Set up the SnapTool external snapshots manager
The SnapTool is an external snapshots manager that enables scheduled snapshots and automatic operations
WEKA provides an external snapshots manager named SnapTool, enabling scheduled snapshots for your WEKA cluster.
The SnapTool provides the following features:
Schedule snapshots monthly, daily, or at multiple (minute granularity) intervals during a daily schedule.
Set the number of snapshot copies to retain per schedule.
Delete expired snapshots automatically.
Upload snapshots to an object store automatically.
Upload and delete in the background.
Access a Web Status GUI to view the snapshot schedules, upload and download queue, , locator IDs for successfully uploaded snapshots, and logs. The default URL is
http://<snaptool server hostname/IP>:8090
.
The SnapTool runs on any Linux-based physical server (or VM). All communication with the WEKA cluster is done by an IP connection only to a WEKA host using the WEKA REST API.
The SnapTool package can be installed with a systemd service or Docker container. In both options, you need to edit the configuration in the snaptool.yml
file before running the installation.
If you have deployed the WMS, follow the procedure in:Deploy monitoring tools using the WEKA Management Station (WMS). Otherwise, continue with this workflow.
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
ordocker-compose-plugin
, depending on the existing operating system.
For instructions on the Docker installation, see the Docker website.
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.
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
Generate an authentication token for the user: Run the following command:
weka user login snaptool --path snaptool-authtoken.json
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.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.
Create a directory for the authentication token: Run the following command:
mkdir /root/.weka
Move the previously-created authentication token into the new directory: : Run the following command:
mv ~/snaptool-authtoken.json /root/.weka/auth-token.json
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
Option 1: Install the SnapTool package with the systemd service
Download the latest
snaptool.tar
file from this link and extract it to the physical server.Edit the
snaptool.yml
configuration file (default location: /opt/weka/snaptool). See Edit the configuration in snaptool.yml. This is a mandatory step before running the installer. Otherwise, the installation fails.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 thesnaptool.yml
file.
If the systemd service is already running locally, the installer stops it and preserves the existing snaptool.yml
file before restarting it.
Option 2: Install the SnapTool package in Docker
The snaptool
container runs similarly to other WEKA Docker containers.
Download the docker image from the docker hub. Run the following command:
docker pull wekasolutions/snaptool:latest
Download the following files from GitHub https://github.com/weka/snaptool/releases to a dedicated directory in the physical server:
snaptool.yml
docker_run.sh
Edit the
snaptool.yml
configuration file (default location: /opt/weka/snaptool). See Edit the configuration in snaptool.yml. This is a mandatory step before running the installer. Otherwise, the installation fails.Edit the
time_zone
field in thedocker_run.sh
file.Run the following command:
./docker_run.sh
Verify that the SnapTool container is running using the following command:
docker ps
Example:
A logs
directory is created in the current working directory for logs and snapshot journaling files.
Edit the configuration in the snaptool.yml file
The SnapTool configuration is defined in the snaptool.yml
file.
Go to the
snaptool
directory and open thesnaptool.yml
file.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:
Example:
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:
4. In the filesystems section, specify the filesystems and their schedule names to run snapshots.
Syntax:
Example:
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 theretain:
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.
For details about the syntax of the schedules
section, see the comments in the snaptool.yml
file.
Example:
Snapshot naming conventions
The format of the snapshot names is <schedulename>.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<schedulegroupname>_<schedulename>.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
.
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.