Avamar : la taille d’une sauvegarde de client Linux peut être trompeuse en raison du comportement de gestion des fichiers « /var/log/lastlog » et sparse file handling.

Le comportement décrit dans cet article peut avoir un impact sur la création de rapports sur la taille des sauvegardes Avamar.
Cela nous intéresse lorsque nous devons générer des rapports sur la quantité de données protégées dans une sauvegarde Avamar. Par exemple, un prestataire de services facture aux utilisateurs finaux le montant du client.

La taille signalée d’une sauvegarde de client Linux où /var/log/lastlog est inclus peut être supérieure à l’espace disque total disponible pour le client.

Exemple:
Un client Linux est configuré pour sauvegarder uniquement le répertoire /var/log qui contient 39 Mo de données.

root@linuxclient:~/#: du -hs /var/log
39M /var/log

Le répertoire /var/log et la sauvegarde contiennent « lastlog »,  

root@linuxclient:/var/log/#: ls -ltrhs /var/log/lastlog
48K -rw-rw-r-- 1 root root 272G Apr 30 11:46 /var/log/lastlog

Remarque : lastlog consomme 48 Ko d’espace sur le disque, alors que la taille normale signalée est de 272 Go. Il s’agit d’un fichier sparse. À la fin de la sauvegarde, avtar affirme avoir sauvegardé 272 Go de données.
 

2015-04-30 12:08:09 avtar Info <5163>: Backup complete, wrapping-up session with Server
2015-04-30 12:08:10 avtar Info <5156>: Backup #494 timestamp
2015-04-30 12:21:58, 131 files, 16 directories, 272.0 GB (5 files, 6.830 KB, 0.00% new)
2015-04-30 12:08:10 avtar Info <7539>: Label "MOD-1430395268242", scheduled to expire after 06/29/15 (2015-06-29 12:01:07 UTC), none backup
2015-04-30 12:08:10 avtar Info <6083>: Backed-up 272.0 GB in 20.83 minutes: 783 GB/hour (377 files/hour)

La valeur signalée pour la quantité de données sauvegardées est supérieure à la taille du système de fichiers Linux.

root@linuxclient:~/#: df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 7.9G 2.4G 5.1G 32% /
/dev/sda1 122M 13M 103M 12% /boot
none 3.0G 0 3.0G 0%
/dev/shm /dev/sda3 1.5G 125M 1.3G 9% /var

Le fichier /var/log/lastlog change chaque fois qu’un utilisateur (humain ou autre) se connecte au système. Avtar doit traiter l’intégralité du fichier en raison des limitations de gestion des fichiers sparse décrites dans l’article Avamar et des fichiers sparse.

Solution de contournement 1 : Excluez /var/log/lastlog de la sauvegarde. 

Si l’utilisateur doit sauvegarder le dernierlog à des fins d’audit, envisagez de créer un crontab quotidien planifié pour envoyer la sortie du dernierlog à un fichier de sortie,
par exemple,

lastlog > /var/log/lastlog_$(date +%d%m%Y).log

Le fichier standard lastlog_<date> est sauvegardé, mais pas le fichier sparse lastlog d’origine.


Solution de contournement 2 : Réduisez la plage d’ID utilisateur et réduisez « lastlog ».

Déterminez si un ID utilisateur aussi élevé est requis. Est-il susceptible de consommer tous les ID utilisateur de la plage donnée ?
Si un ID utilisateur inférieur est tout aussi fonctionnel, les éléments suivants peuvent être utiles : 

• Modifiez /etc/passwd pour vous assurer que la plage d’ID utilisateur est aussi petite que possible.
• Renommez le fichier lastlog, puis recréez-le à l’aide de touch lastlog. Définissez la propriété et les autorisations comme le fichier d’origine.
• Connectez-vous au système avec un utilisateur pour mettre à jour le fichier lastlog nouvellement créé.

root@linuxclient:/var/log/#: ls -ltrhs | grep lastlog
36K -rw-r----- 1 root tty 272G Apr 28 09:44 lastlog.old
8.0K -rw-r----- 1 root tty 143K Apr 28 09:50 lastlog

Remarque n° 1 :
Du point de vue des performances, la sauvegarde d’un fichier sparse volumineux prend beaucoup de temps. En raison de la nature du « lastlog », le fichier est susceptible d’être modifié et doit être entièrement traité chaque jour. Pour plus d’informations sur les fichiers sparse, voir Avamar et les fichiers sparse.

Remarque n° 2 :
Le fichier /var/log/lastlog est un fichier sparse dont la taille dépend de la plage d’ID utilisateur qui existe dans le fichier /etc/passwd.

Dans l’exemple ci-dessus, /etc/passwd disposait à l’origine d’ID utilisateur qui sont passés à 502.  

Le fichier était éparpillé, mais de manière modérée. La taille de fichier signalée était petite.

root@linuxclient:/var/log/#: ls -ltrhs /var/log/lastlog
16K -rw-rw-r-- 1 root root 143K Apr 30 11:26 /var/log/lastlog

L’ajout d’un utilisateur avec un ID utilisateur volumineux entraîne une augmentation considérable de la taille du dernierlog dans la taille signalée. Comme illustré ci-dessous, plus l’ID utilisateur est élevé, plus le nombre de fichiers épars (et la taille signalée supérieure) du lastlog est élevé.

Ajoutez un utilisateur avec un ID utilisateur élevé.

root@linuxclient:/var/log/#: useradd sparsetest -u 999999 

Utilisateur sparsetest créé.

root@linuxclient:/var/log/#: tail -1 /etc/passwd sparsetest:x:999999:999999::/home/sparsetest:/bin/bash

Le dernier fichierlog augmente dans la taille signalée.

root@linuxclient:/var/log/#: ls -ltrhs /var/log/lastlog
32K -rw-rw-r-- 1 root root 279M Apr 30 11:34 /var/log/lastlog

Ajoutez un utilisateur avec un ID utilisateur encore plus élevé.

root@linuxclient:/var/log/#: useradd sparsetest2 -u 999999999

Le dernier fichierlog devient encore plus éparpillé.

root@linuxclient:/var/log/#: ls -ltrhs /var/log/lastlog
48K -rw-rw-r-- 1 root root 272G Apr 30 11:46 /var/log/lastlog