Read this document in English: BackupGuideEN

Cette documentation est destinée à la gestion des backups par les clients, principalement des machines virtuelles et HAG.

Les admins système de Koumbit voudront plutôt consulter les pages suivantes:

Machines virtuelles

Si vous avez un serveur virtuel chez Koumbit et que vous avez un forfait de sauvegardes hebdomadaires, vous avez donc des backups RdiffBackup configurés avec BackupNinja.

Ne pas toucher aux fichiers de configuration de backupninja dans /etc/backup.d. Ils seraient ré-écrits par Puppet dans l'heure suivante et les changements seraient perdus!

Avant d'effectuer ce type d'opérations, assurez-vous d'avoir l'espace nécessaire!

borg

Information sur les points de backup

Lister les backups:

 $ sudo borg list ssh://backup-example.koumbit.net@backup.koumbit.net/srv/example.koumbit.net/borg
...
2020-06-01T05:00:04                  Mon, 2020-06-01 05:00:06 [03db2303c044b0d1fc50be19190c3ce566b9f912c994e37dce3c445ef63cabdc]
2020-06-02T05:00:04                  Tue, 2020-06-02 05:00:06 [e3833850d9969e2b40135e2fac4f9d88d80e0b664b92f0251417fe91cb4f854f]

Lister les informations de l'archive complète:

 $ sudo borg info ssh://backup-example.koumbit.net@backup.koumbit.net/backup/example.koumbit.net//borg
...
Repository ID: 9bf455a159d5d3fb15e6b2e385ed4d4ffc7f46ff4ddde191afecd14046ce086c
Location: ssh://backup-example.koumbit.net@backup.koumbit.net/backup/example.komubit.net/borg
Encrypted: No
Cache: /root/.cache/borg/9bf455a159d5d3fb15e6b2e385ed4d4ffc7f46ff4ddde191afecd14046ce086c
Security dir: /root/.config/borg/security/9bf455a159d5d3fb15e6b2e385ed4d4ffc7f46ff4ddde191afecd14046ce086c
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                5.63 TB              5.24 TB            573.24 GB

                       Unique chunks         Total chunks
Chunk index:                  587053              5766243

Lister les informations d'un backup en particulier:

 $ sudo borg info ssh://backup-example.koumbit.net@backup.koumbit.net/backup/example.koumbit.net//borg::2022-05-04T01:27:06
...
Archive name: 2022-05-04T01:27:06
Archive fingerprint: bc0efe69a527059d9a65ab55524d1ce239291a163a7d9a0b94cca19bea2b7d82
Comment: 
Hostname: example
Username: root
Time (start): Wed, 2022-05-04 01:27:08
Time (end): Wed, 2022-05-04 01:32:00
Duration: 4 minutes 51.88 seconds
Number of files: 545293
Command line: /usr/bin/borg create --stats --compression lz4 --exclude /dev --exclude '/home/*/.aMule' --exclude '/home/*/.beagle' --exclude '/home/*/.gnupg' --exclude '/home/*/.local/share/Trash' --exclude '/home/*/.thumbnails' --exclude '/home/*/.Trash' --exclude '/home/*/gtk-gnutella-downloads' --exclude /proc --exclude /run --exclude /sys --exclude /tmp --exclude /var/cache --exclude '/var/lib/ganeti/locks-*.tmp' --exclude '/var/lib/ganeti/queue/*' --exclude /var/lib/mysql --exclude /var/lib/postgresql --exclude /var/log --exclude /var/run --exclude /var/tmp 'ssh://backup-example.koumbit.net@backup.koumbit.net/backup/example.koumbit.net//borg::{now:%Y-%m-%dT%H:%M:%S}' /
Utilization of maximum supported archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:              797.45 GB            742.22 GB            596.15 MB
All archives:                5.63 TB              5.24 TB            573.24 GB

                       Unique chunks         Total chunks
Chunk index:                  587053              5766243

Accéder aux fichier dans un backup

Si on veut voir l'ensemble des fichiers d'un backup parce qu'on ne trouve pas ce qu'on cherche, il est possible de mounter un backup spécifique en FUSE (Filesystem in Userspace) :

$ sudo su
$ tmux
$ mktemp -d
/tmp/tmp.R7fMCamDDq
$ borg mount ssh://backup-example.koumbit.net@backup.koumbit.net/srv/example.koumbit.net/borg::2020-06-02T05:00:04 /tmp/tmp.R7fMCamDDq

Note Faire ça dans un tmux. Si le backup est large, le processus peut consommer du temps et mémoire important. (~16G RAM et 25min pour 2To)

Par la suite les fichiers peuvent être copiés normalement. Eg. rsync en local, cp -r, etc.

Démonter un dossier borg:

sudo borg umount /tmp/tmp.R7fMCamDDq

Extraire un fichier précis d'un backup

En admettant que le backup nommé borg est fait sur /srv/mon_dossier_backups/ et qu'on souhaite récupérer /srv/mon_dossier_backups/mon_site/mon_fichier.php dans le dossier courant (pour HAG ça serait .srv/alternc/html/...) :

sudo borg extract ssh://backup-example.koumbit.net@backup.koumbit.net/backup/example.koumbit.net//borg::2022-05-04T01:27:06 ./srv/mon_dossier_backups/mon_site/mon_fichier.php

rdiff-backup

Les backups sont stockés sur une machine accessible sous backup.koumbit.net. On assume ici que votre machine se nomme foo.koumbit.net, ce qui vous donne un nom d'utilisateur backup-foo.koumbit.net@backup.koumbit.net. Vous pouvez ensuite construire l'URL vers vos backups rdiff en ajoutant :: et le chemin vers les backups, donc par exemple: backup-foo.koumbit.net@backup.koumbit.net::/backup/foo.koumbit.net/rdiff-backup/.

Quelques exemples:

Obtenir les variables de configuration pertinentes pour un serveur

    cat /etc/backup.d/90_default-rdiff-backup.rdiff | grep -E "directory = |host =| user ="
TODO
faire une ligne qui permet d'extraire ces valeurs et de rouler la commande de backup sur CWD
Lister l'historique des backups
  • $ sudo rdiff-backup -l backup-foo.koumbit.net@backup.koumbit.net::/backup/foo.koumbit.net/rdiff-backup/
    Found 7 increments:
        increments.2014-12-30T03:01:50-05:00.dir   Tue Dec 30 03:01:50 2014
        increments.2014-12-31T03:02:04-05:00.dir   Wed Dec 31 03:02:04 2014
        increments.2015-01-01T03:02:00-05:00.dir   Thu Jan  1 03:02:00 2015
        increments.2015-01-02T03:01:45-05:00.dir   Fri Jan  2 03:01:45 2015
        increments.2015-01-03T03:02:04-05:00.dir   Sat Jan  3 03:02:04 2015
        increments.2015-01-04T03:01:47-05:00.dir   Sun Jan  4 03:01:47 2015
        increments.2015-01-05T03:01:32-05:00.dir   Mon Jan  5 03:01:32 2015
    Current mirror: Tue Jan  6 03:01:36 2015
Inclure l'espace utilisé dans le listing (plus long)
  • $ sudo rdiff-backup -l --list-increment-sizes backup-foo.koumbit.net@backup.koumbit.net::/backup/foo.koumbit.net/rdiff-backup/
Restaurer un répertoire
  • $ sudo rdiff-backup -r 2015-01-05T03:01:32-05:00 backup-foo.koumbit.net@backup.koumbit.net::/backup/foo.koumbit.net/rdiff-backup/home/antoine antoine
  • Ceci va extraire le répertoire personnel du user antoine tel qu'il était le 5 janvier 2015 à 3h du matin dans le répertoire courant.

Lister le contenu d'un backup
  • rdiff-backup --list-at-time 48h backup-foo.koumbit.net@backup.koumbit.net::/backup/foo.koumbit.net/rdiff-backup/

Noter qu'il est important d'utiliser sudo car seule la clé SSH du user root a accès au serveur de backups. Notez également les différents formats d'heures qui peuvent être utilisés, par exemple now (backup le plus récent), 48h (il y a deux jours) ou 2015-01-05T03:01:32-05:00 (date précise du backup).

Then sometimes you have to merge the directories you recovered with the ones that are still there. Especially with Mail, or example. Here is one I did:

$ ls -la | grep Maildir
drwxr-xr-x 11 foo admins     4096 nov  5 23:28 Maildir
$ sudo rsync -Pavvu --dry-run Maildir/ /var/alternc/mail/m/machin.foo_dude.ca/Maildir/

Pay attention to the / at the end of the directory paths, rsync cares about those. And then run it without the dry-run for realzies. Then don't forget to go properly chown all the recovered files!

$ sudo ls -la /var/alternc/mail/m/machin.foo_dude.ca/Maildir/
drwxr-xr-x 11 foo admins  4096 nov  5 23:28 .
drwxr-xr-x  3  2407 vmail   4096 jun 28  2010 ..
$ sudo chown -R 2407:vmail /var/alternc/mail/m/machin.foo_dude.ca/Maildir/

HAG

Tel que mentionné sur la description du service d'hébergement partagé :

Nous faisons des copies de sauvegarde (backups) de tout l’hébergement partagé (bases de données, fichiers, courriels). Toutefois, des frais seront facturés si vous avez besoin que l’on fasse une restauration de backup pour vous. Nous conservons des copies quotidiennes pendant 5 jours, et des copies hebdomadaires pendant 6 mois dans un deuxième lieu physique, en cas de panne majeure.

Veuillez donc nous aviser rapidement si vous avez besoin d’une restauration de backup ! À noter que la restauration d'une sauvegarde de plus de 5 jours est plus complexe et coûte plus cher à faire.

Fichiers et NFS

voir BackupMaintenance#Files

Bases de données

voir BackupMaintenance#Databases

Courriels

Voir BackupMaintenance#Emails

BackupGuide (last edited 2026-05-04 11:49:58 by nina)