The backups Directory
The backups directory is the default location for the data and metadata from any backup performed manually or
automatically by Tungsten. The backup data and metadata for each backup will be stored in this directory.
An example of the directory content is shown below:
shell> ls -al /opt/continuent/backups/
total 130788
drwxrwxr-x 2 tungsten tungsten 4096 Mar 3 16:09 .
drwxrwxr-x 3 tungsten tungsten 4096 Mar 3 11:51 ..
-rw-r--r-- 1 tungsten tungsten 71 Mar 3 16:09 storage.index
-rw-r--r-- 1 tungsten tungsten 133907646 Mar 3 16:09 store-0000000001-mysqldump_2025-03-04_16-08_42.sql.gz
-rw-r--r-- 1 tungsten tungsten 317 Mar 3 16:09 store-0000000001.properties
The storage.index contains the backup file index information. The actual backup data is stored in the GZipped file. The
properties of the backup file, including the tool used to create the backup, and the checksum information, are located in the corresponding
.properties file. Note that each backup and property file is uniquely numbered so that you can identify and restore a specific
backup.
Different backups scripts and methods may place their backup information in a separate subdirectory. For example, xtrabackup stores
backup data into /opt/continuent/backups/xtrabackup.
For full details of taking Backups, and restoring within a Tungsten Cluster, see "Creating a Backup"
Automatically Deleting Backup Files
Tungsten will automatically remove old backup files. This is controlled by the backup-retention setting and defaults to 3. Use the
tpm update command to modify this setting. Following the successful creation of a new backup, the number of backups will be compared
to the retention value. Any excess backups will be removed from the /opt/continuent/backups directory or whatever directory is
configured for backup-directory.
The backup retention will only remove files starting with store. If you are using a backup method that creates additional
information then those files may not be fully removed until the next backup process begins. This includes xtrabackup,
xtrabackup-incremental and any snapshot based backup methods. You may manually clean these excess files if
space is needed before the next backup method. If you delete information associated with an existing backup, any attempts to restore it
will fail.
Manually Deleting Backup Files
If you no longer need one or more backup files, you can delete the files from the filesystem. You must delete both the SQL data, and the corresponding properties file. For example, from the following directory:
shell> ls -al /opt/continuent/backups
total 764708
drwxrwxr-x 2 tungsten tungsten 4096 Apr 16 13:57 .
drwxrwxr-x 3 tungsten tungsten 4096 Apr 16 13:54 ..
-rw-r--r-- 1 tungsten tungsten 71 Apr 16 13:56 storage.index
-rw-r--r-- 1 tungsten tungsten 517170 Apr 15 18:02 store-0000000004-mysqldump-1332463738918435527.sql
-rw-r--r-- 1 tungsten tungsten 311 Apr 15 18:02 store-0000000004.properties
-rw-r--r-- 1 tungsten tungsten 517170 Apr 15 18:06 store-0000000005-mysqldump-2284057977980000458.sql
-rw-r--r-- 1 tungsten tungsten 310 Apr 15 18:06 store-0000000005.properties
-rw-r--r-- 1 tungsten tungsten 781991444 Apr 16 13:57 store-0000000006-mysqldump-3081853249977885370.sql
-rw-r--r-- 1 tungsten tungsten 314 Apr 16 13:57 store-0000000006.properties
To delete the backup files for index 4:
shell> rm /opt/continuent/backups/alpha/store-0000000004*
See the information in "Copying Backup Files" about additional files related to a single backup. There may be additional files associated with the backup that you will need to manually remove.
Removing a backup should only be performed if you know that the backup is safe to be removed and will not be required. If the backup data is required, copy the backup files from the backup directory before deleting the files in the backup directory to make space.
Copying Backup Files
The files created during any backup can be copied to another directory or system using any suitable means. Once the backup has been completed, the files will not be modified or updated and are therefore safe to be moved or actively copied to another location without fear of corruption of the backup information.
There are multiple files associated with each backup. The number of files will depend on the backup method that was used. All backups will
use at least two files in the /opt/continuent/backups directory.
shell> cd /opt/continuent/backups
shell> scp store-[0]*6[.-]* host3:$PWD/
store-0000000001-full_xtrabackup_2024-08-16_15-44_86 100% 70 0.1KB/s 00:00
store-0000000001.properties 100% 314 0.3KB/s 00:00
Check the ownership of files if you have trouble transferring files or restoring the backup. They should be owned by the
tungsten system user to ensure proper operation.
If xtrabackup-full method was used, you must transfer the corresponding directory from
/opt/continuent/backups/xtrabackup. In this example that would be
/opt/continuent/backups/xtrabackup/full_xtrabackup_2024-08-16_15-44_86.
shell> cd /opt/continuent/backups/xtrabackup
shell> rsync -aze ssh full_xtrabackup_2024-08-16_15-44_86 host3:$PWD/
If the xtrabackup-incremental method was used, you must transfer multiple directories. In addition
to the corresponding directory from /opt/continuent/backups/xtrabackup you must transfer all
xtrabackup-incremental directories since the most recent xtrabackup-full backup
and then transfer that xtrabackup-full directory. See the example below for further explanation:
shell> ls -altr /opt/continuent/backups/xtrabackup/
total 32
drwxr-xr-x 7 tungsten tungsten 4096 Oct 16 20:55 incr_xtrabackup_2024-10-16_20-55_73
drwxr-xr-x 7 tungsten tungsten 4096 Oct 17 20:55 full_xtrabackup_2024-10-17_20-55_1
drwxr-xr-x 7 tungsten tungsten 4096 Oct 18 20:55 incr_xtrabackup_2024-10-18_20-55_38
drwxr-xr-x 7 tungsten tungsten 4096 Oct 19 20:57 incr_xtrabackup_2024-10-19_20-57_76
drwxr-xr-x 7 tungsten tungsten 4096 Oct 20 20:58 full_xtrabackup_2024-10-20_20-57_41
drwxr-xr-x 8 tungsten tungsten 4096 Oct 21 20:58 .
drwxr-xr-x 7 tungsten tungsten 4096 Oct 21 20:58 incr_xtrabackup_2024-10-21_20-58_97
drwxrwxr-x 3 tungsten tungsten 4096 Oct 21 20:58 ..
In this example there are two instances of xtrabackup-full backups and four
xtrabackup-incremental backups.
- To restore either of the
xtrabackup-fullbackups then they would be copied to the target host on their own. - To restore
incr_xtrabackup_2024-10-21_20-58_97, it must be copied along withfull_xtrabackup_2024-10-20_20-57_41. - To restore
incr_xtrabackup_2024-10-19_20-57_76, it must be copied along withincr_xtrabackup_2024-10-18_20-55_38andfull_xtrabackup_2024-10-17_20-55_1.
Relocating Backup Storage
If the filesystem on which the main installation directory is running out of space and you need to increase the space available for backup files without interrupting the service, you can use symbolic links to relocate the backup information.
When using an NFS mount point when backing up with xtrabackup, the command must have the necessary access rights and permissions
to change the ownership of files within the mounted directory. Failure to update the permissions and ownership will cause the
xtrabackup command to fail. The following settings should be made on the directory:
Ensure the
no_root_squashoption on the NFS export is not set.Change the group and owner of the mount point to the
tungstenuser andmysqlgroup:shell> chown tungsten /mnt/backupsshell> chgrp mysql /mnt/backupsOwner and group IDs on NFS directories must match across all the hosts using the NFS mount point. Inconsistencies in the owner and group IDs may lead to backup failures.
Change the permissions to permit at least owner and group modifications:
shell> chmod 770 /mnt/backupsMount the directory:
shell> mount host1:/exports/backups /mnt/backups
The backup directory can be changed using two different methods:
- "Relocating Backup Storage using Symbolic Links"
- "Relocating Backup Storage using Configuration Changes"
Relocating Backup Storage using Symbolic Links
To relocate the backup directory using symbolic links:
Ensure that no active backup is taking place of the current host. Your service does not need to be offline to complete this operation.
Create a new directory, or attach a new filesystem and location on which the backups will be located. You can use a directory on another filesystem or connect to a SAN, NFS or other filesystem where the new directory will be located. For example:
shell> mkdir /mnt/backupdata/continuentOptional
Copy the existing backup directory to the new directory location. For example:
shell> rsync -r /opt/continuent/backups/* /mnt/backupdata/continuent/Move the existing directory to a temporary location:
shell> mv /opt/continuent/backups /opt/continuent/old-backupsCreate a symbolic link from the new directory to the original directory location:
shell> ln -s /mnt/backupdata/continuent /opt/continuent/backups
The backup directory has now been moved. If you want to verify that the new backup directory is working, you can optionally run a backup and ensure that the backup process completes correctly.
Relocating Backup Storage using Configuration Changes
To relocate the backup directory by reconfiguration:
Ensure that no active backup is taking place of the current host. Your service does not need to be offline to complete this operation.
Create a new directory, or attach a new filesystem and location on which the backups will be located. You can use a directory on another filesystem or connect to a SAN, NFS or other filesystem where the new directory will be located. For example:
shell> mkdir /mnt/backupdata/continuentOptional
Copy the existing backup directory to the new directory location. For example:
shell> rsync -r /opt/continuent/backups/* /mnt/backupdata/continuent/Following the directions for
tpm updateto apply thebackup-directory=/mnt/backupdata/continuentsetting.
The backup directory has now been moved. If you want to verify that the new backup directory is working, you can optionally run a backup and ensure that the backup process completes correctly.