# Set up the SnapTool external snapshots manager WEKA provides an external snapshots manager called SnapTool, allowing you to efficiently schedule and manage filesystem snapshots for your WEKA cluster. Key features of SnapTool include: * Schedule snapshots at monthly, daily, or minute-level intervals throughout the day. * Set the number of snapshot copies to retain for each schedule. * Automatically delete expired snapshots. * Automatically upload snapshots of a filesystem to its configured object store. * Perform uploads and deletions in the background. * Access a Web Status GUI to view snapshot schedules, upload/download queues, locator IDs for uploaded snapshots, and logs. The default URL is http\://\:8090. Configuration of SnapTool is managed by editing the `snaptool.yml` file before installation. To adjust SnapTool’s behavior after installation, update this file. SnapTool automatically monitors the configuration file and reloads it approximately every minute when changes are detected. {% hint style="info" %} The Snapshot Policies feature replaces the SnapTool external snapshot manager. Snapshot Policies offer greater flexibility and improved control for creating and managing snapshots. See [snapshot-policies](https://docs.weka.io/4.4/weka-filesystems-and-object-stores/snapshot-policies "mention"). {% endhint %} ## **SnapTool installation and communication with WEKA cluster** The SnapTool runs on any Linux-based physical server or VM, communicating with the WEKA cluster via an IP connection to a WEKA host using the WEKA REST API. It can be installed as a systemd service or within a Docker container.

SnapTool setup

{% hint style="info" %} If you have deployed the WMS, follow the procedure in:[deploy-monitoring-tools-using-the-weka-management-station-wms](https://docs.weka.io/4.4/monitor-the-weka-cluster/deploy-monitoring-tools-using-the-weka-management-station-wms "mention"). Otherwise, continue with this workflow. {% endhint %} ### Before you begin If a previous SnapTool version exists in the physical server, make a copy of your existing `snaptool.yml` file. If the `snaptool.yml` file is from releases before 1.0.0, it is incompatible with 1.0.0 or higher. You need to modify the file to use the new syntax. Setting up a dedicated physical server (or VM) for the installation is recommended. #### Server minimum requirements * 2 cores * 8 GB RAM * 5 GB /opt/ partition (for the SnapTool installation) * Network access to the WEKA cluster * To use Docker, the following must be installed on the dedicated physical server (or VM): * `docker-ce` * `docker-compose` or `docker-compose-plugin`, depending on the existing operating system. For instructions on the Docker installation, see the [Docker website](https://www.docker.com/get-started). ### SnapTool authentication For the SnapTool host to communicate with the WEKA cluster, a security token is necessary. However, the SnapTool host is not required to have the WEKA client installed. #### Prepare SnapTool user and token Perform the following steps on an **existing host with access to the WEKA CLI**, for example, on a WEKA backend server. 1. **Create a dedicated user:** Create a unique local username (for example, `snaptool`) for SnapTool. The unique username is displayed in the event logs, making the identification and troubleshooting of issues easier. Then, assign the ClusterAdmin or OrgAdmin role.\ Example: `weka user add snaptool clusteradmin` 2. **Generate an authentication token for the user:** Run the following command:\ `weka user login snaptool --path snaptool-authtoken.json` 3. **Transfer the token:** Copy the `snaptool-authtoken.json` file to the SnapTool management server. It will later be placed in a specific directory on that host. 4. **Remove the token file:** Delete the `snaptool-authtoken.json` locally.\ Example: `rm snaptool-authtoken.json` #### Configure SnapTool host with authentication token Perform the following steps on the **SnapTool host**. 1. **Create a directory for the authentication token:** Run the following command: `mkdir /root/.weka` 2. **Move the previously-created authentication token into the new directory: :** Run the following command: `mv ~/snaptool-authtoken.json /root/.weka/auth-token.json` 3. **Ensure appropriate ownership and permissions are set:** Run the following commands:\ `chown root:root /root/.weka/auth-token.json`\ `chmod 400 /root/.weka/auth-token.json` **Related topics** [#create-a-local-user](https://docs.weka.io/4.4/operation-guide/user-management/user-management#create-a-local-user "mention") [obtain-authentication-tokens](https://docs.weka.io/4.4/security/obtain-authentication-tokens "mention") ### Option 1: Install the SnapTool package with the systemd service 1. Download the latest `snaptool.tar` file from this [link](https://github.com/weka/snaptool/releases/latest/download/snaptool.tar) and extract it to the physical server. 2. Edit the `snaptool.yml` configuration file (default location: /opt/weka/snaptool).\ See [Edit the configuration in snaptool.yml](#edit-the-configuration-in-snaptool.yml).\ This is a mandatory step before running the installer. Otherwise, the installation fails. 3. Install the *unit* file into the `systemd` and start the service. Run the following command:\ `./install.sh`\ The installer validates the connection to the cluster by the hosts specified in the `snaptool.yml` file. {% hint style="info" %} If the systemd service is already running locally, the installer stops it and preserves the existing `snaptool.yml` file before restarting it. {% endhint %} ### Option 2: Install the SnapTool package in Docker The `snaptool` container runs similarly to other WEKA Docker containers. 1. Download the docker image from the docker hub. Run the following command:\ `docker pull wekasolutions/snaptool:latest` 2. Download the following files from GitHub to a dedicated directory in the physical server: * `snaptool.yml` * `docker_run.sh` 3. Edit the `snaptool.yml` configuration file (default location: /opt/weka/snaptool).\ See [Edit the configuration in snaptool.yml](#edit-the-configuration-in-snaptool.yml).\ This is a mandatory step before running the installer. Otherwise, the installation fails. 4. Edit the `time_zone` field in the `docker_run.sh` file. 5. Run the following command:\ `./docker_run.sh` 6. Verify that the SnapTool container is running using the following command:\ `docker ps` Example: ``` oot@weka142:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 718486e75b38 wekasolutions/snaptool "/wekabin/snaptool -…" 30 hours ago Up 5 hours weka_snaptool ``` {% hint style="info" %} A `logs` directory is created during the installation in the current working directory for logs and snapshot journaling files. {% endhint %} ## Edit the configuration in the snaptool.yml file The SnapTool configuration is defined in the `snaptool.yml` file. 1. Go to the `snaptool` directory and open the `snaptool.yml` file. 2. In the **cluster** section under the **hosts** list, replace the hostnames with the actual hostnames/IP addresses of the Weka containers (up to three would be sufficient). Syntax: ``` cluster: auth_token_file: auth-token.json hosts: vweka01,vweka02,vweka03 ``` Example: ``` cluster: auth_token_file: auth-token.json hosts: hostname1,hostname2,hostname3 ``` 3\. In the **snaptool** section, the default network port to access the Web Status GUI is 8090. If required, you can modify it. To disable the Web Status GUI, set the port to 0. Syntax: ``` snaptool: port: 8090 ``` 4\. In the **filesystems** section, specify the filesystems and their schedule names to run snapshots. Syntax: ``` : ,... : ,... ``` Example: ``` filesystems: fs01: default fs02: Weekdays-6pm, Weekends-noon ``` 5\. Optional. Customize the snapshot schedules. Adhere to the following rules when customizing the schedules: * Schedules within a schedules group, such as `default`, cannot be assigned separately from the group. Use only the group name. * To set a specific schedule within a schedules group, such as monthly and weekly, **not** to run on a filesystem, remove it from the filesystem's schedule list. * When deleting snapshots automatically, based on the `retain:` value, snapshots for a schedule and filesystem are sorted by the creation time. The oldest snapshots are deleted until the number of snapshots to retain (the value specified in the `retain:` section) remains. * The SnapTool checks if the `snaptool.yml` file has changed about every minute and reloads it if it is changed. Snapshot schedules are then recalculated before creating new snapshots. {% hint style="info" %} For details about the syntax of the `schedules` section, see the comments in the `snaptool.yml` file. {% endhint %} Example: ```yaml schedules: default: monthly: every: month retain: 6 # day: 1 (this is default) # at: 0000 (this is default) weekly: every: Sunday retain: 8 # at: 0000 (this is default) daily: every: Mon,Tue,Wed,Thu,Fri,Sat retain: 14 # at: 0000 (this is default) hourly: every: Mon,Tue,Wed,Thu,Fri retain: 8 interval: 60 at: 9:00am until: 5pm workhoursHourlyUp: every: Mon,Tue,Wed,Thu,Fri retain: 7 at: 0900 until: 5pm interval: 60 upload: True workhoursEvery20: every: Mon,Tue,Wed,Thu,Fri retain: 7 at: 0900 until: 5pm interval: 20 weekendsNoon: every: Sat,Sun retain: 4 at: 1200 fridayUpload: every: Friday retain: 3 at: 7pm upload: True ``` ### Snapshot naming conventions The format of the snapshot names is `.YYMMDDHHMM`, with the access point `@GMT-YYYY.MM.DD-HH.MM.SS`. **Example:** For a snapshot name `Weekends-noon.2103101200` and access point `@GMT-2021.03.10-12.00.00`, the snapshot name is in the local timezone, the access point is in GMT, and the server timezone is GMT. The name for a group of snapshots is`_.YYMMDDHHMM`. The length of the full name before the '.' is a maximum of 18 characters. **Example:** The `default` schedule group with an `hourly` schedule can be named `default_hourly.YYMMDDHHMM`. {% hint style="warning" %} The SnapTool distinguishes between user-created snapshots and scheduled snapshots only by their name. When creating user-created snapshots, avoid name collisions with scheduled snapshot names. The SnapTool might automatically select the user-created snapshots for deletion if the same naming format is used. {% endhint %} ## Modify SnapTool schedules To change, add, or remove schedules in the SnapTool configuration after installation, follow these steps: 1. **Edit the configuration file**: Open the `snaptool.yml` file, typically located at `/opt/weka/snaptool/snaptool.yml`, and make the necessary changes, such as adjusting schedules or adding filesystems. See [#edit-the-configuration-in-the-snaptool.yml-file](#edit-the-configuration-in-the-snaptool.yml-file "mention"). 2. **Save changes**: Save the modified `snaptool.yml` file after making the updates. 3. **Automatic reload**: SnapTool checks for changes in the configuration file approximately every minute and automatically reloads it if any changes are detected. 4. **Manually apply changes (optional)**: If you want to apply the changes immediately, restart the SnapTool service with the following command: ``` sudo systemctl restart weka-snaptool.service ``` 5. **Verify changes**: Review the SnapTool logs in the `logs` directory or monitor snapshot schedules to ensure the new configuration is applied. (The logs directory is created during installation in the current working directory for logs and snapshot journaling files.) ## **Check snapshot status and rotation** To check if snapshots are running and rotating in a WEKA system, use the following commands: * **View snapshots**: Run `weka fs snapshot` to list all available snapshots, including their creation time and status. * **View snapshot details**: For details on a specific snapshot, use `weka fs snapshot --name `. * **Check snapshot rotation**: Regularly review the list and timestamps to ensure old snapshots are being deleted and new ones are created as per the snapshot policy. For more information on checking snapshot status and rotation, see [snapshots](https://docs.weka.io/4.4/weka-filesystems-and-object-stores/snapshots "mention").