Attention si vous sauvegardez vos systèmes avec tar. C'est super mega simple et pratique à restaurer mais il y a des petites choses à savoir :
Par défaut, tar sauvegarde les UID et GID sous forme textuelle. Ça veut dire qu'il lit le UID+GID d'un fichier, qu'il regarde à quoi ces ID correspondent dans /etc/{passwd,group} et qu'il sauvegarde les intitulés qu'il a trouvés. Ça suppose deux choses :
1- que l'utilisateur et le groupe existent lors de la restauration ;
2- de créer l'archive sur le système lui-même.
Exemple : si vous sauvegardez vos LXC depuis l'hôte, c'est bien les fichiers /etc/{passwd,group} de l'hôte qui seront utilisés pour faire la traduction numéro->nom, pas les /etc/{passwd,group} de votre LXC donc, quand vous restaurerez votre sauvegarde, vous aurez des fichiers/dossiers qui n'appartiennent pas aux bons utilisateurs, ce qui empêchera les logiciels de démarrer.
Pour éviter cela, il faut utiliser --numeric-owner
lors de la sauvegarde.
Par défaut, tar ne sauvegarde pas les file capabilities, ces droits très précis/fins que l'on accorde à une application au lieu de les setuid/setgid (ce qui leur donne plus de droits que ce dont elles ont besoin). L'exemple classique est ping, à qui on attribue la capability « cap_net_raw » pour qu'il puisse créer des sockets raw ICMP.
Pour sauvegarder les capabilites, il faut utiliser --xattrs
lors de la sauvegarde. Il y a visiblement une subtilité lors de la restauration : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775495 .
Je parle des file capabilites mais c'est la même chose pour les ACL POSIX et/ou les contextes SELinux : tar ne les sauvegarde pas par défaut, il faut le demander explicitement.
Autant réparer une restauration qui n'a pas les bons UID/GID, c'est compliqué sans connaître les permissions d'origine (mais on peut les retrouver depuis les scripts de post-installation mais ça nécessite de retrouver quel package a livré tel fichier/dossier et ça, c'est chiant), autant réparer les capabilites, ça se fait plutôt bien. Les capabilites ne sont pas positionnées dans l'archive tar contenue dans un paquet debian (.deb, tout ça). dpkg ne s'en occupe pas non plus. C'est les scripts de postinstall qui s'en occupent. Il suffit donc de lire tous ces fichiers et de retrouver ceux qui affectent des capabilites : grep -R "setcap" /var/lib/dpkg/info/*.postinst
. Il suffit d'exécuter manuellement les commandes setcap que l'on trouve et c'est réglè.
Si vous faites une sauvegarde relative, du genre cd / && tar --exclude='./tmp' --exclude='./dev' -cpJf save.tar.lzma .
, ça complique la restauration : il vaut mieux faire : cd / && tar -cpJf save.tar.lzma bin boot [...]
. Il faut réaliser la backup depuis la racine si l'objectif de la sauvegarde est de restaurer tout un système d'un coup.
Petite info intéressante qui va dans ce sens : on peut tar xf une arborescence sur un système en fonctionnement (genre cd / && tar xf save.tar.lzma
) mais on ne peut pas cp ou mv une arborescence sur un système en fonctionnement (ici, rootfs est le dossier extrait par tar) :
# cp -R rootfs/* /
cp: cannot create regular file '/bin/bash': Text file busy
cp: cannot create regular file '/bin/cp': Text file busy
cp: cannot create regular file '/lib/x86_64-linux-gnu/ld-2.19.so': Text file busy
Je n'explique pas la différence entre tar et cp… tar est aussi lancé par bash et il utilise aussi la libld-2.19 située dans le même répertoire…