Journal Sauvegarde de données

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
21
9
nov.
2020

'lut nal,

Vous me direz encore un journal sur la sauvegarde de données alors qu'il en existe tant d'autres. Mais il n'est jamais inutile de rappeler à tel point il est utile et nécessaire de ne pas négliger ce point et c'est souvent malheureusement suite à une mauvaise expérience qu'on s'en préoccupe sérieusement, et c'est malheureusement également ce qui m'est arrivé.

Pendant longtemps je me suis cru à l'abri de la perte de mes données perso, depuis des années j'utilise d’un serveur Dell PowerEdge avec RAID matériel acheté d’occasion une poignée de figues sur Ebay (PowerEdge 840 puis T310 actuellement) et je fais des sauvegardes régulières sur disque dur externe USB grâce à un script lancé automatiquement avec l’utilitaire cron. Les données les plus précieuses se retrouvent sur un autre disque externe que je stocke au boulot au cas où la maison parte en fumée. Mon RAID était basé jusqu'à présent sur 4 disques Seagate ST2000DM01 de 2To chacun de 2015. Alors certes, on l'a suffisamment martelé sur ce site le RAID n’est pas assimilable à de la sauvegarde, c’est juste un système de redondance qui dispatche les données sur plusieurs disques pour éviter de tout perdre quand un disque crashe, la tolérance au panne est donc censée être meilleure qu’avec un seul disque.

Il se trouve cependant que j’ai eu au printemps dernier une panne de mon RAID bas bruit, le RAID est passé en mode dégradé avec la perte d’un disque. Puis un second disque du RAID a commandé à défaillir, c’est là que j’ai commencé à m’en rendre compte car j’ai eu un certain nombre d’erreurs système qui remontaient. Il était temps de changer 2 disques de mon RAID, après avoir fonctionné quasiment 24h/24 7j/7 pendant 5 ans, je trouve que c'est une durée de vie plutôt correcte pour des disques bas de gamme. Je les ai remplacés par des Seagate IronWolf de 3To. Mon RAID 5 est donc maintenant constitué de 2 disques Seagate ST2000DM01 de 2015 et de 2 disques Seagate IronWolf de 3To ce qui donne une capacité utile de 5,5To. D’ailleurs il faut sans doute que je songe à changer les deux disques les plus anciens.

Après avoir réinstallé mon RAID avec les nouveaux disques j’ai redescendu la sauvegarde, c’est là que je me suis rendu compte qu’il manquait un paquet de fichiers. Sur le coup je n’ai pas compris car les sauvegardes avaient été régulières, j’ai reconstitué tardivement le fil du drame. Il y a eu donc un crash bas bruit sur le RAID qui a dégradé des données, la sauvegarde s’est faite normalement mais a supprimé les fichiers qui avaient disparu du RAID car corrompus. Mais quel crétin ! Je n’avais pas mis en place un test d’état de santé des disques et du RAID avant de lancer la sauvegarde. Du coup j’ai essayé de récupérer les fichiers supprimés de la sauvegarde avec Photorec, ça m’a pris beaucoup de temps (des mois !) car il y en avait pour des To, mais comme il y a eu plusieurs sauvegardes dans l’intervalle je n’ai récupéré au final que peu de choses. Dans l’histoire, j’ai perdu dans les 400 films et une centaine de vidéos perso :-(

J’ai dû revoir de fond en comble ma pratique de la sauvegarde, mes données principales sont toujours stockées sur le RAID 5 et il existe toujours une sauvegarde journalière sur disque de USB externe. Mais j’ai rajouté des sauvegardes croisées avec d’autres PC que je lance manuellement avec unison au moins une fois par semaine et j’ai rajouté également des tests d’état de santé des disques, dès dégradation des disques les sauvegardes ne sont pas lancées, j’ai mis en place un système de mail automatique journalier qui m’informe de l’état des disques.

L’architecture ressemble maintenant à ça :
Titre de l'image

Les données principales se trouvent sur le serveur Mana qui dispose d’un RAID 1 avec deux disques SAS de 136Go pour le système et d’un RAID 5 pour les données dans le répertoire data d’un espace utile de 5,5To. Cet espace est copié automatiquement sur un disque externe USB de 4To, il est également copié dans son intégralité vers le disque Germaine de 4To de la station Predator et en partie (hors fichiers multimédia) vers le Thinkpad Tetiaroa. Les deux dernières copies sont manuelles et se font avec unison.

Concernant le script de sauvegarde, dans le répertoire /etc/cron.daily on va trouver le fichier sauvegarde qui contient :

#!/bin/bash
/usr/local/linux/systeme/hwraid-master/wrapper-scripts/megaclisas-status > /tmp/megastatus 2>&1

distant1="/media/sauvegardes"

# test de vérification de la présence du disque de sauvegarde
if [ ! -e "$distant1" ]
then
    #le disque n'est pas monté, j'envoie juste le mail d'état du raid et je stoppe le script
    cat /tmp/megastatus | mail -s "Etat raid" olivier
    exit
fi

#test de l'état de santé du disque dur externe
/usr/sbin/smartctl -a /dev/sdc >> /tmp/megastatus 2>&1

#envoi du mail de l'état des disques de mana
cat /tmp/megastatus | mail -s "Etat disk mana" olivier

# test de l'état du raid
raid=$(MegaCli64 -LDInfo -L1 -a0 | grep State)
if echo $raid | grep Degraded >/dev/null 2>&1
then
    exit
fi

#test de l'état du disque dur externe
ddur=$(/usr/sbin/smartctl -A /dev/sdc)
if echo $ddur | grep FAILING_NOW >/dev/null 2>&1
then 
    exit
fi

/usr/sbin/sauve

Ce script vérifie la présence du disque dur externe et vérifie son état de santé, ainsi que celui du RAID, il ne va pas plus loin si l’un des deux est dégradé, sinon il lance le script /usr/sbin/sauve qui contient :

#!/bin/bash
# Script sauvegarde rsync https://www.funix.org inspiré par
# celui de  Mickaël BONNARD ( https://www.mickaelbonnard.fr )
# sous licence MIT ( http://choosealicense.com/licenses/mit/ )

# Variables
# date et heure
jour=`date +%Y-%B-%d`
# répertoire contenant les logs
log="/var/log/sauvegarde"

# répertoires à sauvegarder
local1="/data"
local2="/home"
local3="/chroot/data"

# point de montage du disque de sauvegarde
distant1="/media/sauvegardes"
distant2="/media/sauvegardes/base-mysql"

# fichiers et répertoires à exclure de la sauvegarde
excludes1="/root/bin/exclude-data.txt"
excludes2="/root/bin/exclude-home.txt"

# nom de la sauvegarde dans le journal
echo "-------------------------------------------------------------" > $log/sauvegarde_$jour.log
echo "Sauvegarde de $local1 , $local2 et `{mathjax} local3 `(date +%d-%B-%Y)" >> $log/sauvegarde_$jour.log 

echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log

# heure de début du transfert dans le journal
echo "Heure de demarrage de la sauvegarde : $(date +%H:%M:%S)" >> $log/sauvegarde_$jour.log

echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log

#echo "lancement sauvegarde : $(date +%H:%M:%S)" | mail -s "Lancement sauvegarde" olivier

# transfert des fichiers
echo "Copie de data" >> $log/sauvegarde_$jour.log
rsync -av --stats --delete-after --exclude-from=$excludes1 $local1 $distant1 >> $log/sauvegarde_$jour.log
echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log
echo "Copie de home" >> $log/sauvegarde_$jour.log
rsync -av --stats --delete-after --exclude-from=$excludes2 $local2 $distant1 >> $log/sauvegarde_$jour.log
echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log
echo "Copie de chroot" >> $log/sauvegarde_$jour.log
rsync -av --stats --delete-after $local3 $distant2 >> $log/sauvegarde_$jour.log
echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log
# -a : mode archivage ( équivalent -rlptgoD ).
# -z : compression des données pendant le transfert.
# -- stats donne des informations sur le transfert (nombre de fichiers…).
# --delete-after : supprime les fichiers qui n’existent plus dans la source après le transfert dans le dossier de destination.

status=$?

echo "Statut de la commande "  >> $log/sauvegarde_$jour.log

#code d'erreurs rsync

case $status in
0) echo Succès >> $log/sauvegarde_$jour.log;;
1) echo Erreur de syntaxe ou d'utilisation >> $log/sauvegarde_$jour.log;;
2) echo Incompatibilité de protocole >> $log/sauvegarde_$jour.log;;
3) echo Erreurs lors de la sélection des fichiers et des répertoires d'entrée/sortie >> $log/sauvegarde_$jour.log;;
4) echo Action non supportée : une tentative de manipulation de fichiers 64-bits sur une plate-forme qui ne les supporte pas \
 ; ou une option qui est supportée par le client mais pas par le serveur. >> $log/sauvegarde_$jour.log;;
5) echo Erreur lors du démarrage du protocole client-serveur >> $log/sauvegarde_$jour.log;;
6) echo Démon incapable d'écrire dans le fichier de log >> $log/sauvegarde_$jour.log;;
10) echo Erreur dans la socket E/S >> $log/sauvegarde_$jour.log;;
11) echo Erreur d'E/S fichier >> $log/sauvegarde_$jour.log;;
12) echo Erreur dans le flux de donnée du protocole rsync >> $log/sauvegarde_$jour.log;;
13) echo Erreur avec les diagnostics du programme >> $log/sauvegarde_$jour.log;;
14) echo Erreur dans le code IPC>> $log/sauvegarde_$jour.log;;
20) echo SIGUSR1 ou SIGINT reçu >> $log/sauvegarde_$jour.log;;
21) echo "Une erreur retournée par waitpid()" >> $log/sauvegarde_$jour.log;;
22) echo  Erreur lors de l'allocation des tampons de mémoire principaux >> $log/sauvegarde_$jour.log;;
23) echo Transfert partiel du à une erreur >> $log/sauvegarde_$jour.log;;
24) echo Transfert partiel du à la disparition d'un fichier source >> $log/sauvegarde_$jour.log;;
25) echo La limite --max-delete a été atteinte >> $log/sauvegarde_$jour.log;;
30) echo Dépassement du temps d'attente maximal lors d'envoi/réception de données >> $log/sauvegarde_$jour.log;;
35) echo Temps d’attente dépassé en attendant une connection >> $log/sauvegarde_$jour.log;;
255) echo Erreur inexpliquée >> $log/sauvegarde_$jour.log;;
esac

echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log

# heure de fin dans le journal

echo "Jour de fin de sauvegarde : $(date +%d-%B-%Y)" >> $log/sauvegarde_$jour.log
echo "Heure de fin de la sauvegarde : $(date +%H:%M:%S)" >> $log/sauvegarde_$jour.log

echo "-------------------------------------------------------------" >> $log/sauvegarde_$jour.log

cat $log/sauvegarde_$jour.log | mail -s "Sauvegarde" olivier


exit

En parallèle sur le serveur mana j’ai activé smartmontools, cet outil embarque le serveur smartd qui monitore les disques durs et envoie des alertes en cas d’erreur. J'ai mis dans le fichier /etc/smartd.conf la ligne :

DEVICESCAN -o on -S on -s (S/../.././01|L/../../1/03) -m olivier -M test

Cela signifie que tous les disques subiront un test court tous les jours à 1h du matin et un test long les lundis à 3h du matin, en cas d’erreurs rencontrés un mail me sera remonté.

Sur les PC Predator et Tetiaroa ils ne sont pas allumés en permanence, il faut que je pense régulièrement à lancer les commandes de vérification de l’état de santé du disque sur lequel se trouve ma sauvegarde avant chaque lancement d’unison. Je songe à rédiger un script pour vérifier l'état des disques au lancement.

Maintenant j’ai sur les bras un disque externe USB de 1To supplémentaire, un disque dur de 2To inutilisé et bientôt 2 autres disques de 2To après les avoir remplacés dans le RAID 5. Je compte grouper tous ces disques dans un boîtier multi disque USB ou un NAS réseau, je n’ai pas encore fait mon choix, ça me permettra de mettre en place une nouvelle redondance de sauvegarde.

En guise de conclusion et pour en revenir à mes données perdues, je n’ai plus qu’à reconstituer ma collection de films, en partie en récupérant les fichiers enregistrés sur ma box. Pour ce qui concerne mes vidéos perso, fort heureusement une grande partie sont encore sur des bandes miniDV et sur des cassettes VHS, il ne me reste plus qu'à renumériser tout ça.

Je suis preneur de toute remarque sur l'amélioration de ce dispositif.

  • # Pourquoi si compliqué ?

    Posté par  . Évalué à 10.

    Je compatis pour ta perte de données. Si seulement tu étais le seul à qui c'est arrivé…

    En revanche je trouve ton installation bien compliquée. En multipliant les systèmes de copie et de redondance tu multiplies aussi les risques de plantages et de bugs.

    J'ai l'impression (je peux me tromper) qu'il manque un composant essentiel qui te permettrait de simplifier tout ça : la sauvegarde incrémentale. En plus d'être rapide cela te permet d'avoir un historique des sauvegardes et de remonter dans le temps. Si tu utilises en plus la "déduplication" tu peux remonter très loin dans le temps pour un coup d'espace disque modeste: entre deux sauvegardes seuls sont sauvegardés les morceaux d'un fichier qui ont été modifiés et non le fichier en entier. De même quand tu déplaces un fichier dans un répertoire ou que plusieurs fichiers partagent les mêmes données.

    Je te recommande Restic qui te permet de sauvegarder à diverses endroits, dont certains services de stockage dans le nuage, et qui supporte les sauvegardes incrémentales et la déduplication.

    • [^] # Re: Pourquoi si compliqué ?

      Posté par  . Évalué à 3.

      Restic m'a planté une fois, j'ai abandonné. J'avais beaucoup d'espoir dans cette techno. Mais a force de fonctionner, la base a fini par perdre sa cohérence. J'ai donc lâchement abandonné ce bel outil de backup.

      Je préfère pour ma part, un mécanisme de snapshot basé sur BTRFS. Ca irait pas mal sur le serveur de backup et aussi sur le disque USB.

      • [^] # Re: Pourquoi si compliqué ?

        Posté par  . Évalué à 8.

        Sinon il y a borg, qui revient souvent dans les discussions sur les outils de sauvegarde et qui semble faire consensus chez ceux qui l'ont essayé.
        Il gère la sauvegarde incrémentale, et le pruning des snapshots.

        • [^] # Re: Pourquoi si compliqué ?

          Posté par  . Évalué à 7.

          Il gère également la déduplication.

          Tout ce système pour prévenir de la défaillance d'un disque, pourquoi pas mais ça ne protège pas contre les erreurs telles qu'une suppression de fichiers par inadvertance, un bit rot, ou une corruption de données dues à un bug logiciel : il faut absolument pouvoir remonter dans le temps.

          Pour ma part, j'utilise btrfs en raid 1 pour lutter contre un éventuel bit rot, borg pour la sauvegarde sur un autre disque local, et rclone pour une copie extérieure synchronisée de la sauvegarde borg (cloud wasabi).

          • [^] # Re: Pourquoi si compliqué ?

            Posté par  . Évalué à 6. Dernière modification le 10 novembre 2020 à 02:21.

            Je plussoie pour borg. Avec borgmatic, ca prend moins de 5 min à configurer, créer le dépôt de sauvegarde, tester et automatiser.

            Emacs le fait depuis 30 ans.

            • [^] # Re: Pourquoi si compliqué ?

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

              Mon dispositif fait déjà de la sauvegarde incrémentale que ça soit avec mon script ou avec unison, mais vu le volume de données aujourd'hui je ne peux guère remonter qu'à une semaine. Je note le principe de la déduplication et de borg, merci pour les pistes d'amélioration.

              https://www.funix.org mettez un manchot dans votre PC

              • [^] # Re: Pourquoi si compliqué ?

                Posté par  . Évalué à 4.

                si je peux me permettre, BTRFS, par le biais des snapshots permet aussi nativement de gérer de la déduplication par bloc. Plus précisément, suite à un snapshot, si 1 octet change sur un fichier de 1Go, seul le différentiel sera conservé sur le volume courant.

                Par expérience, le mécanisme de snapshot fonctionne assez bien avec une volumétrie de 25To et plusieurs dizaines de millions de fichiers et sur un historique de 30 jours. Le serveur est monté en RAID matériel (je n'ai pas choisi) et en partition BTRFS pour ces volumes de données. La rotation par snapshot est réalisée par un script maison.

                La création et suppression de snapshot est instantanée : on récupère la main dans les quelques secondes qui suivent. Mais attention, suite à une suppression d'un snapshot, il y a une tache qui va faire du nettoyage en tache de fond et qui dure environ 1 ou 2 heures.

                Nous avions une solution basée sur rsnapshot pour faire la même chose à l'époque ou BTRFS n'existait pas encore. La suppression par une sorte de "rm -fr" des snapshots durait des heures. Cette tache était programmée pour tourner la nuit, mais notre système arrivait au bout et risquait de déborder sur les taches de backup en début de matinée.

                BTRFS c'est vraiment bien. Méfiance avec certains fonction avancée, en particulier le RAID. Sans RAID, pas d'incident constaté depuis des années.

                • [^] # Re: Pourquoi si compliqué ?

                  Posté par  . Évalué à 4.

                  Attention la déduplication par bloc et les snapshots, ce n'est pas la même chose.

                  La déduplication permet surtout de limiter l'effet de fichiers ou blocs dupliqués. Typiquement si tu crées deux fichiers exactement identiques, la déduplication (online ou offline) va trouver ces deux fichiers et ne va en stocker réeelement qu'un seul.

                  Par contre c'est vrai que si tu ne changes que légèrement un fichier, seul le bloc impacté est mis à jour dans le snapshot (vu que le snapshot opère au nivau du bloc si je me souviens bien).

                  Avec Btrfs, le mieux c'est de lancer un processus de déduplication avant de faire le snapshot.
                  Mais attention dans ce cas là, car si tu as un fichier qui est dédupliqué des centaines de fois, tu n'as plus qu'une copie de ce fichier (donc s'il est corrompu…).
                  Raison pour laquelle j'utilise RAID avec Btrfs…

                  • [^] # Re: Pourquoi si compliqué ?

                    Posté par  . Évalué à 2.

                    Par contre c'est vrai que si tu ne changes que légèrement un fichier, seul le bloc impacté est mis à jour dans le snapshot (vu que le snapshot opère au nivau du bloc si je me souviens bien).

                    La déduplication de borg fonctionne aussi par bloc (taille paramétrable).

                • [^] # Re: Pourquoi si compliqué ?

                  Posté par  . Évalué à 2.

                  Mais du coup, ce qui est dommage, c'est que dans ce cas, on est obligé d'utiliser BTRFS, ce n'est pas FS agnostique.

                  Emacs le fait depuis 30 ans.

              • [^] # Re: Pourquoi si compliqué ?

                Posté par  . Évalué à 7.

                Mon dispositif fait déjà de la sauvegarde incrémentale que ça soit avec mon script ou avec unison, mais vu le volume de données aujourd'hui je ne peux guère remonter qu'à une semaine.

                Tu produit tant de données ? Ou tu roll tant de données que ça par semaine ?

                Quand on commence à avoir beaucoup de données (beaucoup c'est à l'appréciation de chacun, mais je pense que c'est quand tu commence à te demander si tu a la place pour faire ce que tu veux), il est important de segmenter tes données en te demandant combien de temps tu souhaite les garder, quelle fréquence tu les met à jour, quel volume ça représente,…

                Personnellement je n'applique pas du tout le même backup aux données « vivantes » de mon dossier personnel et aux données que je souhaite garder aussi longtemps que possible avec mes photos et vidéos. Je ne sauvegarde pas de la même façon, je n'y accède pas de la même façon, etc.

                Ça peut grandement aider et simplifier.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Pourquoi si compliqué ?

            Posté par  . Évalué à 3.

            Pour ma part, j'utilise btrfs en raid 1 pour lutter contre un éventuel bit rot

            Je me souviens d'une discussion ici même où je luttais pour faire comprendre que BTRFS en RAID 1 permet de lutter contre la corruption de données :
            https://linuxfr.org/users/saintgermain/journaux/gestion-de-versions-et-sauvegarde-de-donnees

            C'est vraiment pas évident pour tout le monde…

            La conclusion que j'en ai tirée, c'est que parler de RAID et de sauvegarde dans le même texte, c'est s'exposer à des remarques violentes.

            • [^] # Re: Pourquoi si compliqué ?

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

              Certes tous ces outils sont certainement très bien, mais est-ce qu'ils intègrent des tests d'intégrité des disques, car mon soucis vient d'abord de là. J'aurais également souhaité savoir comment vous vous prémunissez d'un disque qui commence à flancher.

              https://www.funix.org mettez un manchot dans votre PC

              • [^] # Re: Pourquoi si compliqué ?

                Posté par  . Évalué à 3.

                Btrfs peut être configuré pour détecter la corruption de données: par exemple en RAID1 tu peux stocker deux fois les données et les métadonnées.
                Si tu lances tous les soirs une vérification (scrub), tu auras le résumé (et la correction !) des données corrompues.

                C'est une preuve indirecte que tes disques flanchent.

                Bien entendu le mieux c'est de détecter plus en amont (smartctl, badblocks et compagnie…)

                • [^] # Re: Pourquoi si compliqué ?

                  Posté par  . Évalué à 3. Dernière modification le 10 novembre 2020 à 21:36.

                  Normalement un scrub périodique n'est pas utile. En raid 1, les erreurs sont automatiquement détectées et corrigées lors d'un accès en lecture de la donnée concernée, donc lors de la sauvegarde par exemple.

                  Il est bien plus économique en charge système de regarder les logs btrfs que de lancer un scrub tous les jours.

                  • [^] # Re: Pourquoi si compliqué ?

                    Posté par  . Évalué à 1.

                    De mémoire, j'avais lu qu'on recommande un scrub par mois et pas pour vérifier les checksums, mais pour la cohérence du filesystem. Je n'ai pas réussi à trouver de doc officielle là dessus. Le paquet debian et ubuntu btrfsmaintenance lance tous les mois un scrub, un trim, un defrag et un balance.
                    Comme d'hab sur btrfs, on a l'impression de faire de la magie noire pour un truc qui est bien documenté et bien scripté dans les OS sur les autres filesystems…

              • [^] # Re: Pourquoi si compliqué ?

                Posté par  . Évalué à 2. Dernière modification le 10 novembre 2020 à 12:21.

                Les tests d'intégrité de disque sont un mythe. De mémoire, il y a 50% des défaillances qui ne sont pas détectées par les métriques SMART ; c'est surtout intéressant pour surveiller le vieillissement des disques. Les autres tests sont pires que tout, parce que stresser son disque avec un test de surface est un bon moyen d'augmenter le risque de défaillance.

                BTRFS est pas mal effectivement pour détecter le bitrot et les autres secteurs qui crèvent. Mais ça reste un FS immature, avec une doc misérable et un outillage approximatif. J'ai déjà testé pour faire des sauvegardes en ligne différentielles, et déjà quasi tout perdu, il y a 3 ans.

                btrfs check --repair
                […]
                Note that while this tool should be able to repair broken filesystems, it is still relatively new code
                […]
                This page was last modified on 6 July 2015, at 22:16.

                Donc OK pour BTRFS mais avec de la grosse sauvegarde derrière, bien solide.

                • [^] # Re: Pourquoi si compliqué ?

                  Posté par  . Évalué à 3.

                  Tu peux aussi utiliser ZFS si tu veux quelque chose de plus mature mais avec le même principe…

                  Mais oui Btrfs n'est pas fini, loin de là.
                  Cependant si tu restes dans du simple RAID1, je n'ai pas vu beaucoup de soucis.

                  Le plus embêtant c'est quand il faut réparer, dans ce cas la meilleure solution est:
                  - le RAID1 te permet de réparer avec un simple scrub
                  - si ça ne marche pas, balancer le disque dur et reconstruire le RAID

                  Essayer de réparer un Btrfs (hormis avec scrub), il faut avoir le coeur solide.

                • [^] # Re: Pourquoi si compliqué ?

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

                  Ah j'avais pas pensé à ça, en pensant faire bien en lançant des tests sur les disques, on contribue à accélérer leur vieillissement et à augmenter le risque de défaillance, c'est ballot.

                  https://www.funix.org mettez un manchot dans votre PC

                  • [^] # Re: Pourquoi si compliqué ?

                    Posté par  . Évalué à 3.

                    Ben tu veux faire comment pour s'assurer que ça marche sans regarder ?

                    Sinon c'est un peu le disque dur de Schrödinger: p'tet bien que ça marche, p'tet bien que ça marche pas..

                    • [^] # Re: Pourquoi si compliqué ?

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

                      Oui mais du coup je suis un peu paumé, plutôt que le disque dur de Schrödinger je dirais plutôt est-ce que le risque que je prends à tester les disques est plus grand que de rien tester du tout.

                      https://www.funix.org mettez un manchot dans votre PC

                      • [^] # Re: Pourquoi si compliqué ?

                        Posté par  . Évalué à 1.

                        Si tu fais des sauvegardes complètes régulièrement, en plusieurs exemplaires et sans différentiel, ça n'a aucune importance de tester le disque. Si tu as des secteurs morts, c'est hautement improbable d'écrire deux fois dans le même secteur sans que le disque te remonte une erreur, fasse planter ton process de sauvegarde. Et les disques ont des algorithmes de correction d'erreur qui se comportent plutôt bien dans l'ensemble.
                        La faiblesse dans le setup évoqué, c'est de baser la sauvegarde hors-ligne sur la sauvegarde en ligne. C'est un risque potentiel, qui peut se compenser en utilisant du BTRFS ou du ZFS, qui recalcule le checksum à la lecture des blocs.
                        Le but n'est pas le risque zéro mais de minimiser le risque de perdre des données.

                        • [^] # Re: Pourquoi si compliqué ?

                          Posté par  . Évalué à 1.

                          J'ajouterais que vérifier ta sauvegarde est plus malin que de vérifier ton disque.

                          • [^] # Re: Pourquoi si compliqué ?

                            Posté par  . Évalué à 2.

                            Expérience vécue: j'avais de bons disques mais des câbles endommagés.
                            Au final j'avais beaucoup de corruption de données (non corrigé par le disque du coup).

                            Si je ne teste pas mon filesystem (avec scrub) et que je fais uniquement des sauvegardes, comment je fais pour ne pas perdre des données ?

                            • [^] # Re: Pourquoi si compliqué ?

                              Posté par  . Évalué à 2.

                              Je ne comprends pas tout. Un disque que tu sauvegarde régulièrement a beaucoup d'erreurs, mais c'est silencieux ? Si tu te sers de ses données tu devrais voir le problème, non ?

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                              • [^] # Re: Pourquoi si compliqué ?

                                Posté par  . Évalué à 2.

                                J'ai des milliers de photos que je regarde seulement de temps en temps.
                                Il peut se passer des années avant que je regarde de nouveau les photos de 2003 par exemple, mais j'aime bien les avoir sous la main.

                                Idem pour des vieux fichiers (bulletin de paie par exemple) que je ne regarde jamais mais dont on peut avoir besoin.

                                • [^] # Re: Pourquoi si compliqué ?

                                  Posté par  . Évalué à 2.

                                  C'est dommage de réécrire toutes les semaines ces données, non ? Ça augmente le risque sans en avoir d'intérêt particulier (et potentiellement ça prend de la place, du temps pour les resauvegarder,…).

                                  Idem pour des vieux fichiers (bulletin de paie par exemple) que je ne regarde jamais mais dont on peut avoir besoin.

                                  Pour des données comme ça, au lieu de multiplier les itérations de sauvegarde, utiliser quelque chose comme par2 me parait plus approprié.

                                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                  • [^] # Re: Pourquoi si compliqué ?

                                    Posté par  . Évalué à 2.

                                    Que veux-tu dire par réécrire ?
                                    Les données sont sur mon disque et je n'y touche pas. Elles sont prises en compte lors de la sauvegarde de données c'est tout.
                                    La plupart du temps, le méchanisme de sauvegarde les ignore car elles n'ont pas changé (sauvegarde incrémentale).
                                    C'est seulement lors d'une sauvegarde complète, qu'elles sont lues.

                                    Quelle solution tu préconises pour gérer des photos ?

                                    Je suppose que je peux les mettre sur un disque à part avec des sommes par2, mais ça veut dire que:
                                    - c'est plus compliqué pour y accéder
                                    - il faut que je fasse manuellement (ou via un script supplémentaire) le contrôle et la correction
                                    - il faut que je gère la sauvegarde de ce disque séparemment

                                    Déjà la sauvegarde c'est pénible, donc le but c'est de rendre le truc le plus simple et automatisé possible.

                                    • [^] # Re: Pourquoi si compliqué ?

                                      Posté par  . Évalué à 2.

                                      Ok je n'avais pas compris que c'était incrémental cependant :

                                      La plupart du temps, le méchanisme de sauvegarde les ignore car elles n'ont pas changé (sauvegarde incrémentale).

                                      Quel est le moment où il y a une bonne raison que ça arrive ? À mon avis aucun.

                                      Personnellement ce genre de sauvegarde je le gère séparément. Je ne fais qu'une détection des fichiers, je ne cherche pas à regarder leur contenu. Donc rsync en lui disant bien de ne jamais supprimer de fichier, il crée juste de nouveau, il ne met pas à jour un fichier existant. Distant génération d'un index de checksum (et son contrôle avec le précédent) et d'une archive par2. C'est à la fois très simple et très fiable.

                                      c'est plus compliqué pour y accéder

                                      Tu mélange les besoin. La sauvegarde et la mise à disposition sont 2 choses différentes. La sauvegarde ne s'intéresse à l'accès que pour réduire le temps de recovery. L'accès normal aux données n'a rien à voir. Justement si ton disque explose tu n'a probablement pas besoin que ces données soient les premières restaurées. Si tu sais qu'elles sont sauves tu peux te permettre d'attendre un peu je pense. Alors que le fichier sur le quel tu as travaillé 8h hier, tu as besoin de le récupérer rapidement.

                                      Déjà la sauvegarde c'est pénible, donc le but c'est de rendre le truc le plus simple et automatisé possible.

                                      Segmenter ses sauvegardes simplifie énormément tes sauvegardes car tu utilise les critères qui conviennent pour chaque données. Chercher à sauvegarder de la même façon des fichiers que tu veux garder à vie et des fichiers qui n'ont plus aucun intérêt dans 6 mois rend vraiment les choses plus difficile à gérer.


                                      Ce sera peut être plus clair avec un exemple.

                                      Catégories de données

                                      Moi je sépare mes données en 3 groupes :

                                      • les données froides : ce sont les photos, vidéos et quelques documents
                                        • elles ne vivent pas
                                        • elles ont une durée de rétention infini
                                        • elles représentent un volume important au final (pour moi)
                                        • je n'y accède que très peu, je n'ai pas besoin d'y accéder tous les jours
                                      • les données chaudes : qui sont ce sur quoi je travail tous les jours
                                        • elles bougent continuellement
                                        • je n'ai pas besoin d'une rétention très grande (j'ai pris 15 jours, mais je pourrais ne les garder que 7)
                                        • elles sont assez peu volumineuses au final
                                      • les données que j'accepte de perdre : tout un tas de trucs dont je me fou, je peux les retrouver

                                      Méthodes de sauvegarde

                                      Pour les premières c'est un rsync+checksum+par2. Je ne l'ai pas décri t tout à l'heure, mais je roll le par2. Une fois que j'ai construit le nouveau et que je sais que les données dedans sont cohérente je détruis l'ancien.

                                      Pour le second j'utilise tarsnap, mais grosso modo je pourrais utiliser plus ou moins n'importe quelle solution. Limiter les volumes ici me permet d'alléger les sauvegardes, c'est particulièrement intéressant quand tu paie comme moi mais c'est toujours utile, même chez toi sur ton réseau local.

                                      Pour les troisième OSEF.

                                      À l'usage

                                      Les première ne sont pas stockées sur mon ordinateur local, mais uniquement sur un VPC OVH, elles sont accessibles en web (j'ai un moteur de galerie statique dont j'ai oublié le nom). C'est depuis le serveur quelles sont sauvegardées. C'est utile surtout pour pouvoir envoyer des données directement depuis mon téléphone et voir mes données aussi depuis ma tv ou une tablette. Ça ne m'embête pas de ne pas pouvoir y accéder hors ligne, sinon j'en ferais une synchro sur un disque local périodiquement (aucune notion de backup là dedans c'est juste une copie donc rien de complexe ou autre juste besoin d'un rsync croné).

                                      Les deuxièmes c'est mon dossier home à l'exception de quelques exceptions (mon dossier de téléchargement, le cache des applications et quelques trucs comme ça).

                                      Les troisième c'est le reste.

                                      Au final ça ne me paraît pas aussi compliqué que tu semble le penser. En tout cas je vis bien avec (et c'est l'essentiel). Ça m'a demandé un peu d'outillage pour mes données long terme, mais ça me simplifie tellement la vie je trouve.

                                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                      • [^] # Re: Pourquoi si compliqué ?

                                        Posté par  . Évalué à 2.

                                        Oui tu fais comme je l'avais imaginé: tu mets tes photos à part et c'est donc plus compliqué d'y accéder.
                                        Sans parler du fait que tu maintiens deux processus de sauvegardes différents (rsync+tarsnap).

                                        Je ne doute pas que cela marche bien dans ton cas si tu as la discipline et la compétence derrière.

                                        Mais imagine le cas d'une famille où tout le monde stocke n'importe où au petit bonheur. Tu te vois expliquer qu'il faut stocker les photos ici et les vidéo là et les fichier ici ?
                                        Tu peux aussi tenter le coup dans une entreprise : dans mon entreprise, on avait le même principe que toi (un disque réseau pour les fichiers importants, un répertoire local pour les fichiers temporaires, etc.). Au final tu as toujours des utilisateurs qui râlent car ils ont perdu des semaines de travail car ils ont pas stocké au bon endroit.

                                        Du coup j'ai pris l'option radicale: chacun gère ses appareils comme il veut. Tous les appareils sont sauvegardés sur un NAS où un processus de déduplication a lieu et un contrôle d'intégrité (Btrfs scrub). Le NAS en lui-même est sauvegardé sur un site distant.

                                        Pour l'instant tout fonctionne bien, mais il est vrai que je me repose beaucoup sur Btrfs.

                                        • [^] # Re: Pourquoi si compliqué ?

                                          Posté par  . Évalué à 2. Dernière modification le 12 novembre 2020 à 17:01.

                                          Mais imagine le cas d'une famille où tout le monde stocke n'importe où au petit bonheur. Tu te vois expliquer qu'il faut stocker les photos ici et les vidéo là et les fichier ici ?

                                          Tu exagère. D'une part tu décris quelque chose de plus complexe que ce que moi j'ai décris. D'autre part c'est automatisé dans l'énorme majorité des cas. Donc non ça n'est même pas une question de connaître une règle et de s'y tenir, mais d'avoir mis en place une règle et de l'oublier.

                                          Tu peux aussi tenter le coup dans une entreprise : dans mon entreprise, on avait le même principe que toi (un disque réseau pour les fichiers importants, un répertoire local pour les fichiers temporaires, etc.). Au final tu as toujours des utilisateurs qui râlent car ils ont perdu des semaines de travail car ils ont pas stocké au bon endroit.

                                          Pareil tu exagère, mon setup ne permet pas que cela se produise (ou alors il faut supprimer ton travail et t'en rendre compte plus de 2 semaines après).

                                          Si le logiciel doit être au service de l'utilisateur dépenser des centaines d'euros et des megawatt pour éviter à l'utilisateur une étape de formation est un non sens dans le cadre du travail. Il faut que les règles fasses du sens, mais passer son temps à gérer des Tio de données pour rien n'est bon pour personne1. Après ça peut être de leur expliquer qu'on va bien tout sauvegarder, mais que du coup ils ont 20Gio de quota sur leur machine.


                                          1. je pense sincèrement que c'est une forme de dette. Tu t'évite des ennuis aujourd'hui que tu paiera plus tard 

                                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Pourquoi si compliqué ?

                  Posté par  . Évalué à 2.

                  C'est aussi un FS qui évolue donc ce qu'il était il y a quelques années ne reflète pas/plus ce qu'il est aujourd'hui.

    • [^] # Re: Pourquoi si compliqué ?

      Posté par  . Évalué à 2.

      Pas de pot pour la perte de données, la corruption "silencieuse" de fichiers, c'est ce que je redoute le plus.

      Pour ma part j'utilise aussi unison, mais uniquement pour mes fichiers les plus importants. Tout le reste est synchronisé avec FreeFileSync, de façon "manuelle", sur des disques externes (j'en ai au moins 2 à chaque fois). Je dis "manuelle", cela me permet de vérifier d'un coup d'oeil rapide s'il n'y a pas d'incohérence dans les données qui vont être placés sur le disque de sauvegarde. Mais il faudrait par contre que j'automatise la vérification de la bonne santé des disques.

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: Pourquoi si compliqué ?

        Posté par  . Évalué à 1.

        En vrai c'est la perte la plus improbable, surtout avec des disques de bonne qualité. Ça se contourne avec des sauvegardes complètes et en utilisant les fonctionnalités de vérif intégrées par exemple à borg ou à btrfs, ou tout outil de sauvegarde qui se respecte. Et le seul moyen de s'assurer que tout va bien est de simuler des incident en essayant de récupérer ses données depuis les sauvegarde, régulièrement.

        • [^] # Re: Pourquoi si compliqué ?

          Posté par  . Évalué à 2.

          Pour moi c'est la cause la plus probable hormis les boulettes utilisateurs/administrateurs.

          Le feu, la foudre, les explositions, les cambriolages, c'est somme toute assez rare (quoique pour les cambriolages, cela dépend de là où l'on vit).

          Par contre les corruptions de données, cela m'arrive régulièrement.
          Je ne sais pas si c'est parce que je n'ai pas de chance ou si c'est parce que je teste régulièrement (bah oui si on ne regarde pas, il n'y a pas de problème…).

          Disque endommagé, câble data défectueux, câble power défecteux: j'ai tout eu.

        • [^] # Re: Pourquoi si compliqué ?

          Posté par  . Évalué à 3.

          En vrai c'est la perte la plus improbable, surtout avec des disques de bonne qualité

          ah, j'avais oublié de raconter, il m'est arrivé à peu près la même chose qu'à l'auteur de ce journal il y a quelques années, sur un nas en RAID, un jour un disque est indiqué comme étant défectueux, je le retire, le temps de commander un remplaçant, une semaine se passe, et un second disque a lâché, du coup tout a été perdu (ce n'était pas grave pour le coup, c'était juste un support de stockage pour des sauvegardes). En retirant le disque, j'ai vu que c'était un modèle du même lot que le premier : même marque, même série, du coup s'il y avait un problème sur la série ce n'est pas si étonnant que les disques aient lâché quasi au même moment, après avoir fonctionné 2 ans sans faille.

          « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Pourquoi si compliqué ?

            Posté par  . Évalué à 2.

            Dans toutes ces histoires, un truc que je me demande, c'est pourquoi on ne recommande pas plus souvent RAID 6.

            Alors oui, tu perds un disque supplémentaire, oui, les performances chutent, mais d'une part si tu es parti sur du RAID, c'est déjà que tu assumes d'avoir un certain budget pour ta sécurité et, d'autre part, a supposer qu'on ait des besoins de performance importants, ce qui est pas le cas le plus fréquent, y a plein de goulots d'étranglement a vérifier avant genre le réseau qui est a 10 Mbit/s, les disques qui sont a 5400 t/minutes…

            Bref, moi, j'ai monté mon NAS en RAID 6, même si tout le monde se fiche de moi, mais pour l'instant, je ne 'e regrette pas

            • [^] # Re: Pourquoi si compliqué ?

              Posté par  . Évalué à 3. Dernière modification le 14 novembre 2020 à 21:43.

              J'avais trouvé (mais ne retrouve plus) un article dans lequel Dell, assez officiellement, déconseille le RAID5.

              Avec les grandes capacités des disques, le risque de perte d'un second disque pendant la reconstruction est devenu trop important.

              Ceci dit, d'autres personnes poussent plus loin la statistique en déconseillant maintenant le RAID6, donc au bout d'un moment il faut de toute façon considérer que n'importe quel RAID est perdable et se dire qu'il faut bien prendre un risque quelque part…

              Ceci dit, et si ça peut rassurer certains, j'ai remplacé, je pense, 200 à 300 disques dans des RAID, j'ai déjà vu des cartes RAID tomber en panne et exploser le RAID mais (pour le moment) jamais de second disque lâcher pendant que la reconstruction se fait, même avec des machines du type 12x 2 To (avec lesquelles les reconstructions sont longues). Cependant, on n'a jamais attendu plus longtemps qu'un week-end.

              Par contre j'ai déjà eu (une seule fois, je crois) le problème de "doubles fautes" avec des secteurs défectueux sur plusieurs disques, dans ce cas on peut perdre des données alors que le RAID est encore Online.
              https://www.dell.com/support/article/fr-fr/sln111497/double-faults-and-punctures-in-raid-arrays?lang=en
              Pour bien faire, il faut regarder plus loin que l'état BON/PAS BON du RAID et voir s'il y a des erreurs silencieuses (que voit très bien le contrôleur RAID même s'il n'en modifie pourtant pas l'état du RAID, je parle seulement des contrôleurs LSI/PERC).

    • [^] # Re: Pourquoi si compliqué ?

      Posté par  . Évalué à 6.

      Un petit nouveau dans la famille restic/borg : kopia
      https://github.com/kopia/kopia
      Il regroupe les fonctionnalités que les deux précédents ne font pas : compression et stockage type S3. En prime il est plus rapide…

      Sinon mon principe, comme déjà dit par d'autres, c'est de différencier le type de sauvegarde par type de données.
      Mes photos comme elles ne sont ni compressable ni deduplicable je les envois sur S3 avec versionning.
      Mon boulot, je push sur un dépot distant avec un hook à chaque commit. Je lance lance kopia toutes les heures sur mon home de travail, c'est surtout pour le cas où je supprime un fichier par erreur dans la journée.
      Et enfin j'ai craqué, j'envoi un tas de trucs sur S3…

      Le mieux c'est quand j'ai effacé tous les mails d'un client car on s'était mal compris. Je n'ai pas eu le temps de lui dire que j'avais une sauvegarde, il m'a remercié, il m'a dit que ça lui avait changé la vie, qu'il se sentait rajeunir, tout ça… Depuis je ne sauvegarde plus mes mails !

      • [^] # Re: Pourquoi si compliqué ?

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

        Merci pour la suggestion de kopia, je ne connaissais pas. Peux-tu nous en dire plus à son sujet ? Quels avantages comparé à restic et borg ? Des inconvénients ? Est-ce que c’est un outil fiable et stable ? (c’est plus récent apparemment).

        • [^] # Re: Pourquoi si compliqué ?

          Posté par  . Évalué à 3.

          Les avantages c'est qu'il fait tout ce que font les autres, plus une UI, très rapide etc… Un peu trop (compliqué) à mon avis d'ailleurs.
          L'inconvénient (et l'avantage, le développeur est vraiment très réactif) c'est que c'est jeune et que ça évolue beaucoup donc trop tôt pour savoir si c'est fiable, il n'est pas encore en v1.
          Pour l'instant j'utilise borg et kopia en //.
          Il est éventuellement prévu que kopia soit scindé en une lib + une UI. Ce que je préférerais pour développer un outil plus simple maison par dessus.

          • [^] # Re: Pourquoi si compliqué ?

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

            Merci. Ça faisait un moment que je voulais tester borg, j'ai finalement commencé à l'utiliser pour le boulot à la fin de la semaine (motivé par la lecture des commentaires de ce journal). J'ai aussi mis en place la même sauvegarde avec kopia, pour comparer. C'est pour un dossier de seulement 25 Go (ce sont beaucoup de fichiers petits et moyens en taille, et dont certains changent très souvent), mais ça suffit pour se faire une bonne idée sur les deux outils. Je travaille aussi avec d'autre données plus volumineuses, qui occupent des dizaines de To et ne compressent pas très bien… mais qui ne changent pas une fois collectées, donc pour elles je me contente d'une copie (avec rsync) vers un serveur de stockage dont le système de fichiers est sauvegardé quotidiennement par quelqu'un dont c'est le métier.

            J'ai utilisé kopiaUI et Vorta pour borg. Les deux permettent de mettre en œuvre une stratégie de sauvegarde simple en très peu de temps, c'est bien appréciable. J'ai trouvé Vorta plus facile à utiliser que kopiaUI.

            Vers un disque externe, la sauvegarde initiale des 25 Go était beaucoup plus rapide avec borg (4 minutes ; je ne me souviens plus combien de temps kopia a pris). La différence sera normalement moins perceptible avec les sauvegardes incrémentales (du moins je l'espère). Le disque est bien plus volumineux que mes 25 Go, donc je peux conserver des versions très anciennes avant de devoir faire le ménage, c'est nickel.

            Je n'utilise pas de service de stockage commercial (S3, etc.), donc ça n'est pas un critère pour choisir entre les deux outils pour moi. Mais le serveur de stockage mentionné plus haut, j'y accède simplement par ssh, donc c'est appréciable de pouvoir s'en servir comme d'un gigantesque disque externe avec kopia (sftp). J'adorerais pouvoir faire ça avec borg aussi, malheureusement ça ne marche que si borg est aussi installé sur le serveur (et je ne crois pas que ça sera possible sur ce serveur du boulot, même en insistant).

      • [^] # Re: Pourquoi si compliqué ?

        Posté par  . Évalué à 2.

        Il regroupe les fonctionnalités que les deux précédents ne font pas : compression et stockage type S3.

        Faux, borg fait de la compression.

        • [^] # Re: Pourquoi si compliqué ?

          Posté par  . Évalué à 4.

          Restic ne fait s3 mais pas la compression, borg fait la compression mais pas s3, kopia fait les deux.

  • # Proxmox

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

    Je compatis a la perte de donnée… C'est toujours en cas de panne qu'on se rend compte que notre systeme ultra complexe a une faille quelque part…

    Sinon pour ma part je suis entrain de basculer sur Proxmox Backup Server. C'est top ;)

  • # nouveaux outils

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

    Je confirme que les nouveaux outils sont nécessaires.

    Utilisation de PROXMOX avec un Proxmox Backup Server pour la sauvegarde des VM.
    Utilisation d'un NAS pour export des sauvegardes (compatible Ubuntu) ou comme repository dans une VM
    Utilisation de BORG pour l'externalisation des sauvegardes

    Pour PROXMOX, soit du full SSD donc au moins 4 disques;
    soit du mix SSD + HDD, il faut au moins 8 disques :
    - RAID 1 - 2 HDD
    - ZFS : RaidZ1 sur 3(minimum) disques HDD + 2 LOG en miroir SSD + 1 cache SSD

    En full SSD, le 1To est à 150€.

    PS: ton NAS, tu peux le mettre n'importe où dans la maison.
    Prendre un QNAP ou Synology!

  • # Commentaire supprimé

    Posté par  . Évalué à -4. Dernière modification le 10 novembre 2020 à 14:59.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Sauvegarde à froid

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

    De mon côté je suis passé sur un système de sauvegarde à froid a base de raspbery pi :

    - https://david.mercereau.info/?p=6096
    - https://retzo.net/services/service-de-sauvegarde-ecologiquement-soutenable-a-froid/

    Quand même un peu plus soutenable d'un point de vue écologique… (consommation énergétique)

    StackPiDD

    Le RAID j'ai arrêté, ça donne des boutons… 2 bonnes sauvegardes (sauvegarde+duplication) à 2 endroits différents c'est à mon sens plus sécurisant

    • [^] # Re: Sauvegarde à froid

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

      Intéressant ça me plait bien, une bonne piste pour monter un NAS et à terme pourquoi pas remplacer le serveur.

      https://www.funix.org mettez un manchot dans votre PC

    • [^] # Re: Sauvegarde à froid

      Posté par  . Évalué à 1. Dernière modification le 11 novembre 2020 à 14:41.

      Le RAID n'a rien à voir avec la sauvegarde. C'est juste utile si tu veux une haute disponibilité (pouvoir changer les disques sans arrêter les services) ou non.
      Mais c'est vrai que ça augmente le taux de panne car il y a plus de disques.

  • # Une centrale nucléaire pour des photos de famille :)

    Posté par  . Évalué à 5.

    Je plaisante, mais j'ai de suite pensé à ça en voyant ton schéma.
    A simplifier et à verdir un peu ? :D

  • # Quelques principes généraux résultants de l'expérience

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

    • RAID 5 c'est risqué.
    • RAID ne protège pas de l'écrasement ou de l'effacement par erreur.
    • Des sauvegardes manuelles c'est des sauvegardes oubliées.
    • Des sauvegardes automatiques dont la réussite n'est pas activement surveillée, c'est des sauvegardes en panne mais dont on s'en n'est pas encore aperçu.
    • Des sauvegardes qu'on n'a jamais réussi à restaurer c'est pas des sauvegardes de secours.
    • SMART c'est sympa mais plein de disques tombent en panne sans prémices.

    Adhérer à l'April, ça vous tente ?

  • # Sauvegarde Paranoïa

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

    Après avoir tenté beaucoup de choses, j'en suis venu à utiliser essentiellement des disques USB + Unisson. Pas cher, pratique, plutôt fiable à mon avis, moyennant certains habitudes à prendre.

    J'ai aussi différents espaces de différentes tailles et importances:
    - Mes documents perso (pas très gros mais importance ++)
    - Mes photos (très gros et très important)
    - Archives (gros et important mais ne bouge pas beaucoup)
    - Musique et films (pas si important que ça, peut être reconstitué)
    - Développement (rien à foutre, c'est sur github/gitlab/chez les potes)

    Selon l'importance, je duplique plus ou moins et plus ou moins souvent.

    Ça peut aller jusqu'à cinq ou six exemplaires, pas forcément tous mis à jour souvent. Je garde les anciens disques pleins aussi (il ne jette rien!). Si il y a un gros problème un jour, ça multiplie les chances de récupération.

    Bien sûr, les disques ne sont pas tous au même endroit physique.

    Lancer Unison régulièrement (selon le travail, une fois par jour ou par semaine) est devenu une habitude que je trouve saine (un peu comme faire des ctrl-S en tapant un texte).

    L'automatisation me fait peur. Dans Unison, j'ai un regard sur ce qui est fait et il m'arrive parfois de rattraper des erreurs (comme je travail sur plusieurs poste, cela fait aussi ma synchro).

    Le RAID me parait inutile et coûteux. Il répond selon moi à des questions de disponibilité, pas de sauvegarde. Si un jour j'ai une catastrophe, je suis près à prendre quelques jours pour tout remettre en ordre.

    • [^] # Re: Sauvegarde Paranoïa

      Posté par  . Évalué à 4.

      Le RAID me parait inutile et coûteux. Il répond selon moi à des questions de disponibilité, pas de sauvegarde.

      Pas que. Par exemple le RAID 1 sous BTRFS permet la détection et la correction automatique d'une corruption. Je m'en sers pour ça, pas spécialement pour la disponibilité.

      Ca permet d'éviter (autant que possible) qu'une corruption ne se propage le long de l'historique jusqu'à ce qu'il n'y ait plus aucune version du fichier non corrompue. De ce point de vue, ça répond à une problématique de la sauvegarde (mais ça ne la remplace absolument pas, on est bien d'accord).

  • # dispositif

    Posté par  . Évalué à 5.

    Merci pour ton retour d'expérience, jamais facile à vivre de perdre de la donnée.

    Pour la protection de données, j'applique quelques principes:

    • au moins trois jeux de données : un live et deux de sauvegardes → car lors d'une opération de restauration, un jeu de sauvegarde est mise en risque
    • au moins deux sites distants → en cas d'événement majeur type incendie ou vol
    • au moins un jeu de données non lié logiciellement aux autres → de la synchronisation entre trois sites ne protège pas des corruptions ou effacements de données qui vont se propager (penser ransonware)
    • une sauvegarde manuelle n'est pas une sauvegarde → c'est du déchet numérique
    • le RAID n'est un mécanisme de protection de données → qui a déjà testé l'arrachage d'un disque et la reconstruction du RAID avant d'en avoir besoin ? La reconstruction est longue, il faut serrer les fesses pendant toute l'opération. Si le contrôleur crame, tout est perdu.

    Je pense avoir un dispositif correct sans être infaillible :

    • Mes deux laptops sont synchronisés avec un nextcloud hébergé chez un hébergeur nordiste.
    • Le nextcloud est sauvegardé par cron rsync+ssh avec une rétention générationnelle (7 jours, 3 semaines, 3 mois) sur un serveur à la maison.
    • Si la sauvegarde ne se fait pas ou échoue, je suis averti sur mon mobile (merveilleux https://healthchecks.io/).

    Les points forts :

    • respecte les principes énoncés plus haut
    • nextcloud fait du versioning ce qui permet de revenir en arrière en cas de CTRL+S malheureux, simplement par l'interface web.
    • rsync rend la sauvegarde robuste et rapide (déduplication à la source)

    Les points faibles :

    • les données sont chez un hébergeur externe (il serait possible de faire de la réciprocité de sauvegardes avec un ami)
    • ce dispositif ne concerne que les fichiers, or nous produisons bien d'autres données
    • la vérification des données sauvegardées n'est pas faite de manière régulière
    • [^] # Re: dispositif

      Posté par  . Évalué à 1.

      une sauvegarde manuelle n'est pas une sauvegarde → c'est du déchet numérique

      C'est-à-dire ?

      • [^] # Re: dispositif

        Posté par  . Évalué à 3.

        Je m'explique sur la notion de déchet numérique.
        Je ne jette pas la pierre car je n'ai pas toujours eu ce dispositif automatisé. Et j'ai déjà dégainé un disque/clé USB pour copier vite fait mes données "au cas où".
        Sauf que ces "sauvegardes" ne sont pas gérées : impossible de savoir quelle est la plus fraîche, quelle est l'exhaustivité. Difficile à retrouver : où est la dernière ? Et très difficile de s'en débarrasser car c'était "au cas où" mais est-ce que j'ai une autre "sauvegarde" qui remplace ce tas de fichiers (ou archive) donc ça traîne sur le disque.

        Quant au principe qu'une sauvegarde manuelle n'est pas une sauvegarde. C'est peut être évident pour chacun mais au cas où. Si il y a une étape manuelle, elle finira par ne pas être faite. Soit par lassitude soit par impossibilité (vacances, autre priorité). J'ai vécu ça, avant l’avènement des accès internet haut débit, j'avais mis en place des sauvegardes manuelles mais très simplifiées pour une PME. En gros, il y avait un planning pour que chaque jour qqun prenne le disque branché sur le serveur, en branche un autre (numéroté) et emporte le premier chez lui. Sur le papier très sympa. Dans la pratique, c'est comme le planning pour sortir les poubelles dans une copro, tout le monde ne joue pas le jeu. Au final, on prend un prestataire externe.

        • [^] # Re: dispositif

          Posté par  . Évalué à 3.

          Merci pour l'explication ! Ça m'intriguait comme lien ! :)

          D'ailleurs, tu as tout à fait raison : je fais uniquement des sauvegardes manuelles, de 5 ordinateurs, via cp…Je mets tout ce que je veux sauvegarder dans un dossier que je renomme par exemple "Novembre 2020"…Je clone ce disque, je garde la sauvegarde précédente (mettons, octobre 2020) et j'efface "septembre 2020" sur les deux disques.

          Mais…parfois, j'oublie, je tarde. C'est un tampon que j'accepte, de perdre un mois de données. Au quotidien, je ne le ferais pas.

        • [^] # Re: dispositif

          Posté par  . Évalué à 3.

          Comment tu fais des sauvegardes hors-ligne ?

          • [^] # Re: dispositif

            Posté par  . Évalué à 2.

            Des sauvegardes qu'on met dans un placard ou au coffre, c'est ça ?

            Si je comprends bien la définition, je n'en fais pas, je crois. Je ne sais pas quel risque cela couvre ni si j'en aurai besoin pour compléter mon dispositif…

        • [^] # Re: dispositif

          Posté par  . Évalué à 2.

          Quant au principe qu'une sauvegarde manuelle n'est pas une sauvegarde. C'est peut être évident pour chacun mais au cas où. Si il y a une étape manuelle, elle finira par ne pas être faite.

          je ne comprends pas la logique là. On peut en dire autant d'une sauvegarde automatique. Il y a toujours un moment où il y a aura un bug, une panne, l'oubli de relancer un démon après un redémarrage, etc.

          Personnellement je fais plus confiance à ma paranoïa qu'à un processus automatique que je vais oublier et me ressouvenir bien trop tard après qu'il ait planté.

          • [^] # Re: dispositif

            Posté par  . Évalué à 4. Dernière modification le 13 novembre 2020 à 10:51.

            Personnellement je fais plus confiance à ma paranoïa qu'à un processus automatique

            Cela marche peut être dans ton cas. Mais qui a la ténacité de lancer une sauvegarde tous les jours et d'attendre que tout ce soit bien passé ? Personne que je ne connaisse.

            Il y a toujours un moment où il y a aura un bug, une panne, l'oubli de relancer un démon après un redémarrage, etc.

            Tu as raison, j'aurai du ajouter un principe fort de monitoring : une sauvegarde non surveillée n'est pas une sauvegarde.

            Dans le dispositif que je décris, j'utilise un healthchecks.io hébergé en dehors de mon infra. Tu peux aller voir le produit, il est opensource. En bref, il s'attend à être notifié régulièrement pas une processus. Si le notification n'arrive pas - ce qui arrive par exemple en cas de panne ou de bug - healthchecks.io envoi une alerte par le(s) moyen(s) configurés. Dans mon cas : email + Telegram + SMS. Moi aussi je suis parano :)

            • [^] # Re: dispositif

              Posté par  . Évalué à 2.

              Cela marche peut être dans ton cas. Mais qui a la ténacité de lancer une sauvegarde tous les jours et d'attendre que tout ce soit bien passé ? Personne que je ne connaisse.

              Sauf si ça fait partit des tâches à faire et que ne pas le faire déclenche une alerte pour le reste de l’équipe.

              • [^] # Re: dispositif

                Posté par  . Évalué à 1.

                Si tu as une équipe, je pense qu'elle a mieux à faire que de lancer des sauvegardes à la main…
                Et tu aurai automatisé la détection de l'absence de sauvegardes et pas les sauvegardes elles-mêmes. Ça commence à être tordu.

                • [^] # Re: dispositif

                  Posté par  . Évalué à 2.

                  Si tu as une équipe, je pense qu'elle a mieux à faire que de lancer des sauvegardes à la main…

                  Je pense que tu ne comprends pas où je veux en venir. Je dis pas qu’il faut faire toutes ses sauvegardes à la main, je dis seulement que faire des sauvegardes à la main, c’est possible et pas plus prompt à l’oublie, pour peu qu’il y ait une surveillance.

                  Dans une équipe, tout le monde ne fait pas que déployer ou écrire du code tout le temps. Vérifier que les sauvegardes soient utilisables, traiter les alertes, faire une réunion d’équipe pour se synchroniser, tout ça se sont des tâches que tu ne peux pas automatiser.

                  Et tu aurai automatisé la détection de l'absence de sauvegardes et pas les sauvegardes elles-mêmes.

                  De ce point de vue, c’est strictement identique à ta solution avec healthcheck.io, tu ne vérifies pas que ta sauvegarde fonctionne, seulement que la tâche s’est visiblement déroulé comme prévu.

  • # Snapraid

    Posté par  . Évalué à 2.

    Un peu étonné de pas voir Snapraid mentionné. Juste pour citer le site snapraid.it :

    SnapRAID is a backup program for disk arrays. It stores parity information of your data and it recovers from up to six disk failures.
    SnapRAID is mainly targeted for a home media center, with a lot of big files that rarely change.

    Beside the ability to recover from disk failures, other features of SnapRAID are:
    All your data is hashed to ensure data integrity and to avoid silent corruption.
    If the failed disks are too many to allow a recovery, you lose the data only on the failed disks. All the data in the other disks is safe.
    If you accidentally delete some files in a disk, you can recover them.
    You can start with already filled disks.
    The disks can have different sizes.
    You can add disks at any time.
    It doesn't lock-in your data. You can stop using SnapRAID at any time without the need to reformat or move data.
    To access a file, a single disk needs to spin, saving power and producing less noise.

    Je tourne avec 3x3To, dont 2 disques sont alloués au stockage proprement dit et 1 disque alloué aux sommes de contrôle. Snapraid vérifie les sommes de contrôle et les fichiers correspondants régulièrement et petit à petit (8% à chaque fois), ce qui fait qu'on est alerté en cas de corruption silencieuse.

    • [^] # Re: Snapraid

      Posté par  . Évalué à 2.

      Un peu étonné de pas voir Snapraid mentionné.

      Peut-être parce que le sujet du journal est la sauvegarde et qu'un raid, aussi résilient soit-il, ne protège pas contre les pertes de données dues à d'autres causes que les problèmes disque. Seule une sauvegarde avec historisation (et si possible deux destinations, une locale et une externe) peut répondre à ce problème. Si le raid en question assure une détection et une correction des erreurs disque, c'est très bien mais ça ne remplace pas une sauvegarde pour autant.

      • [^] # Re: Snapraid

        Posté par  . Évalué à 4.

        C'est bizarre, moi je vois un journal dont le sujet est la perte de données dû à des erreurs silencieuses de disque.

        D'ailleurs cette erreur a eu lieu sur le client de sauvegarde, mais ça peut se produire sur le serveur de sauvegarde (joie et félicité en perspective).

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Merci à tous !

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

    Merci à tous pour vos contributions ! J'ai maintenant beaucoup de matière et il faut que je fasse le tri de tout ça. De prime abord je retiens l'idée de classer les données en froides/chaudes et de les sauvegarder de manière différente, je retiens aussi BTRFS, je vais sans doute attendre de passer à Mageia 8 pour basculer mes systèmes de fichiers en BTRFS, un peu de boulot en perspective.

    https://www.funix.org mettez un manchot dans votre PC

  • # FreeNAS

    Posté par  . Évalué à 1.

    J'utilise depuis des années FreeNAS (qui s'appelle maintenant TrueNAS Core)

    C'est un logiciel libre spécialisé dans le stockage et qui s'appuie sur FreeBSD et ZFS. C'est très facile à utiliser et ça devrait résoudre la plupart des points faibles de ton ancien système de sauvegarde.

Suivre le flux des commentaires

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