/var/duplicity
peut être éventuellement un lien symbolique vers un autre chemin situé sur une partition plus adaptée quand celle où se trouve /var
ne convient pas au volume des données à sauvegarder
Le système de sauvegarde documenté ci-dessous utilisant duplicity
avec le wrapper duplicity-backup.sh
est en train d'être migré vers une nouvelle solution utilisant obnam
. (Zertrin 2016-02-14 23:15) NE PLUS UTILISER
Backup interserveurs en mode push a l'aide de duplicity et son wrapper duplicity-backup.
/root/scripts/duplicity-backup
/var/duplicity
1)/etc/duplicity-backup.<machine1>_to_<machine2>.conf
/etc/cron.daily/duplicity-backup
Pour consulter l'état actuel des sauvegardes de <machine1> vers <machine2> :
sudo /root/scripts/duplicity-backup/duplicity-backup.sh -c /etc/duplicity-backup.machine1_to_machine2.conf -s
hexagon → quigon (2015-09-14 21:00)
hexagon → baldrick (2015-09-14 21:00)
quigon → hexagon (2015-09-14 21:00)
quigon → baldrick (2015-09-14 21:00)
PAS ENCORE ADAPTÉ/MIS EN FORME : ne pas utiliser tel quel ! Mais l'idée générale y est et devrait suffire à reproduire.
Procédure à ne faire que si l'on part de zéro sur tous les serveurs (pas de backups en place)
Si au moins un des serveurs a déjà été configuré (voir procédure précédente) et qu'on désire préparer un autre serveur pour effectuer des sauvegardes via duplicity-backup.
Seulement si le serveur auquel on ajoute une nouvelle destination de sauvegarde a déjà été configuré une première fois (voir procédure ci-dessus).
Très important ! Chaque admin technique devrait générer ces sauvegardes pour lui-même et les conserver en lieu sûr (i.e. pas sur les serveurs où elles ont été générées). Sans ces données il sera difficile de restaurer les données. (et même impossible si les clefs GPG sont perdues)
Ces archives sont générées à l'aide de l'option --backup-script
du wrapper duplicity-backup.sh.
Ceci génère une archive TAR chiffrée symétriquement avec GPG. Le mot de passe utilisé est le même pour tous les serveurs et se trouve dans /root/passwords/duplicity-backup
Dans l'archive se trouve tout ce qui est nécessaire pour effectuer une restauration des données à partir d'un autre serveur (fichier de config + clefs GPG de signature et de chiffrement).
hexagon ~ # /root/scripts/duplicity-backup/duplicity-backup.sh -c /etc/duplicity-backup.hexagon_to_quigon.conf --backup-script You are backing up: 1. /root/scripts/duplicity-backup/duplicity-backup.sh 2. GPG Secret encryption key: 8B97F497 and GPG secret sign key: 9ED0EF7B 3. Config file: /etc/duplicity-backup.hexagon_to_quigon.conf Backup tarball will be encrypted and saved to: /root/duplicity-backup-2013-07-25.tar.gpg >> Are you sure you want to do that ('yes' to continue)? yes Encrypting tarball, choose a password you'll remember... IMPORTANT!! >> To restore these files, run the following (remember your password): gpg -d duplicity-backup-2013-07-25.tar.gpg | tar x
Dans tous les cas il est nécessaire de diposer de la clef de déchiffrement correspondant à la clef GPG 8B97F497
On suppose ici le cas où un fichier ou dossier a été modifié ou supprimé par mégarde et qu'on cherche à restaurer celui-ci tel qu'il était auparavant, le tout depuis le serveur d'origine.
C'est la situation la plus simple car duplicity-backup.sh a déjà été mis en place et est configuré.
Voici la commande générique :
serveur1 ~ # /root/scripts/duplicity-backup/duplicity-backup.sh \ --config /etc/duplicity-backup.<machinededépart>_to_<machinedarrivée>.conf \ --restore-file [FILE_TO_RESTORE] [DESTINATION] \ --time [TIME]
avec:
--restore-file
est équivalent à --restore-dir
. La procédure fonctionne de manière strictement identique pour restaurer un fichier ou un dossier.[FILE_TO_RESTORE]
de la forme relative/path/to/the/file/in/the/archive
[DESTINATION]
de la forme /path/to/where/to/place/the/restored/file
[TIME]
pour le format, cf la doc officielle. Exemples qui fonctionnent:1H30M
: il y a une heure et trente minutes12D
: il y a 12 jours“2015-12-01T00:00:00”
le 1er décembre 2015 à minuit
Exemple de restauration du fichier /etc/postfix/main.cf
tel qu'il était il y a 12 jours sur le serveur hexagon depuis le backup effectué sur quigon. Le fichier restauré est enregistré sous
.
/root/main.cf.restored
hexagon ~ #/root/scripts/duplicity-backup/duplicity-backup.sh -c /etc/duplicity-backup.hexagon_to_quigon.conf --restore-file etc/postfix/main.cf /root/main.cf.restored --time 12D
Exemple de restauration du dossier /etc/apache2
tel qu'il était il y a 1 heure et demi sur le serveur baldrick depuis le backup effectué sur hexagon. Le dossier restauré est enregistré sous
.
/root/etc-apache2.restored
baldrick ~ # /root/scripts/duplicity-backup/duplicity-backup.sh -c /etc/duplicity-backup.baldrick_to_hexagon.conf --restore-dir etc/apache2 /root/etc-apache2.restored --time 1H30M
On suppose ici que l'on a plus accès au serveur d'origine (exemple perte du disque-dur) et qu'on veuille restaurer les données sauvegardées sur une autre machine.
On suppose aussi que l'on dispose des éléments suivants :
--backup-script
du wrapper duplicity-backup.sh et la procédure est documentée ci-dessus.8B97F497
)Il est très important de s'assurer que ces éléments aient été bien conservés en dehors des serveurs (par exemple dans une base KeePass de plusieurs admin tech de FedeRez).
finir la doc. En attendant voici l'idée générale :
/var/duplicity
peut être éventuellement un lien symbolique vers un autre chemin situé sur une partition plus adaptée quand celle où se trouve /var
ne convient pas au volume des données à sauvegarder