Triggering the backup
Manual backup
Whether you have configured Tar-LVM just basically for manual backup or more thoroughly for automated backup, you can always run the backup manually from the command line. Both ssd-backup and tar-lvm scripts are installed and must be configured irrespective of the model used.
If all your filesystems that must stay read-write during normal system operation are using LVM volumes and if the tar-lvm
script is configured to create and backup their LVM snapshots, full manual backup can be invoked by using the following command sequence.
ssd-backup -u -v stop
tar-lvm -v pre
ssd-backup -u -v start
tar-lvm -v run 0 /path/to/backup/dir
tar-lvm -v post
The downtime of all services to stop is really short, because it covers only the period that is necessary for creating LVM snapshots. After the snapshots are created, the system can operate normally because the contents of the snaphots is backed up.
If the read-write filesystems are not on LVM, their backup can be performed as well. The only difference is the duration of the downtime period that must cover whole backup process in order to create consistent backup of whole operating system.
ssd-backup -u -v stop
tar-lvm -v pre
tar-lvm -v run 0 /path/to/backup/dir
tar-lvm -v post
ssd-backup -u -v start
Consecutive incremental backups are obtained in the same way, just the level
argument of the tar-lvm
command in the run
mode must be increased. E.g. a level 1 incremental backup can be obtained as follows.
...
tar-lvm -v run 1 /path/to/backup/dir
...
Automated backup
Centralized triggering model
A compulsory prerequisity for the centralized triggering model is to have the tar-lvm-all script installed and configured at the host triggering and managing the backups. Its usage is then simple, just don't forget that SSH public key authentication must be set up as described earlier.
Let's edit the configuration of the Cron scheduler at the triggering host.
crontab -e
It could look as follows to run the backups at midnight. Full backup is done on Sunday and the incremental ones on all other week days.
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
0 0 * * * tar-lvm-all all "$(date '+%w')"
The backup results can be checked automatically as well and mailed by Cron. This must be configured at the triggering host again, i.e. at the host where tar-lvm-all
runs.
crontab -e
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
0 6 * * * tar-lvm-all check "$(date '+%w')"
Distributed triggering model
As it was already mentioned, the distributed triggering model doesn't require to have the tar-lvm-all
script installed or configured, tar-lvm-one is sufficient. This also means that the direct access method of the backup storage shouldn't be used and that the backup storage should be always accessed remotely using the SSHFS filesystem. The reason is that this method allows concurrent access to the backup device from more hosts.
If you want to run the backup of certain host at midnight with full backup on Sunday and incremental backups on all other week days, simply configure Cron as follows at the backup host, i.e. at the host being backed up.
crontab -e
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
0 0 * * * tar-lvm-one all "$(date '+%w')" && echo 'tar-lvm-one result => ok' || echo 'tar-lvm-one result => failure'
The backup results can be checked automatically again and mailed by Cron if the tar-lvm-one
script in the check
mode produces some error output. This must be configured at the backup host again.
crontab -e
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
0 6 * * * tar-lvm-one check "$(date '+%w')"
Rotating the backups and logs
It's wise not to use the -f
argument to delete existing archives and logs of the same or higher backup level, but save the target backup directory at the backup storage before each new full backup is created.
The simplest solution could be configured in Cron at the backup storage. If the full backup is created on Sunday and incremental backups on another week days, let's save just the backups for the last week and delete everything else.
crontab -e
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
50 23 * * 6 cd /path/to/backup/storage && rm -fr tar-lvm.old && mv tar-lvm tar-lvm.old
There are many ways how to achieve backup rotation depending on your needs. Another example storing all backups for the whole year could be configured using Cron again at the backup storage.
crontab -e
SHELL=/bin/bash
MAILTO=backup@domain.org
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
50 23 * * 6 cd /path/to/backup/storage && rm -fr "tar-lvm.$(date '+%W')" && mv tar-lvm "tar-lvm.$(date '+%W')"
Inserted: | 2017-12-20 19:56:44 |
Last updated: | 2017-12-20 19:56:44 |