How rotation works :
When rsnapshot hourly is called, a new backup will be created from the file system, and saved in <snapshot_root>/hourly.0/. The rest of the retained backups will continue to get incremented each time the command is run. So eventually, what was <snapshot_root>/hourly.0, will become <snapshot_root>/hourly.23/. Then the next time the command is run, this will be deleted.
When rsnapshot daily is called, it will create <snapshot_root>/daily.0/ from the <snapshot_root>/hourly.23/ backup if it exists. Otherwise, rotation works the same way.
Likewise, when rsnapshot weekly is called, it will create <snapshot_root>/weekly.0/ from the <snapshot_root>/daily.6/ backup if it exists. The pattern follows the same for each additional retain level that is configured.
Un pattern avec rsnapshot :
Utiliser la directive backup_script pour éxécuter un script distant (backup script<tab>ssh root@hostA.com /mon/script/backup.sh<tab>unused/)
Et ensuite la directive backup pour récupérer ce qui a été produit à distance en local (backuptab>root@hostA.com:/mon/working/dir/<tabhostA.com
De cette façon, il n'y a plus de cron sur la machine à backup. Le cron rsnapshot déclenche le backup à distance, et ensuite ramène les datas.
On pourrait aller un cran plus loin en ayant pas de script sur la machine à backup mais laisser le script a quand meme des avantages : on a le dernier backup en local et un script plus clair qu'une suite de ssh root@host 'cmd1', ssh root@host 'cmd'..
PS : le script doit se charger de faire le ménage avant de commencer, on supprime tout et on lancer le backup. Car on ne veut garder qu'une copie en local
Découverte sympa, même si je reste fan de rsnapshot et de ses hardlink
Pour avoir plusieurs politiques de retentions suivant les répertoires, il faut créer plusieurs fichiers de config et lancer en cron rsnapshot en précisant la conf (-c)
Attention à bien changer le snapshot_root
à tester le script de report en perl