'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 :
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 Ririsoft . É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 Marc Quinton . É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 nlgranger . É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 mahikeulbody . É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 Astaoth . É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 Funix (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 Marc Quinton . É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 SaintGermain . É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 mahikeulbody . Évalué à 2.
La déduplication de borg fonctionne aussi par bloc (taille paramétrable).
[^] # Re: Pourquoi si compliqué ?
Posté par Astaoth . É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 barmic 🦦 . Évalué à 7.
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 SaintGermain . Évalué à 3.
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 Funix (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 SaintGermain . É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 mahikeulbody . É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 damaki . É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 damaki . É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.
Donc OK pour BTRFS mais avec de la grosse sauvegarde derrière, bien solide.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . É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 Funix (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 SaintGermain . É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 Funix (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 damaki . É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 damaki . Évalué à 1.
J'ajouterais que vérifier ta sauvegarde est plus malin que de vérifier ton disque.
[^] # Re: Pourquoi si compliqué ?
Posté par SaintGermain . É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 barmic 🦦 . É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 SaintGermain . É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 barmic 🦦 . É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,…).
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 SaintGermain . É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 barmic 🦦 . Évalué à 2.
Ok je n'avais pas compris que c'était incrémental cependant :
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.
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.
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 :
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 SaintGermain . É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 barmic 🦦 . Évalué à 2. Dernière modification le 12 novembre 2020 à 17:01.
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.
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.
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 mahikeulbody . É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 damaki . Évalué à 1. Dernière modification le 11 novembre 2020 à 11:03.
Pour le coup, la lenteur de la maturation de BTRFS est un message en soit, même si on exclut Oracle de l'équation qui a son propre agenda autour d'OpenZFS. Sur le sujet du RAID, seuls le 1 et le 0 (et leurs variantes) sont utilisables en prod aux dernière nouvelles. L'outillage n'est pas toujours considéré comme utilisable par les docs officielles et lesdites docs officielles sont d'une qualité lamentable.
Très franchement, malgré tout l'amour que j'ai pour cette techno, je me vois pas utiliser ça sur ma prod au taf ou pour mes sauvegardes, surtout vu que les checksums vont être directement intégré à LVM, grâce aux patches en provenance d'Android.
[^] # Re: Pourquoi si compliqué ?
Posté par zurvan . É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 damaki . É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 SaintGermain . É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 zurvan . Évalué à 3.
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 qdm . É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 YannickP . É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 wilk . É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 Guillawme (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 wilk . É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 Guillawme (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 mahikeulbody . Évalué à 2.
Faux, borg fait de la compression.
[^] # Re: Pourquoi si compliqué ?
Posté par wilk . Évalué à 4.
Restic ne fait s3 mais pas la compression, borg fait la compression mais pas s3, kopia fait les deux.
# Proxmox
Posté par Raoul Hecky (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 ;)
[^] # Re: Proxmox
Posté par damaki . Évalué à 3.
Et c'est en bêta. Utiliser un outil de sauvegarde en bêta, ça n'est sans doute pas l'idée du siècle.
[^] # Re: Proxmox
Posté par Graveen . Évalué à 2.
Pour ses photos de vacances, pourquoi pas.
[^] # Re: Proxmox
Posté par _Tof_ . Évalué à 3.
Ah ben tiens, justement !
https://www.inpact-hardware.com/article/2153/proxmox-backup-server-est-disponible-en-version-1-0
https://www.proxmox.com/en/news/press-releases/proxmox-backup-server-1-0-available
# nouveaux outils
Posté par Tonio (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 amlidajame25 . É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 David (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)
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 Funix (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 InfoLibre . É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 Graveen . Évalué à 5.
Je plaisante, mais j'ai de suite pensé à ça en voyant ton schéma.
A simplifier et à verdir un peu ? :D
[^] # Re: Une centrale nucléaire pour des photos de famille :)
Posté par Funix (site web personnel, Mastodon) . Évalué à 1.
Et encore t'as pas vu le reste du réseau local
je suis un bon client EDF (et j'ai même pas honte…)
https://www.funix.org mettez un manchot dans votre PC
# Quelques principes généraux résultants de l'expérience
Posté par Pol' uX (site web personnel) . Évalué à 10.
Adhérer à l'April, ça vous tente ?
# Sauvegarde Paranoïa
Posté par pyrollo (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 mahikeulbody . Évalué à 4.
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 steph1978 . É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:
Je pense avoir un dispositif correct sans être infaillible :
Les points forts :
Les points faibles :
[^] # Re: dispositif
Posté par Stinouff . Évalué à 1.
C'est-à-dire ?
[^] # Re: dispositif
Posté par steph1978 . É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 Stinouff . É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 Anonyme . Évalué à 3.
Comment tu fais des sauvegardes hors-ligne ?
[^] # Re: dispositif
Posté par steph1978 . É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 Jean-Baptiste Faure . Évalué à 2.
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 steph1978 . Évalué à 4. Dernière modification le 13 novembre 2020 à 10:51.
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.
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 Anonyme . Évalué à 2.
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 steph1978 . É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 Anonyme . Évalué à 2.
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.
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 insert_coincoin . Évalué à 2.
Un peu étonné de pas voir Snapraid mentionné. Juste pour citer le site snapraid.it :
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 mahikeulbody . Évalué à 2.
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 barmic 🦦 . É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 Funix (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 koopa . É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.