On sait comment sont stockés les fichiers des backups "rsnapshot" (hard
links, nombreuses références vers de mêmes données sur les disques, ...)
Ex:
/monthly.0/serveur1/répertoire1/fichier1
/monthly.0/serveur1/répertoire1/fichier2
/monthly.0/serveur1/répertoire2/fichier1
/monthly.0/serveur1/répertoire2/fichier2
/monthly.0/serveur2/répertoire1/fichier1
/monthly.0/serveur2/répertoire1/fichier2
/monthly.0/serveur2/répertoire2/fichier1
/monthly.0/serveur2/répertoire2/fichier2
/monthly.1/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier2
/monthly.1/serveur1/répertoire2/fichier1
/monthly.1/serveur1/répertoire2/fichier2
/monthly.1/serveur2/répertoire1/fichier1
/monthly.1/serveur2/répertoire1/fichier2
/monthly.1/serveur2/répertoire2/fichier1
/monthly.1/serveur2/répertoire2/fichier2
[...]
La manière dont fonctionne rsnapshot fait que des mêmes fichiers.
contenus dans des répertoires identiques (mêmes noms, même paths), sur
des serveurs identiques mais dans des backups différents, n'occupent
qu'une fois l'espace nécessaire (une seule "copie physique" des
données
sur les disques).
De ce fait, si on change le nom d'un fichier, le backup suivant _refait
une copie des données_ et donc on occupe le double d'espace disque que
nécessaire.
Pire: si on renomme un répertoire, tous les contenus de ce répertoire
(et de l'arborescence située en dessous) sont recopiés, nécessitant
potentiellement un espace-disque important, totalement inutile puisque
les contenus restent les mêmes.
Idem si on change le nom d'un serveur (majuscule/minuscule ou numéro de
version, par exemple).
L'outil rdfind détecte ces cas, et remplace des copies identiques de
contenus par des "hard links", c'est-à-dire économise de
l'espace-disque, sans aucun autre effet non souhaité (en cas de
renommage, de modification par exemple).
Après des tests de grande taille, il apparaît que les backups, avant et
après le passage de rdfind, sont bien identiques. Mais on peut faire
encore mieux.
Sur divers serveurs, on trouve naturellement de nombreux fichiers
identiques (ex: librairies, fichiers "packages", ...), ce que rsnapshot
ne remarque pas, et donc fait des copies multiples, alors que le contenu
est le même.
Il y a aussi le cas des copies multiples de mêmes documents sur un
serveur de fichier, par exemple. Ainsi, une même vidéo peut être
conservée des dizaines de fois dans un même serveur, chaque utilisateur
en conservant une copie dans son espace personnel.
La commande rdfind peut tenir en compte ces situations, à condition
d'utiliser l'option "-removeidentinode false". En effet, par défaut,
il
ne le fait pas. Exemple:
Imaginons que les fichiers "fichier1" sont tous identiques.
/monthly.0/serveur1/répertoire1/fichier1
/monthly.0/serveur1/répertoire2/fichier1
/monthly.1/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire2/fichier1
Avec un coup de rdfind "classique, les deux copies seront remplacées par
_deux___ copies. En effet,
/monthly.0/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier1
sont déjà des "hard links" vers un même contenu, et
*/monthly.0/serveur1/répertoire2/fichier1*
/monthly.1/serveur1/répertoire2/fichier1
sont des "hard links" vers _une autre_ copie. On a donc bien _deux_
copies physiques _avant_ le passage de rdfind.
Après, la situation est:
/monthly.0/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier1
*/monthly.0/serveur1/répertoire2/fichier1*
qui référencent tous une même copie physique, et
/monthly.1/serveur1/répertoire2/fichier1
qui référence une _autre_ copie physique. En effet, par défaut, rdfind
ne traite _qu'une seule fois_ des références multiples d'un même contenu
(hard links vers un même contenu). rdfind considère donc _deux copies_,
et ne remplace donc qu'une seule fois une entrée dans un répertoire (ici
/monthly.0/serveur1/répertoire2/fichier1) par un hardlink vers l'autre
copie.
Du fait que l'autre référence n'est pas traitée, il subsiste une
référence vers la seconde copie (ici
/monthly.1/serveur1/répertoire2/fichier) et donc _on ne gagne aucune
place dans le stockage_. On est passé de deux références vers la copie A
plus deux références vers la copie B à trois références vers la copie A
et une référence vers la copie B, mais les deux copies subsistent.
Si on repasse une couche de rdfind. on va effectivement "fusionner" la
dernière copie aux autres, et libérer de l'espace disque. Mais dans le
cas réel de backups via rsnapshot, on risque d'avoir des milliers de
fichiers qui sont identiques sur divers serveurs (modules du kernel,
librairies, ...) et donc il faudrait exécuter rdfind autant de fois que
nécessaire jusqu'à ce que plus rien ne change.
Comme l'économie de place ne survient, en pratique, qu'au moment de la
disparition de la dernière référence au contenu redondant, il est
nécessaire de procéder ainsi.
Sauf que rdfind dispose d'une option "-removeidentinode", qui évite à
cette commande de ne pas s'intéresser aux copies multiples d'un même
contenu (même inode = hardlinks). Après tests, je peux affirmer que la
commande rdfind, avec l'option "-removeidentinode" sur false, a le
comportement attendu: il remplace _en une seule passe_ *toutes les
copies d'un même contenu* !
Il suffit donc de faire exécuter la commande
rdfind -removeidentinode false -makehardlinks true
-makeresultsfile
true -outputname /var/log/rdfind_result.log /Backup/monthly.0
/Backup/monthly.1
après exécution d'un "rsnapshot" monthly...
Bon à savoir.