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.

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.

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.

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.

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.

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.

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.

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.

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.

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.