KVM : sauvegarde gagner du temps

Les machines virtuelles (ici KVM/QEMU), c'est bien mais il faut aussi les sauvegarder.

J'assure le backup des disques de mes machines virtuelles à l'aide de dd + bzip2 et j'ai constaté que la taille du backup résultant ne fait que croître au cours du temps ... 
Exemple : sur une machine munie d'un disque de 32Gb le backup consommait à l'origine environ 5Gb, après quelques mois de fonctionnement la taille du backup atteint 13 Gb. 
Or le système n'a que peu été modifié et a "subi" principalement les mises à jour de l'OS et l'activité normale d'une machine : écrire des logs, utiliser une base de données, faire tourner les logs (logrotate) fournir un service Web (3000/5000 pages par jour).

Filesystem     1K-blocks    Used Available Use% Mounted on  udev               10240       0     10240   0% /dev  tmpfs             307348    4808    302540   2% /run  /dev/vda3       30971828 6780496  22594968  24% /  /dev/vda1         944120   56628    822316   7% /boot

Le filesystem "root" n'est rempli qu'à 24% mais doit finir par être désorganisé et surtout plein de secteurs qui ont été utilisés et qui ne le sont plus mais comportent des données "aléatoires" peu compressibles. Une sauvegarde par un simple "tar" serait presque moins volumineuse ! 
C'est alors que "zerofree" intervient, il permet de forcer des zéros dans toutes les zones inutilisées du filesystem ce qui les rend beaucoup plus apte à la compression. 
La procédure que j'ai utilisée nécessite l'arrêt de la machine virtuelle car "zerofree" ne peut pas écrire sur un FS monté en lecture/écriture. 
Par commodité j'ai effectué les opérations comme suit :

• stopper la VM
• attacher le disque à une VM "de travail"
• monter le disque en lecture seule sur la VM de travail, par exemple sur /mnt 
  mount /dev/xxx1    /mnt -o ro
• lancer "zerofree" 
  zerofree -n /dev/xxx1
• démonter le disque 
  umount /mnt
• stopper la VM de travail
• relancer la VM originale 

On peut intercaler la sauvegarde proprement dite avant de relancer la VM originale. L'opération de "zéroification" est relativement rapide et donne de bons résultats sur les sauvegardes  (Ci dessous pour une partition de #30Gb) :

Résultats : 
Avant "zéro-ification"

Sauvegarde disque /dev/mapper/VG00-COM--WEB  sur : /DATA/SAUVE/SV_VM/VG00-COM--WEB.dd.bz2  524288+0 records in  524288+0 records out  34359738368 bytes (34 GB) copied, 3836,41 s, 9,0 MB/s -rw-r--r-- 1 root root 13735399619 févr. 28 16:11 VG00-COM--WEB.dd.bz2

Après "zéro-ification" :

Sauvegarde disque /dev/mapper/VG00-COM--WEB  sur : /DATA/SAUVE/SV_VM/VG00-COM--WEB.dd.bz2  524288+0 records in  524288+0 records out  34359738368 bytes (34 GB) copied, 1540,74 s, 22,3 MB/s -rw-r--r--  1 root root  4492903322 févr. 28 17:51 VG00-COM--WEB.dd.bz2

Le gain d'espace est d'environ 9Gio (-66%), celui de temps est très appréciable lui aussi #25 minutes contre un peu plus d'une heure (-60%).

C'est dons une opération à renouveler régulièrement et qui ne dure pas très longtemps :

- Sur partition /boot 954Mio  ./ZEROF  dimanche 28 février 2016, 16:38:52 (UTC+0100)  dimanche 28 février 2016, 16:39:04 (UTC+0100) - sur partition /  30,1Gio  ./ZEROF  dimanche 28 février 2016, 16:44:48 (UTC+0100)  dimanche 28 février 2016, 16:49:57 (UTC+0100)

La seule chose dont il faut disposer est d'une machine virtuelle avec son propre disque système sur laquelle on peut "attacher" le disque à "zéroifier". 
Et un peu de temps #1Gio = 12s, #30Gio un peu plus de 5 minutes, ce qui est "rentable" à coté des 35 minutes gagnées sur la sauvegarde.