What is most important for backups? That's right, reproducibility. So let's make a bike on the knee and on the --link-dest
option of rsync . Our bike will not have a complex git-like restic data structure, nor a bunch of backends like duplicity. But we can restore his work from memory, even under stress.
The --link-dest
option allows you to specify the previous backup version on which rsync will put hard links if files have not changed since the last time.
That is, rsync --link-dest=/var/backups/www.1 remote:/var/www /var/backups/www.0
copies only those files from the remote server to the /var/backups/www.0 folder that have changed, but for the rest it will put a hard link in /var/backups/www.1
Now the trick is small: wrap the rsync
call in code that shifts backups by one back and frees up space for a new backup in /var/backups/www.0
, and also removes the last copy of /var/backups/www.9
.
This code will rename /var/backups/www.1
to /var/backups/www.2
and /var/backups/www.0
rename /var/backups/www.1
.
It remains only to run rsync --link-dest=/var/backups/www.1 remote:/var/www /var/backups/www.0
, adding options to taste. So the --delete
option deletes the files in the last copy ( rsync
does not do this by default), the -C
option ignores the .svn
, .git
folders, patch
artifacts and some other common types of temporary files.
Together:
Outside of the brackets was error handling (see set -e
) and notifications, and the number of copies can be made customizable.
But it works!