search

gkiefer / backup2l

backup2l - A Low-Maintenance Backup/Restore Tool
https://gkiefer.github.io/backup2l
GNU General Public License v2.0
47 stars 16 forks source link

Rotating full backups #17

Closed gburca closed 5 years ago

gburca commented 5 years ago

I've been using backup2l for a long time and I love it. The files it generates are being backed up offsite to AWS Glacier. Glacier has no facility to move or rename the backups, or any of the associated metadata.

If I decide to purge some of the old full backups to save space (or if I reach the MAX_FULL limit of 8), backup2lwill delete the first full backup and move/rename all the subsequent backups, moving them up. This move/rename is impossible to replicate on Glacier.

Is there a sensible workaround for this situation? Ideally backup2l would never rename a BID once it's been created.

gkiefer commented 5 years ago

The solution to your problem is:

  1. Never remove the meta data of old backups. To save disk space, you may remove the archive file (e.g. 'all.1.tar,.gz') while leaving the meta files (especially 'all.1.list.gz') intact. (See also section "MANIPULATING FILES AND CONFIGURATIONS" in the man page on moving archive files out of the way.)

  2. Make sure that you never get more than MAX_FULL full backups.

In this case, backup2l will never rename backup archives.

Rule 2 may appear restrictive at first glance. However, if you run daily backups with MAX_LEVEL=4 and MAX_PER_LEVEL=9 (or similar), the period between two full backups is already more than 25 years. Even if at certain occasions it may make sense to insert manual full backups, there is enough room to not exceed 9 full backups during your (hopefully long) life time.