Archlinux.fr [Forums]

Plop !

Ma question est toute simple, mais personne n'a été capable de me répondre de but en blanc : je veux faire des snapshots de mes machines, et je veux pouvoir rollback sans soucis (remplacer mon système actuel par un instantané qui a été pris il y a X semaines).

Quels dossiers doivent être snapshottés pour éviter les inconsistances[1] ?
Quels dossiers peuvent être laissés tels quels malgré un rollback, notamment pour des questions d'espace disque[2] ?

Il est à noter que j'utilise un SSD de 250Go (je crois) avec compression lzo globale (tous mes fichiers sont compressés sur le disque).

Voilà, je compilerai ici une liste de dossiers et fichiers importants à conserver.
Merci d'avance !

[1]Genre pacman qui me dit "Oui, le paquet <paquet> est installé, mais euh... y'a aucun fichier à lui dans le FS !"
[2]Genre /var/cache/pacman qui ne contient "que" les paquets (ça prend de la place en plus, pas question que je le snapshotte !)

Salut,

Bon, je t'avais préparé un pavé mais je l'ai perdu à cause d'une déconnexion du forum... donc tu n'auras qu'une version courte.

Moviuro a écrit :Ma question est toute simple, mais personne n'a été capable de me répondre de but en blanc : je veux faire des snapshots de mes machines, et je veux pouvoir rollback sans soucis (remplacer mon système actuel par un instantané qui a été pris il y a X semaines).

Il est important de savoir quoi sauver et comment restaurer efficacement. Ça dépend donc de la stratégie employée (sauvegarde incrémentale ou pas, espace disque...).

Moviuro a écrit :Quels dossiers doivent être snapshottés pour éviter les inconsistances[1] ?

A minima, aucun, la liste des paquets étant suffisante pour réinstaller un système: https://wiki.archlinux.fr/Enhancing_Arc ... all.C3.A9s
Puis tu peux rajouter la base de données de pacman, https://wiki.archlinux.fr/Enhancing_Arc ... 9es_Pacman et éventuellement le cache si tu as la place (mais là, c'est selon la stratégie de restauration dont je parlais).

Tu y adjoins /etc pour toutes tes configurations persos et /home pour les données utilisateurs (un chroot pour réinstaller d'après la liste des paquets avec réinjection de /etc et zou, terminé).

/var et /boot si possible (/srv si ta machine fait serveur).

Moviuro a écrit :Quels dossiers peuvent être laissés tels quels malgré un rollback, notamment pour des questions d'espace disque[2] ?

Comme je disais... quasiment tous...

Tu peux totalement occulter /usr (qui abritent des données statiques qui pourront être remis en place via chroot/pacman).

OK, merci pour ces infos, mais, le but, c'est de pouvoir rollback en deux commandes, un reboot. Pas de réinstall. Par exemple, aujourd'hui je mets à jour avec pacman et après-demain, je me rends compte que (malheur !) tomcat est tout cassé, plus rien ne se lance et ça fonctionnait bien la semaine passée !

Donc hop, à grands coups de btrfs, je rollback <insérez ici la liste des dossiers>, je reboot et mon système est consistant, en date de la semaine passée. Fini.

La stratégie employée est toute simple : btrfs subvolume snapshot, question espace disque, c'est le top, mais pas question de snapshot-ter le cache pacman (et autres données inutiles) !

Comme /var contient des logs, je me pose la question de leur utilité : si je snapshot un log, il va prendre de la place pour rien

(je vais pas m'amuser à lire mon log journald du 6 juillet 2014 un autre jour que le 6 juillet 2014)
Pour /boot, j'ai une autre technique : j'ai une entrée backup (kernel 3.13 je crois) avec l'initramfs qui va bien : /boot/vmlinuz-linux-20140425 et /boot/initrd-linux-20140425.img. Et je me suis assuré que ça bootait bien. J'ai aussi, en plus, juste pour être vraiment sûr, le kernel LTS.

Supprimer /usr de mes snapshots, c'est pas du tout logique, puisque ça veut dire que je ne peux pas retourner mon système à l'état en date du <date>.

La question dont tu traites FoolEcho, c'est le "disaster recovery" : la machine casse physiquement ou le disque meurt. Effectivement, dans ce cas, il ne faut que /etc, /home, /srv et la liste des paquets.

Moviuro a écrit :La question dont tu traites FoolEcho, c'est le "disaster recovery" : la machine casse physiquement ou le disque meurt. Effectivement, dans ce cas, il ne faut que /etc, /home, /srv et la liste des paquets.

Pas du tout.
Cela s'applique aussi si tu veux dupliquer une machine en modérant le coût (coût en espace disque/coût en copie-recopie et temps/coût en ligne de commandes... l'ensemble est globablement plus avantageux que de refaire une installation/configuration de zéro ou une copie complète d'un système pour laquelle il faut avoir assez d'espace... et de temps, etc.).

Moviuro a écrit :Supprimer /usr de mes snapshots, c'est pas du tout logique, puisque ça veut dire que je ne peux pas retourner mon système à l'état en date du <date>.

Ça ne l'est pas dans la logique de restauration que tu souhaites et pourtant... ça l'est d'autant plus que /usr n'est valable à un instant t que par rapport à la liste des paquets installés, c'est elle qui prime et donc la base de données de pacman, pas l'inverse (et du coup, tu économises à avoir liste + cache de façon à réinstaller /usr en l'état).
Autrement, il peut être délicat de se passer de /var car c'est toute la partie dynamique des applications (enfin souvent...) même si effectivement tu peux te passer des logs, de tmp bien sûr... mais pas de données de certaines applications (mettons que tu aies un serveur sql ou ce genre de choses, à moins bien sûr de faire autrement...).

Maintenant si tu veux une stratégie plus spécifique, il faut détailler quelle est la tienne ou au moins les moyens que tu comptes mettre en œuvre et à disposition...

Le but de mes snapshots, c'est de pouvoir restaurer le système intégralement à une date antérieure (hors, éventuellement, documents personnels).
Ce but nécessite la restauration de /usr puisque c'est dedans qu'il y a le système.

Si pour une raison X ou Y un soft arrête de fonctionner (ou mon PC commence à déconner très sérieusement), je veux pouvoir instantanément revenir en arrière. Récupérer la liste des paquets ne me permet pas de faire ça et snapshot-ter le cache de pacman prendra beaucoup de place (pas possible de faire de l'incrémental sur des archives au niveau du FS).

Les seuls outils dont j'ai visiblement besoin, btrfs me les fournit (snapshot et mount).

FoolEcho a écrit :
Moviuro a écrit :Supprimer /usr de mes snapshots, c'est pas du tout logique, puisque ça veut dire que je ne peux pas retourner mon système à l'état en date du <date>.
Ça ne l'est pas dans la logique de restauration que tu souhaites et pourtant... ça l'est d'autant plus que /usr n'est valable à un instant t que par rapport à la liste des paquets installés, c'est elle qui prime et donc la base de données de pacman, pas l'inverse (et du coup, tu économises à avoir liste + cache de façon à réinstaller /usr en l'état).

D'où ma notion de consistance dans le premier post : je veux en deux commandes et un reboot être capable de revenir sans aucun souci (que ce soit pacman ou n'importe quoi d'autre) à une version fonctionnelle de ma machine.

Qu'est-ce qu'il est donc vital de snapshot-ter ?

/usr (normal, c'est le système)
/etc (normal, c'est la conf du système)
/var (puisque visiblement, il y a des données importantes dedans)
Pas les logs par contre, c'est inutile, ça prendra de la place et si je ne touche pas les logs lors d'un rollback, j'y garde accès (pour le temps de leur présence)
Pas /var/lock
Pas les caches de paquets, puisque les paquets sont installés et snapshot-tés dans les autres dossiers, et en plus, ça prend de la place

Dans ce cas, tu n'as pas trop d'autre option que tout prendre sauf le cache de pacman (qui sera la partie du système la plus lourde et qui effectivement ne te servira à rien).
Mais il te sera très long de faire la sauvegarde du sauvegarde (ce qui est fâcheux si tu veux le faire régulièrement, d'autant plus si btrfs n'a pas la possibilité de faire des sauvegardes incrémentielles) et de la remettre en place (enfin, tu n'auras qu'à faire l'essai ^^).

FoolEcho je ne suis pas sur de te suivre... Ce que demande Moviuro est tout à fait logique et normal.

Pour rappel la création d'un snapshot via btrfs est instantané comme son accès. Tout est l’intérêt de btrfs. Pour résumé son fonctionnement de manière simplifié :

Création d'un fichier A de 1 Mo, le contenu sera stocké physiquement dans 256 secteurs (s1, s2, ..., s256)
Création d'un snapshot, le fichier A sera stocké physiquement au même endroit dans le snapshot (fichier nommé As), c'est à dire dans les secteurs: s1, s2, ..., s256
Modification du fichier A (nommé A') avec un autre contenu de 1 Mo, le fichier As sera toujours dans les secteurs: s1, s2, ..., s256, mais le nouveau fichier A' sera stocké dans d'autres secteurs...

Sinon pour être totalement cohérent il faudra faire un snapshot de

Code : Tout sélectionner

etc home opt root srv usr var

Mais en effet les log ainsi que le cache de pacman n'est pas nécessaire. Et pour le home c'est très personnel, ce n'est pas forcément nécessaire...
Pour exclure des dossiers particuliers comme le cache de pacman il suffit de les mettre dans des sous volumes à part.
De toute façon tu ne peux pas faire un snapshot d'un dossier en particulier que je sache, cela fonctionne par sous volume, tu snapshot forcément tout le sous volume en entier.

Et pour finir, /var/lock n'est pas dans btrfs, c'est un lien symbolique vers /run/lock, hors /run est monté en tmpfs

Je ne connais rien à btrfs.

benjarobin a écrit :Sinon pour être totalement cohérent il faudra faire un snapshot de
Code : Tout sélectionner
etc home opt root srv usr var
Mais en effet les log ainsi que le cache de pacman n'est pas nécessaire. Et pour le home c'est très personnel, ce n'est pas forcément nécessaire...

Il y a aussi /var/tmp qui n'est pas à snapshot-ter (vu le nom, c'est pas tout à fait illogique).

La question devient donc : quel est le comportement que je dois adopter par défaut pour /var ? par défaut, je le snapshot-te sauf les sous-volumes tmp, abs, log et cache?
Ou justement, je considère qu'il ne faut pas snapshot-ter /var et seulement les sous-volumes db, lib, local, opt et spool?

Code : Tout sélectionner

__to_snapshot
 > var
__not_to_snapshot
 > vartmp
 > varcache
 > ...

ou

Code : Tout sélectionner

__to_snapshot
 > varlib
 > varlocal
 > ...
__not_to_snapshot
 > var

J'aurais tendance à dire la première solution (mieux vaut trop que pas assez en cas de catastrophe), mais la seconde ne semble pas si déconnante si on compte le nombre de dossiers à ignorer.

FoolEcho a écrit :Je ne connais rien à btrfs.

et moi encore moins, je fais des images de mes OS avec clonezilla chaque semaine

Bon, alors je vais m'y mettre dans quelques heures : j'utilise d pour un dossier créé avec mkdir et v pour un volume créé par btrfs:

Code : Tout sélectionner

**  SUBLEVEL 0
d root
d home
d var (utile ?)
d varcache
d vartmp
d git
d <videos de vacances>

Code : Tout sélectionner

** SUBLEVEL 1
v __active
v __hourly.0
v __hourly.1
v ...
v __daily.0
v ...

Me manque-t-il des trucs ? Est-ce que vous avez des idées à balancer ?
EDIT: OK, fini la migration vers la nouvelle architecture

Code : Tout sélectionner

# btrfs subvolume list -p /                             
ID 530 gen 83304 parent 5 top level 5 path home/__active
ID 531 gen 83304 parent 5 top level 5 path var/__active
ID 532 gen 83258 parent 5 top level 5 path git/__active
ID 533 gen 83290 parent 5 top level 5 path varcache/__active
ID 534 gen 83304 parent 5 top level 5 path varlog/__active
ID 535 gen 83292 parent 5 top level 5 path vartmp/__active
ID 537 gen 83303 parent 5 top level 5 path root/__active

Code : Tout sélectionner

# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/mapper/luks-c3c2fcfa-9265-4da7-a927-0a18d83d8d77 LABEL=btrfsroot
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /               btrfs   rw,noatime,ssd,space_cache,subvol=root/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache        0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /home           btrfs   rw,noatime,ssd,space_cache,subvol=home/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache        0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /srv/git        btrfs   rw,noatime,ssd,space_cache,subvol=git/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache 0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /var            btrfs   rw,noatime,ssd,space_cache,subvol=var/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache 0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /var/cache      btrfs   rw,noatime,ssd,space_cache,subvol=varcache/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache    0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /var/log        btrfs   rw,noatime,ssd,space_cache,subvol=varlog/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache      0 0
UUID=73b5d405-ed79-474c-bb6a-e6c137eb9dcd       /var/tmp        btrfs   rw,noatime,ssd,space_cache,subvol=vartmp/__active,compress=lzo,discard,autodefrag,space_cache,inode_cache      0 0


# /dev/sda1
UUID=4E18-863E  /boot   vfat    rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro  0 2

Je m'attelle de suite à la rédaction d'une unit pour prendre les snapshots !

Archlinux.fr [Forums]

[btrfs, snapshot, loi de Murphy] Dossiers à conserver

[btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver

Re: [btrfs, snapshot, loi de Murphy] Dossiers à conserver