Journal Bricolage pour faire des sauvegardes

Posté par  . Licence CC By‑SA.
Étiquettes :
22
6
jan.
2019

Sommaire

J’aime archiver tout ce qui bouge, et j’aime bien l’idée de ne rien perdre si mon ordinateur tombe en panne MAINTENANT. Dans ce journal, je vais décrire comment je gère mes sauvegardes, des personnes ici se sont montrées intéressées.

Attention, je vous préviens tout de suite : c’est un système de sauvegarde bricolé maison à base de cron et de scripts shell dégueulasses. Ce n’est pas un tutoriel, donc c'est écrit dans un style « je raconte ma vie ».

Bonne lecture !

Prérequis

Voici ce que j'attends de mon système de sauvegardes.

  • Éviter de sauvegarder doit être une opération consciente. Je ne dois pas à avoir à penser à faire mes sauvegardes sauf pour vérifier occasionnellement que tout fonctionne, et ça doit être dur de perdre quelque chose.
  • Aussitôt écrit sur le disque, aussitôt c’est sauvegardé (sauf conditions spécifiques).
  • Utilisation de logiciels libres uniquement.

Matériel

Voici le matériel dont je dispose :

  • Un ordinateur, sous GNU/Linux, dans une maison sur une connexion domestique à la campagne avec un disque dur de 4 Tio
  • Un disque dur externe de 4 Tio
  • Un serveur virtuel quelque part
  • Mon ordinateur, sous GNU/Linux, mais on s’en fout un peu.

Le serveur virtuel sert à diverses choses. Il héberge notamment quelques sites et mes mails. L’ordinateur dans la maison, il est là pour recevoir des calculs de temps à autres. On peut les utiliser sans gros surcoût économique ou énergétique puisqu’ils sont déjà utilisés pour autre chose.

Sauvegarde immédiate, avec versionnage « opportuniste »

Pour cela, j’ai une instance de NextCloud qui tourne sur le serveur virtuel, et un client OwnCloud sur mon ordinateur. Mon dossier « Documents » est en fait un lien symbolique vers un dossier du dossier OwnCloud. Les téléchargements et autres fichiers un peu lourds ne sont pas sauvegardés comme ça.

Dès que j’écris un truc sur le disque, OwnCloud le détecte et envoie ça sur le serveur. Si un fichier est modifié plusieurs fois d’affilée, généralement NextCloud ne supprime pas tout de suite l’ancienne version : il maintient plusieurs versions de ce fichier. Chaque version peut être téléchargée ou restaurée depuis l’interface Web de NextCloud. Ces versions sont automatiquement supprimées quand NextCloud considère qu’il y a besoin de récupérer de l’espace libre.

Ce versionnage un peu automatique a sauvé mes fesses plusieurs fois pour des conneries à court terme.

Ouvrir un autre ordinateur avec le client OwnCloud / NextCloud installé me permet d’obtenir une sauvegarde additionnelle un peu gratuitement et sans effort.

À lui seul, ce mécanisme de sauvegarde n’est pas suffisant : une mauvaise modification / suppression sur des fichiers dont les versions ont été perdues et c’est foutu. La modification est propagée sur le serveur, sauf à débrancher internet très rapidement mais le processus de synchronisation peut s’avérer redoutablement rapide et efficace dans ce genre de situation.

Un système de synchronisation tel que NextCloud ou Dropbox n’est donc pas un bon système de sauvegarde à lui seul parce que les conneries sont synchronisées, elle aussi, même si le versionnage un peu opportuniste peut occasionnellement servir de filet de sauvetage un peu troué en cas de saut à pieds joints dans le vide.

Condition particulière où je suis en roue libre : absence de connexion internet. C’est plutôt rare et pas sur une longue période. Il est toujours possible d’utiliser une clef USB ou un disque dur externe pour un truc vraiment important.

Sauvegarde à plus long terme, incrémentale

Chaque nuit, l’ordinateur de la maison se réveille et une tâche cron lance rsync pour récupérer les modifications sur le serveur depuis la nuit dernière dans un dossier de son disque interne (dans mon $HOME, disons /home/raphj/vps).

Rien qu’avec ça, je ne peux plus perdre plus de 24h de travail au pire des cas en cas de fausse manipulation.

Mais ce n’est pas tout. Une connerie, on peut s’en rendre compte le lendemain. À ce moment là c’est trop tard, elle a été successivement propagée sur le serveur virtuel, puis à la maison.

L’astuce, elle est ici : le disque dur externe de l’ordinateur de la maison est formaté en Btrfs (à noter que ça devrait aussi marcher avec Zfs).

La première fois, un sous volume Btrfs est créé et le contenu du $HOME est copié dedans avec rsync:

btrfs subvolume create /mnt/sauvegardes/@

puis:

rsync -azp --delete "/home/" "/mnt/sauvegardes/@/"

Et enfin, on crée un instantané :

btrfs subvolume snapshot -r "/mnt/sauvegardes/@" "/mnt/sauvegardes/@-$(date "+%Y-%m-%d.%H.%M.%S")"

Ainsi, la nuit du 4 janvier, on a le sous-volume suivant qui est créé : /mnt/sauvegardes/@-2019-01-04.01.03.54

La nuit suivante, rebelote, le serveur virtuel est sauvegardé :

rsync -azp --delete "/home/" "/mnt/sauvegardes/@/"

Et on lance rsync pour mettre à jour son contenu :

btrfs subvolume snapshot -r "/mnt/sauvegardes/@" "/mnt/sauvegardes/@-$(date "+%Y-%m-%d.%H.%M.%S")"

Et on a un beau sous-volume @-2019-01-05.01.03.42 qui ne prend pas beaucoup de place sur le disque dur (seule les différences sont stockées), mais qui donne l’impression d’être complète.

Limitations et problèmes potentiels

Ça marche plutôt bien

Cela fait plus d’un an que je fonctionne comme ça. Ce système fonctionne bien, et il devient difficile de perdre des données. De fait, j’ai une copie de mes fichiers tels qu’ils étaient chaque jour depuis un an, 2 copies de mes fichiers tels qu’ils sont maintenant, et plus ou moins 4 copies physiques récentes de mes fichiers sans y penser (une sur mon ordinateur, une sur le serveur virtuel, deux sur l’ordinateur de la maison sur deux disques durs différents).

Mais attention aux pannes silencieuses

Comme tout système plus ou moins automatiques, c’est bien sauf quand ça cesse de fonctionner silencieusement. Les deux soucis qui me sont arrivés sont :
- le client NextCloud qui cesse de fonctionner, parce que je me suis déconnecté ou un problème d’installation. C’est rare mais ça peut arriver
- une modification dans mes scripts de sauvegarde sur l’ordinateur de la maison qui casse le mécanisme.

J’ai donc un trou de deux trois mois dans mes sauvegardes. Sur ce moment, seule la sauvegarde immédiate me couvrait. En général, quand le client NextCloud cesse de fonctionner, on finit par s’en rendre compte au bout de quelques jours au pire.

Et à l’utilisation de Btrfs

Tout le monde n’a pas totalement confiance en Btrfs. Et le jour où la partition se retrouve foirée, ça peut être un peu la galère à cause des sous-volumes. Btrfs vient cependant avec des outils de restauration avancés et c’est décrit ici : https://linuxfr.org/users/raphj/journaux/btrfs-restore-a-la-rescousse

Zfs, peut-être plus robuste, pourra probablement être utilisé à la place (surtout si l’ordinateur n’est pas sous Linux, mais plutôt BSD ou autre système avec une prise en charge de Zfs). Fonctionnalités importantes / intéressantes pour le système de fichier utilisé :

  • sous volumes et instantanés (et système de copie à l’écriture)
  • compression transparente (éventuellement)
  • déduplication

On pourrait probablement s’en sortir avec un système de fichier sans ces fonctionnalités en bidouillant avec les liens matériels (hard links).

Calcul, transferts et stockage des différences entre fichiers et instantanés

En fait, ça se fait plutôt bien, c’est rsync qui ne modifie que ce qui a été modifié. Mais ce n’est pas parfait. Actuellement, si un fichier est modifié, déjà NextCloud le renvoie entièrement au serveur, et pas seulement les blocs différents. Ensuite, je suppose que dans beaucoup de cas, rsync récupère à nouveau le fichier entier (si une modification a lieu au début d’un fichier et qu’elle change sa taille par exemple). Aussi, pour les fichiers qui n’ont pas été modifiés, Btrfs fait de la déduplication par blocs, et pas par fichier. Mais ça n’a pas l’air d’être un gros problème. Enfin, si un dossier est déplacé, NextCloud comme rsync vont tout transférer à nouveau, et Btrfs ne va pas dédupliquer. Des outils permettent de dédupliquer, mais ça n’a pas l’air très facile à utiliser et calculer la déduplication est plutôt coûteux. Je n’ai pas mis ça en place.

Confidentialité

Là, il faut faire confiance à l’hébergeur qui fournit le serveur virtuel. De toute façon, j’héberge mes mails et ce n’est pas vraiment possible pour le moment sans une connexion à Internet un minimum professionnelle. L’installation décrite ici pourrait être faite avec un serveur hébergé chez soi ou ailleurs, ou directement sur l’ordinateur à domicile, mais là attention à avoir ses données à plusieurs endroits différents, et aussi, une connexion internet domestique peut être lente dans le sens montant.

Utilisation des ressources (bande passante)

Avec ce système, il est clair que je transfère des deltas de ma vie plusieurs fois par jour sur internet. Je développe des programmes et j'écris des trucs, donc j’enregistre assez souvent des petits fichiers. Un enregistrement = un transfert, puis tout est transféré à nouveau dans la nuit. Les transferts, ça coûte un peu d’énergie même si ce n’est probablement pas énorme.

Maintenant, si vous écoutez une radio internet toute la journée ou que vous regardez une ou deux vidéos sur internet, la différence n'est peut-être pas si grande.

Bonus

Performances de la synchronisation NextCloud

À la campagne, l’envoi de données peut mettre la connexion à genoux. Les personnes qui partagent la connexion avec vous ne vont pas être contentes et vous-même n’allez pas apprécier surfer dans ces conditions.

Le client NextCloud est capable de limiter le débit d’envoi, et c’est très appréciable.

Sauvegardes des SMS / MMS et du journal d’appels

C’est couvert ici : https://linuxfr.org/users/raphj/journaux/sauvegarde-des-sms-mms-et-du-journal-d-appels-sous-android

Naturellement, cette sauvegarde est faite dans mon dossier NextCloud, donc il bénéficie de tout ce qui est décrit dans ce journal

Sauvegardes de la liste de lecture musicale

find ~/Musique -type f > ~/.ownCloudFolder/musiques-liste

:-D

Sauvegardes des photos, vidéos

Je n’ai pas assez d’espace sur mon serveur virtuel pour ça, alors je copie avec rsync depuis mon ordinateur sur l’ordinateur de la maison quand j’y suis. Ces trucs ne sont qu’à deux endroits et demie différents : ces deux ordinateurs et sur le disque dur externe.

Sauvegarde du serveur

En fait, mon script de sauvegarde du serveur virtuel fait un peu plus que du rsync. Il lance plusieurs processus par SSH pour sauvegarder les bases de données notamment. Un tunnel SSH est utilisé pour ne pas avoir à ouvrir et fermer la connexion SSH à chaque commande.

Cette sauvegarde devrait me permettre de reconstruire un serveur manuellement assez facilement (je gère mes configurations à l’ancienne, directement en production, en tâtonnant - ces configurations sont sauvegardées la nuit prochaine et si je me foire je peux consulter les versions précédentes et faire des diffs pour regarder ce qui a bougé d’un jour à l’autre).

Voici une simplification de ce que j’utilise :

#!/usr/bin/env sh

set -euf

BACKUP_TARGET="$(dirname "$(realpath "$0")")"/@
SSH_USER="root"
SSH_HOST="xxx"
SSH_PORT="xxx"

SSH_CONTROL_PATH="$HOME/.ssh/backup-%r-%h-%p-$(date +%s)"

#### ESTABLISH THE SSH CONNECTION ####
ssh -fN -p "${SSH_PORT}" -oControlMaster=yes -oControlPath="${SSH_CONTROL_PATH}" "${SSH_USER}"@"${SSH_HOST}"

#### DPKG/APT ####

#http://askubuntu.com/questions/9135/how-to-backup-settings-and-list-of-installed-packages

echo "Prepare Backup: DPKG and APT"

ssh -oControlMaster=no -oControlPath="${SSH_CONTROL_PATH}" \
    -p "${SSH_PORT}" \
    "${SSH_USER}"@"${SSH_HOST}" '
    mkdir -p /backups/apt;
    dpkg --get-selections > "/backups/apt/package.list";
    apt-key exportall > "/backups/apt/repo.keys"
'


#### MYSQL ####
echo "Prepare Backup: MySQL"

ssh -oControlMaster=no -oControlPath="${SSH_CONTROL_PATH}" \
    -p "${SSH_PORT}" \
    "${SSH_USER}"@"${SSH_HOST}" '
    mkdir -p /backups/mysql;
    mysqldump --events --routines --triggers --all-databases > /backups/mysql/dump.sql
'

#### DOVECOT ####
# echo 'Prepare Backup: Dovecot'

# ssh -oControlMaster=no -oControlPath=${SSH_CONTROL_PATH} \
#     -p "${SSH_PORT}" \
#     "${SSH_USER}"@"${SSH_HOST}" '
#     mkdir -p /backups/dovecot/
#     doveadm backup /backups/dovecot/
#     '

#### FOLDERS ####
echo "Backup: Folders…"

while read i; do
    i="$(printf "%s" "${i}" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"

    if [ -z "$i" ]; then
        continue;
    fi

    echo "Backup: '$i'"

    dest="${BACKUP_TARGET}""$i"

    mkdir -p "${dest}"

    rsync -avzp --delete --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys --exclude=/run --exclude=/var/run --exclude=/home/raph/.cache --exclude=/var/cache/apt/ \
              -e "ssh -oControlMaster=no -oControlPath='${SSH_CONTROL_PATH}' -p ${SSH_PORT}" \
              "${SSH_USER}@${SSH_HOST}":"$i/" \
              "${dest}/"
done < "$(dirname "$(realpath "$0")")/folders-to-backup.txt"

date > "$(dirname "$(realpath "$0")")/LAST_UPDATED"

#### CLOSE SSH ####

ssh -O exit -oControlMaster=no -oControlPath="${SSH_CONTROL_PATH}" -p "${SSH_PORT}" "${SSH_USER}@${SSH_HOST}"

ssh -oControlMaster=no -oControlPath="${SSH_CONTROL_PATH}" \
    -p "${SSH_PORT}" \
    "${SSH_USER}"@"${SSH_HOST}" '
    exit

Économie d’énergie

Le serveur virtuel sert des sites web et des mails, donc il est de toute façon allumé en permanence. Mon ordinateur est en veille quand je ne m’en sers pas, ce qui n’arrive jamais.

L’ordinateur de la maison, lui, passe son temps à ne rien faire. J’ai mis en place un système qui détecte si personne n’utilise la machine toutes les 10 minutes. Si c’est le cas, l’ordinateur parque la tête de lecture du disque dur externe, se met en veille et se réveille dans la nuit pour lancer le processus de sauvegardes ou quand il reçoit un paquet magique (Wake on Lan). Avant de s’endormir, l’ordinateur programme le routeur pour que celui-ci lui envoie un paquet magique à la réception d’une requête HTTP spécifique sur un port spécifique, depuis internet ou depuis le réseau local.

C’est un peu délicat et fastidieux à mettre en place au début et implique beaucoup de bidouillage. On serre un peu les fesses pour que ça marche, parce que si l’ordinateur ne se réveille pas une nuit, pas de sauvegarde cette nuit-là. Mais force est de constater que ça fonctionne, finalement. Il a pu aussi arriver qu’un processus utilisateur traîne et empêche la machine de se mettre en veille, ce qui consomme de l’énergie et fait du bruit pour rien.

Voilà, j’espère que vous pourrez trouver de l’inspiration dans ce journal pour votre propre système de sauvegarde :-)

  • # Vérification de la sauvegarde

    Posté par  (site web personnel) . Évalué à 4.

    Il te manque un processus de vérification de la sauvegarde. Il devrait vérifier la disponibilité des données, indépendamment de la sauvegarde. Il faudrait faire des restauration périodiques.

    Chiffrer les données est un plus. En particulier avec Gnupg puisqu'on peut chiffrer sans entrer la phrase de passe.

    • [^] # Re: Vérification de la sauvegarde

      Posté par  . Évalué à 3.

      Le processus de vérification est manuel : je vérifie périodiquement que les fichiers sont là. Je m’en sers aussi de temps en temps, parce que j’ai envie de consulter ou restaurer une version précédente d’un fichier. Mais effectivement, rien de très rigoureux.

      Pour ce qui est de la restauration, si jamais mon serveur tombe en rade ça sera une réinstallation manuelle. Mettre en place un système de restauration un peu automatique serait certainement trop lourd à mon niveau pour le moment. De toute façon je ne pourrais pas trop restaurer automatiquement les choses depuis la maison, la connexion montante est trop faible pour ça, et le faire périodiquement voudrait certainement dire d’avoir un serveur virtuel additionnel.

      Pour ce qui est du chiffrement, il faudrait voir quelle attaque elle préviendrait : mon serveur virtuel doit de toute façon pouvoir accéder aux données, donc la clé serait quelque part dessus. La seule manière pour le moment d’accéder aux données est de rentrer dans le serveur, mais à ce moment il est possible d’accéder à la clé.

      Idem pour l’ordinateur de la maison. Je pourrais chiffrer le disque dur externe au cas où il serait volé et l’ordi non, mais ça ne facilite pas une restauration des données en cas de problème avec le système de fichiers.

      L’ordinateur portable sera chiffré à un moment donné, c’est probablement ce que je suis le plus susceptible de me faire voler.

      Merci pour le commentaire ! Ce sont des éléments importants et si je pouvais modifier mon journal je rajouterais tout ça.

  • # Mine

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 06 janvier 2019 à 12:34.

    Un peu dans la même idée, j'ai deux machines:

    Mes documents perso:

    • Tout mes documents sont synchronisés par Syncthing sur toutes mes machines perso, avec une copie sur mon dédié.
    • Toutes les nuits, le dédié fait une sauvegarde dans un .tar.gz de tout mes documents. Il .tar.gz aussi mes mails (ceux-là ne sont pas synchronisés).
    • Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi les .tar.gz de la nuit d'avant.

    Les services hébergés sur mon dédié (site web perso, openpaper.work, etc):

    • Là, je peux me permettre 1 semaine de perte sans que ce soit trop grave. C'est surtout les installations et configurations que je veux sauvegarder plus que les données elles-même. La plupart des donnés sont soit sur Git soit je m'en fiche un peu (flux RSS, etc).
    • Chaque service tourne dans son propre conteneur LXC (--> plusieurs Apache, 2 MariaDB, etc).
    • Une fois par semaine, un à un, un script les arrête, en fait un .tar.gz, et les relance.
    • Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi une copie des .tar.gz de la semaine précédente.

    À l'occasion, il faudra que je regarde pour utiliser duplicity pour faire des sauvegardes incrémentales.

    Il y a sûrement moyen de faire plus efficace. Par exemple je pourrais éviter la coupure temporaire des conteneurs LXC. Mais pour l'instant c'est la solution la plus simple que j'ai trouvée. Avec cette approche, je n'ai pas à me soucier si un service tourne et pourrais corrompre la sauvegarde, ni à faire de méthode de sauvegarde spécifique à chaque service (cf MariaDB).

  • # burp

    Posté par  . Évalué à 5. Dernière modification le 06 janvier 2019 à 13:30.

    Pour info, burp fait chez moi des sauvegardes incrémentales et compressées sur une partition à distance chiffrée (on pourra ajouter des serveurs pour plus de redondance). Aucun besoin de script, juste d'installer burp sur le client et le serveur et de lancer le client à intervalles réguliers.
    Ça a l'air de remplir l'intégralité de ton cahier des charges, à part peut-être l’instantanéité, même si on peut choisir finement les intervalles jusqu'à une résolution d'une seconde. Ceci dit, je n'ai jamais rencontré un cas de figure où je perdais immédiatement des données que je venais de créer (à part peut-être professionnellement du code, mais il y a git pour ça).
    On peut même vérifier régulièrement l'intégralité de la sauvegarde depuis le client.

    • [^] # Re: burp

      Posté par  . Évalué à 4. Dernière modification le 06 janvier 2019 à 16:33.

      Très bien BURP pour ce que j’ai pu tester il y a de ça quelques années. Très bon concurrent du vénérable Bacula. Il a l’avantage d’être plus simple à mettre en œuvre que Bacula, donc pas forcément overkill pour la sauvegarde d’un seul poste de travail.

      Pour mon dernier laptop je me suis mis à Back In Time dont je trouve l’interface graphique très bien. Ça utilise rsync et scp dans les coulisses. C’est ultra-simple à utiliser.

  • # PRA

    Posté par  . Évalué à 4.

    bonjour et merci pour ce retour d'expérience, concernant en particulier BTRFS.

    Pour ma part, j'ai mis en place un mécanisme permettant de dupliquer l'ensemble de nos sauvegardes, avec rsync. Les données arrivent sur un serveur dédié qui à terme sera sorti de notre salle serveur et localisé quelques centaines de mètres plus loin. C'est pour cela qu'on l'appelle PRA, bien qu'on ne se concentre que sur les données.

    Les données sont collectées sur une grosse partition BTRFS de 20To extensible à 40 via LVM. Nous avons actuellement une volumétrie de 17To pour 15 millions de fichiers. Je réalise, via un script un snapshot quotidien et efface les snapshots les plus anciens. Je n'en garde que 30. Les opérations de snapshot sont pratiquement instantanées : entre 2 et 5 secondes pour la création et moins de 30ms pour la suppression.

    Le couple BTRFS + rsync me semble un très bon remplacement à RSYNC + rsnapshot. Le premier permet en théorique de faire des synchros différentielles par blocs avec rsync (--inplace --no-whole-file), ce que ne permet pas rsnapshot qui ne peut en aucun cas opérer sur les snapshots en mode différentiel (contrairement à BTRFS). L'organisation en layers de BTRFS permet de conserver 2 copies d'un même fichier en différentiel par bloc.

    concernant la supervision, j'ai mis en place sur certains volumes, la création d'un fichier .backup-timestamp créé par une tache cron. Il suffit de surveiller l'age de ce fichier pour lever une alarme si celui-ci prend de l'age de façon inexpliquée. J'ai couplé cela avec le plugin telegraf/filestat :

    marc$ cat input.filestat.conf
# https://docs.influxdata.com/telegraf/v1.9/plugins/inputs/#filestat
# Read stats about given file(s)
[[inputs.filestat]]
  files = ["/extra/backup/*/.backup-timestamp"]
  interval = '1d'

    concernant BTRFS, j'évite de m'appuyer sur les fonctionnalités avancées : la gestion des volumes est faite par LVM. Le RAID est géré matériellement. Cela m'évite d'avoir des soucis avec les bugs résiduels liés à la maturité de BTRFS. Je dois encore expérimenter la fonctionalité send/receive. J'aimerai bien faire mettre en place un snapshot de type hourly localement sur chacune de nos machines en réseau : un snapshot local est pratiquement instantané et n'induit aucune charge réseau. Il ne reste plus qu'a envoyer sur les serveurs de backup une daily pendant la nuit.

    J'ai expérimenté le couple restic + rest-server. J'ai eu quelques déconvenues et par ailleurs, la sauvegarde génère une charge CPU non négligeable, mais non apparente sur nos applications.

  • # Très inéteressant

    Posté par  . Évalué à 4.

    Personnellement je suis passé l'an dernier à tarsnap. L'intérêt principal pour moi c'est que ce n'est pas moi qui maintiens les backup. Donc ça évite qu'une défaillance complète de l'admin sys fasse exploser à la fois ma machine et celle qui contient les sauvegardes. Le prix est pas mauvais je trouve et j'ai mis en place un script lancé par NetworkManager quand il trouve une connexion. Il regarde liste les anciennes sauvegardes et supprime celles qui sont trop vielles (je garde une semaine et au minimum 5 sauvegarde - je n'utilise pas mon ordinateur tous les jours -).

    La sauvegarde de mon ${HOME} prend 6 minutes pour environ 50Gio.

    Il faudrait que je mette en place un backup des données de mon serveur, mais ça reste à faire. Je pense utiliser l'un de mes RPi pour ça.

  • # Borg

    Posté par  . Évalué à 5.

    de mon coté j'utilise borg backup. Simple, efficace. Je recommande.

    • [^] # Re: Borg

      Posté par  (site web personnel) . Évalué à 2.

      Moi aussi j'utilise borg habillé d'un script lancé toutes les nuits. Je suis content de cet outil pour sa simplicité d'utilisation, la sauvegarde moyennant seulement un compte ssh, le chiffrement et la déduplication (donc sauvegarde incrémentale).

      Fonctionnellement j'ai un laptop synchronisé avec unison pour une partie des données et seafile pour une autre partie des données plus bureautique, avec un serveur à la maison. Une sélection des données de ce serveur (/etc, /home, /var/lib/ par exemple) est sauvegardée toutes les nuits sur un autre disque dur du même serveur avec une profondeur de plusieurs mois (en cas de panne matérielle disque dur mais aussi pour pouvoir revenir en arrière) et chez un pote dans une autre région qui fait de même avec une profondeur de 10 jours (en cas de cambriolage, incendie).

      Une fois à la suite d'une fausse manipulation j'ai perdu des données qui n'étaient pas identifiées comme à sauvegarder, du coup maintenant j'apporte une grande attention à cette liste.

      • [^] # Re: Borg

        Posté par  . Évalué à 2.

        Moi aussi j'utilise borg habillé d'un script

        Pourquoi ne pas utiliser bormatic ?

  • # Restic

    Posté par  (Mastodon) . Évalué à 3. Dernière modification le 07 janvier 2019 à 08:51.

    Pour ma part j'utilise Restic pour faire une sauvegarde de mon home directory de mes laptops, le tout est chiffré et envoyé sur un stockage compatible s3 dans le nuage de chez Wasabi.

    À l'origine je faisais des backups sur des disques externes dont je faisais une rotation entre la maison et le bureau mais depuis que j'utilise quasi exclusivement des laptops et que mon raspberrylike est utilisé comme DAC et serveur media/DLNA/Airplay j'ai rien qui tourne 24hx7. J'aimerai quand même remettre en place une copie locale, il faut que j'investisse dans un remplacement de mon NAS qui est maintenant éteint. Je paye presque "dans le vide" un abo crashplan business juste parce qu'il contient encore les données de mon NAS au cas où au redémarrage je ne retrouve plus les données.

    • [^] # Re: Restic

      Posté par  . Évalué à 2.

      Pour ma part j'utilise Restic pour faire une sauvegarde de mon home directory de mes laptops, le tout est chiffré et envoyé sur un stockage compatible s3 dans le nuage de chez Wasabi.

      C'est intéressant. Ils ont l'air moins chère que tarsnap.

  • # Le backup c'est bien, les restorations c'est mieuc

    Posté par  . Évalué à 0.

    Il ne faut pas oublier que faire des sauvegardes n'a d'utilité "QUE" de restaurer les données. Cela été auparavant. Rsync a ceci de très interessant que la sauvegarde…
    tout comme la restoration ne nécessite pas le lancement de multiples processus. Maintenant, il serait interessant d'intégrer un indexation des fichiers sauvegardés pour faciliter la restore. On peux imaginer rsync au dessus d'un sqlite ou mariadb avec une belle interface ncurse pour lancer "restore moi annakounikova.jpg du 4 mai 2000 à tel endroit", et cela faciliterait la sauvegarde à plusieurs endroits et les duplications

    • [^] # Re: Le backup c'est bien, les restorations c'est mieuc

      Posté par  . Évalué à 2. Dernière modification le 08 janvier 2019 à 22:26.

      J'ai déjà une belle interface pour la restauration d'un fichier spécifique :

      cd /mnt/sauvegardes/@date/chemin…/
      get fichier

      Qu'est-ce que la base de donnée ajouterait ?

      En ce qui concerne le fait de ne pas oublier la restauration, oui c'est très important, cf mon commentaire précédent.

      • [^] # Re: Le backup c'est bien, les restorations c'est mieuc

        Posté par  (Mastodon) . Évalué à 3.

        Si ton fs de sauvegarde est continuellement monté ou dans la fstab on peut difficilement appeler ça une sauvegarde.

        • [^] # Re: Le backup c'est bien, les restorations c'est mieuc

          Posté par  (site web personnel) . Évalué à 1.

          Et pourquoi donc ?

          Comme l’ont déjà montré plusieurs commentaires, il y a plusieurs sortes de sauvegardes, répondant à des objectifs différents ; notamment :

          • rapidement accessible (facilité, latence, débit) pour consulter l’historique, revenir en arrière, etc.
          • hors-site mais plus lourd à gérer, pour prévenir contre les vols, incendies, inondations, etc.

          Une sauvegarde montée en permanence ne signifie donc pas qu’elle est inutile : elle est peut-être simplement de la première sorte.
          À noter : les deux sont complémentaires, pas exclusifs.

          Il est par contre certain qu’il ne serait pas sage de laisser ce montage en lecture-écriture, mais avec tous les outils désormais disponibles dans Linux pour partitionner les droits, il est relativement aisé de faire en sorte que le point de montage soit en lecture seule pour tout le monde sauf pour l’outil de sauvegarde.

          Une petite remarque aussi : la notion de local ou « remote » est relative. Par exemple, mon PC est sauvegardé sur mon serveur… et mon serveur est sauvegardé sur mon PC, de manière incrémentale et montée en permanence ; j’ai donc chaque donnée en 2 exemplaires, à 2 endroits distincts. Malgré le montage permanent sur mon PC, cette seconde sauvegarde est bien de type « remote » puisqu’elle n’est pas sur le serveur lui-même ;-)

        • [^] # Re: Le backup c'est bien, les restorations c'est mieuc

          Posté par  . Évalué à 1.

          Clairement, si mon disque dur qui contient les instantanés tombe en panne, je perd l'historique. Il me reste, sur la même machine, la sauvegarde du serveur.

          Si jamais il y a un problème sur la machine et que je perds tout, j'ai toujours le serveur que je peux re-sauvegarder.

          Si, pas de bol, mon serveur virtuel tombe en panne au même moment (ça devient improbable, mais bon, pourquoi pas, une erreur spectaculaire impliquant SSH touchant les deux machines n'est pas impossible), je perds la configuration du serveur et ça sera beaucoup plus long à tout reconstruire. Je perds aussi les courriels qui n'ont pas été stockés par Thunderbird.

          À savoir aussi qu'en réalité, mes instantanées sont en lecture seule, donc c'est monté, mais intouchable même par root, sauf à faire du dd sur le périphérique.

          Mes données importantes sont encore sur mon ordi et, sur d'autres machines sur lesquelles mon client NextCloud est installé, potentiellement dans une version un peu plus ancienne.

          Globalement, je trouve que les risques de perdre mes données actuelles sont très limités.

          Ce que je peux améliorer :

          • télécharger régulièrement une copie de mes mails / de la conf du serveur sur mon ordinateur. Je vais peut-être le faire d'ailleurs.
          • acheter un nouveau disque dur externe sur lequel je sauvegarde aussi le serveur.

          Au lieu d'avoir trois copies dont deux sont sur la même machine, ça permettrait d'avoir 4 ou 5 copies dont 2 sur le même ordinateur.

          De là à dire qu'il ne s'agit pas d'une sauvegarde, il y a un pas. Le mécanisme fait partie d'un ensemble plus grand, à lui seul il ne suffit pas je suis d'accord. Petit rappel aussi : je suis un particulier, je ne gère pas les sauvegardes d'une entreprise.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.