Journal RAID is no Backup!

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
39
29
sept.
2017

Suite à une discussion avec mon copain Léo, je retombe sur ce tweet magnifique : https://twitter.com/leyrer/status/847816162557689857.

Je sais qu’en écrivant ici j’ai une audience assez érudite, mais sauvons l’humanité et rajoutons une couche :

Repeat after me: RAID is no Backup!

Répète après moi : le RAID n’est pas de la sauvegarde !
Titre de l’image

Alors, ça sert à quoi le RAID ?

On voit bien avec la photo que le gars pouvait avoir douze disques de redondance, ça ne lui sert plus à rien. Ça marche aussi avec une inondation, un cambriolage, une surtension, un orage magnétique (bon, là j’exagère), etc., ou un rm -rf mal tapé. La photo provenant de l’incendie d’un data center dans le Wisconsin, on se dira qu’ils avaient pris toutes leurs précautions.

Qu’on se le dise : le RAID ne protège pas de tout. En revanche, il protège du plus probable. Tellement probable qu’on peut dire à coup sûr que ça vous arrivera un jour : le panne de disque dur. Un beau jour (ou pas), le disque décide que c’est fini, qu’il a largement dépassé son MTBF d’heures de travail et que, à partir de dorénavant, ce sera sans lui. Et ça, ça arrive tous les jours.

Mais comment faire ?

Des sauvegardes pardi ! On le sait tous, mais c’est pas forcément facile. Surtout qu’une sauvegarde pour être efficace doit être :

  • automatique (sinon on la fait de temps en temps, puis plus du tout) ;
  • éloignée (pour se protéger de l’incendie ou de l’inondation).

Voici une description de mon système, adapté à une famille de bons gros geek quatre personnes et un peu plus sûrement :

  • un espace RAID disponible sur un NAS, j’ai opté pour du RAID 6. Le prix d’entrée est assez cher (deux disques de « perdus » en espace, ainsi que le besoin d’un processeur un peu costaud), mais les avantages sont assez importants : je peux perdre deux disques [*] tout en gardant le service, et surtout j’en rajoute à la volée très facilement pour augmenter la taille ;
  • du Gigabit filaire dans la maison, ainsi ça va vite, c’est transparent pour tout le monde et certains fichiers sont disponibles directement via le NAS, comme les photos et vidéos familiales ou la mise en commun des CD et DVD « rippés » ;
  • une sauvegarde des machines de la maison sur cet espace ;
  • j’utilise rsnapshot pour faire les sauvegardes, ce qui signifie qu’elles sont incrémentales et que je peux par exemple récupérer un fichier que mon fils a effacé une mois auparavant ;
  • une liaison à 100 Mbit Wi‐Fi avec un voisin (deux antennes Ubiquity) : on peut donc introduire de la distance ;
  • une machine chez le voisin avec Openmediavault, une distribution assez sympa pour faire un NAS. Bon, la distrib’ ne me sert pas à grand’chose vu que je n’utilise que rsync en fait, mais c’était l’occasion de jouer avec ; c’est un PC de récup (mini‐ITX avec Atom soudé) et un simple disque de 2 To. ;
  • rsync quotidien du dernier instantané (snapshot) des machines chez le voisin : si je perds mon NAS (cf. photo d’illustration), je perds l’historique (je ne pourrai donc pas récupérer le fichier effacé par mon fils il y a un mois), mais j’ai toutes les sauvegardes de la famille (ainsi que les photos et les vidéos familiales, sûrement le bien le plus précieux de mon réseau local). Je sauvegarde également les médias photos, vidéos et audio présents sur le NAS.

Et c’est pas un peu too much tout ça ?

Meuh si évidemment !!! Mais pas tant que ça en fait si l’on considère que ça me permet ainsi raisonnablement de m’assurer :

  • contre le rm -rf (y compris en local de la part de mes administrés) ;
  • contre la panne disque (idem) ;
  • contre l’incendie (ouais, bon, là, c’est quand même très peu probable) ;
  • que le voisin jette un œil de temps en temps à ma baraque pendant mes périodes de vacance, j’ai son NAS de sauvegarde chez moi. ;)

Cela dit, on peut tout de même simplifier :

  • on peut remplacer le disque chez le voisin ainsi que la liaison dédiée par un service cloud (Amazon Glacier me tentait bien, par exemple), mais à condition d’avoir une connexion sympa (ce n’est pas vraiment le cas de mon ADSL à 4 Mbit/s) ;
  • on peut directement sauvegarder chez le voisin sur un petit NAS RAID 1 par exemple ; mais, à ce moment, il faut être assez confiant sur la disponibilité de sa propre machine chez quelqu’un d’autre (coupure de la liaison Wi‐Fi, coupure d’électricité du voisin en partant en vacances).

Et vous, vous faites vos sauvegardes ?

[*] J’ai été victime d’un classique du RAID 5 avec un disque spare. Un disque est détecté défaillant et le spare se rajoute donc automatiquement dans la grappe. La synchro démarre et prend plusieurs heures, où l’ensemble des disques est très sollicité. À ce moment, il n’y a pas de redondance (puisque j’avais eu un disque défaillant). Pas de redondance, très haute sollicitation, etc. Vous devinez ce qui s’est passé ? Oui, une second a lâché.

  • # Consommation mémoire

    Posté par  . Évalué à 1. Dernière modification le 29 septembre 2017 à 23:06.

    Pour 1000Go, un backup par mois consomme combien de mémoire?
    Est-ce réellement plus solide que du raid 1 réseau (avec potentiellement un arbitre pour régler les soucis de coupure)?

    A titre perso j'utilise JBOD btrfs pour la partie local et glusterfs pour la partie réseau (mais je n'ai pas encore simulé de panne)

    Je pleure si je subis pareil que sur la photo ^ ^

    Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Consommation mémoire

      Posté par  . Évalué à 5.

      Pour 1000Go, un backup par mois consomme combien de mémoire?

      Ça va dépendre uniquement des données et de la fréquence de modification. Si tu sauvegarde des vidéos qui changent tous les jours, tu vas avoir 1To par mois. Si tu stocke des machines virtuelles qui ont toutes la même installation et qui ne bougent pas beaucoup, tu vas avoir peut-être 200Go au total avec de la déduplication.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Consommation mémoire

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

      Est-ce réellement plus solide que du raid 1 réseau

      Bon, on recommence : "RAID is no Backup!"
      même en réseau.

      A titre perso j'utilise JBOD btrfs pour la partie local et glusterfs pour la partie réseau

      OK. Mais je croyais qu'on parlait backup. Il est ton backup?
      (glusterfs est de la réplication, qui n'est pas du tout du backup, i.e. il n'est pas à l'abri d'un rm ou autre problème survenant en prod)

      Pour 1000Go, un backup par mois consomme combien de mémoire?

      Pas compris le rapport. Mémoire? Je ne vois pas le rapport, 1 Go ou 1 To (~1000 Go) n'est pas ce qu'on compte pour la conso mémoire, mais plus les outils. Ou veux-tu en venir?

      Si tu penses à combien ça va prendre de place sur le disque, entre 1000 Go et nombre de mois x 1000 Go, dépendant de ce que tu fais avec tes données (toi seul sait combien de changement tu as) et de ta politique de suppression des vieilles données (toi seul sait laquelle tu veux).

      • [^] # Re: Consommation mémoire

        Posté par  . Évalué à 2.

        Pas compris le rapport. Mémoire? Je ne vois pas le rapport, 1 Go ou 1 To (~1000 Go) n'est pas ce qu'on compte pour la conso mémoire

        Le rapport avec la mémoire ? Peut-être ici

    • [^] # Re: Consommation mémoire

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

      Pour 1000Go, un backup par mois consomme combien de mémoire?

      Avec rsnapshot, la formule serait : 1000Go + (nb de snapshots par mois * différence entre chaque snapshots)

      Je m'explique :
      - tu payes déjà la totalité de tes données. c'est un backup, pas de magie, on a tout recopié ailleurs
      - ensuite tu fais des snapshots, qui ne vont coûter que la différence entre ces données

      Si tu fais un snapshot par jour, et que chaque jours tu modifies environ 100Go sur ces 1000Go, le mois te coûtera donc 1000 + 30*100 = 4000 Go.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Et vous, vous faites vos sauvegardes ?

    Posté par  . Évalué à 7.

    Borgbackup (j'aime bien le fait de pouvoir pousser mes backups mais que la machine qui pousse ne puisse pas supprimer de données, ça évite la blague du ransomware) avec rsync sur un machine distante.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Et vous, vous faites vos sauvegardes ?

      Posté par  . Évalué à 1. Dernière modification le 30 septembre 2017 à 02:28.

      Pour mon usage j'ai pas besoin de haute disponibilité ni de grande capacité de stockage donc pas de RAID. Par contre, j'utilise Unisson pour mes sauvegardes à froid mensuelles et surtout rhash pour vérifier leur intégrité parce que même si ça prend pas forcément de place, il y a des contenus que je ne veux pas perdre à cause d'une corruption d'écriture.

    • [^] # Re: Et vous, vous faites vos sauvegardes ?

      Posté par  . Évalué à 2.

      borg est en effet vraiment très bien. Je n'ai que quelques semaines de recul dessus mais pour le moment c'est top.

  • # nuage

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

    J'ajouterai une chose. La synchro auto dans le cloud, ce n'est pas un backup non plus.

    • [^] # Re: nuage

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

      Ah bon pourquoi ? Toutes mes sauvegardes sont dans le Cloud (Dropbox ou S3 ou snapshots EBS). Je sais que Dropbox peut décider de fermer mon compte/supprimer mes données à tout moment, mais l'idée c'est que ça a peut de chance d'arriver au moment où je lance un rm -rf --delete-all-the-things * dévastateur.

      • [^] # Re: nuage

        Posté par  . Évalué à 2.

        Sur Nextcloud|Owncloud tu as aussi une corbeille qu'on ne peut vider que via la webui (ou si passé un délais fixé par l'admin).

        Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: nuage

        Posté par  (Mastodon) . Évalué à 5. Dernière modification le 30 septembre 2017 à 09:04.

        Parce qu'un service de stockage dans le cloud ne fournit pas nécessairement un système de snapshot qui te permet de revenir à une version antérieure. N'empêche pas un ransomware de chiffrer tous tes fichiers, ne te protège pas forcément contre tes propres erreurs de manipulation. Après il y'a des services qui ont des fonctionnalités (comme des snapshots) qui permettent de s'en approcher mais ce sont souvent des fonctionnalitées optionnelles sur des abos pro et de toute façon à partir du moment où la gestion de tes données/snapshots/ou autre se fait sur un client en local tu n'auras jamais la sécurité d'une infra vraiment séparée. Ça peut éventuellement être un complément pour synchroniser les données d'un serveur de backup mais en soit synchroniser tes données sur google drive par exemple ça ne te protège de pas grand chose.

        Il y'a des vrais services de backup dans le cloud (crashplan, carbonite) mais ce ne sont pas des outils de synchronisation dans le cloud.

    • [^] # Re: nuage

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

      oui, j'aimerais que tu développes, personnellement je trouve ça fort acceptable.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: nuage

        Posté par  . Évalué à 4.

        La synchronisation automatique protège contre le disque dur qui lâche, mais pas contre la boulette ou le ransomware qui chiffre tout ce qu'il trouve.

        En revanche le cloud comme support de stockage distant pour accueillir les sauvegardes est quelque chose de tout à fait envisageable.

        • [^] # Re: nuage

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

          ah pardon, j'avais pas fait gaffe au détail "synchro". oui en effet, dans mes critères, ça protège pas du "rm -rf".

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: nuage

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

      La synchro auto dans le cloud, ce n'est pas un backup non plus.

      tu peux argumenter?
      Je ne vois pas en quoi ce n'est pas un backup, du moins une cloud correct c'est-à-dire qui s'occupe des backups (donc "le ransomware qui chiffre tout ce qu'il trouve" ne dérange pas, clic droit sur le fichier/répertoire "version précédente"). Après, si il faut prendre en compte les mauvais clouds… Dans ce cas dire "La synchro auto dans un mauvais cloud, ce n'est pas un backup non plus."

      • [^] # Re: nuage

        Posté par  (Mastodon) . Évalué à 2. Dernière modification le 30 septembre 2017 à 10:00.

        https://linuxfr.org/nodes/112778/comments/1715341

        C'est exactement ce que je dis. Pour qu'un stockage dans le cloud puisse être considéré comme un backup il doit offrir certaines fonctionnalités étendues que la plupart ne fournissent pas dans leur offre de base. Chaque offre est à étudier et dès lors que tu peux manipuler en écriture les fichiers sauvegardées, les snapshots et/où les périodes de rétention directement depuis le client tu ne peux plus considérer ça comme une sauvegarde fiable.

        Autrement dit ce n'est pas parce qu'une donnée est sur un stockage distant qu'elle ne peut pas être altérée depuis ta machine locale.

        • [^] # Re: nuage

          Posté par  . Évalué à 5.

          Attention que c'est la même constat pour pas mal de solution de backup où c'est la machine qui va écrire sur la machine de backup tout en pouvant y supprimer des fichiers. D'ailleurs, les solutions comme Borg où on peut avoir un client qui n'a accès qu'en append sur le serveur de backup et le serveur de backup qui n'a pas accès sur la machine client ne sont pas si courante.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # raid5

    Posté par  . Évalué à 5.

    J'ai eu le coup d'un disque sur un raid5 qui lâche… Et évidemment un second disque n'a pas tardé à rejoindre le premier : numéro de série similaire puisque acheté en même temps, sans doute le même problème à la base. Ce n'était qu'un nas de sauvegarde

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

  • # "Surtout qu'une sauvegarde pour être efficace doit être :"

    Posté par  . Évalué à 7.

    • Testée, TEstée, TEStée, TESTée, TESTÉe, TESTÉE de temps en temps.

  • # Au boulot

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

    Au boulot c'est en gros 200Go de données qui bougent tout les jours, il y a de la VM (vmware), de la base de données Oracle/Mysql et les données utilisateurs (office, images…).

    On a prévue slip/caleçon/ceinture/bretelles/parachute… Les données sont stockés sur des espaces des travail prévues sur une baie NetApp avec tout ce qui faut (double alim, doubles disques, doubles réseaux) pour prévoir la panne matériel, ensuite backupé sur un nas syno (avec du raid) et ensuite le tout est sortie sur un autre syno (encore du raid) chez Ikoula avec une fibre 100/100.

    Au niveau des programmes il y a ArcServe UDP pour les VM, ArcServe backup pour les fichiers et db que je suis en train de virer car infernal à utiliser au quotidien à cause d'une interface qui date d'un autre temps et d'une logique basée sur le fonctionnement en cassette de backup (dat, lto…) et puis du script maison pour les dump et Windows (robocopy).

    Pour remplacer ArcServe Backup je test BackupPC 4.1.3, je l'avais utilisé quand c'était encore la branche 3 puis viré car il ne gérait pas la partie VM (ce qui est toujours le cas) mais comme j'ai UDP (oui je me suis laissé avoir par les chants des sirènes d'une interface unifié pour les VM et les fichiers et les DB…).

    Un exemple dernièrement nous avons eu un coupure de courant, l'onduleur a pris le relais pendant 30mn et il aurait dû lancer la procédure d'arrêt en fin de batterie… "Aurait dû", car pour une raison encore inconnu ça n'a pas été le cas. Du coups arrêt brutal des toutes l'infra et résultat des courses une LUN complètement morte avec un fs irrécupérable. Pas de bol c'était la db Oracle de l'ERP qui était dessus, je commence à transpirer et après quelques appelles à des amis ont (enfin surtout mes amis), remontent le dump du dernier backup, pas mal d'heures d'import après tout est reparti. Si le dump local avait eu un problème il nous était possible de revenir à celui de la veille, de l'avant veille, de l'avant avant […] veille. Je vous avoue que j'ai eu bien transpiré. Car pas d'ERP, plus d'activité pour la société. Je pense que j'aurais perdu mon boulot et pas que moi car un fort risque que la boite ferme la porte à cause d'un onduleur qui a chié dans la colle.

    Born to Kill EndUser !

    • [^] # Re: Au boulot

      Posté par  . Évalué à 3.

      Logiquement ton onduleur aurait dû lancer la procédure d'arrêt propre mais ça n'a pas marché…
      Mais vu l'importance de ces machines pourquoi ne pas avoir surveillé toi même ? Par exemple au bout de 32min ouppps le script ne s'est pas lancé, je le fais en manuel.
      Ou alors c'est arrivé en pleine nuit et tu n'as vu la notification que le lendemain matin ? :D

      • [^] # Re: Au boulot

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

        Logiquement

        Je suis d'accord avec toi et pas de bol c'est arrivé en pleine nuit… Et comme beaucoup de monde la nuit je dors malgré la notif envoyée sur mon téléphone posé sur ma table nuit…

        Born to Kill EndUser !

    • [^] # Re: Au boulot

      Posté par  . Évalué à 5.

      et 2 onduleurs de capacité différente et marque différente, le premier foire, le deuxième devrais fonctionner. Vu le prix d'un onduleur pro, ca devrait le faire. ca depend du tiens, évidement ;)

      c'est le probleme des truc critiques que tu ne peux pas tester :D, attention demain je teste l'onduleur jusqu'a la mort de la BDD.

      la bonne question est : va tu refaire un test de l'onduleur pour voir que le script fonctionne correctement ? et tu nous fait un petit journal la dessus …

      • [^] # Re: Au boulot

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

        Avec 2 onduleurs tu aura la même problématique lorsque les batteries seront vides sur le 2. Autant envisager un onduleur pour pallier le temps de démarrage d'un groupe électrogène. Ensuite tu es sur l'autonomie du groupe qui est sans fin tant qu'il y a du gasoil dans le réservoir ou une personne pour en remettre.

        J'ai un smartups 5000va, il encaisse pas mal, avec la petite carte réseau qui va bien et une vm capable de piloter l'arrêt des VM's et des hôtes ESX, ensuite un agent sur chaque machine physique (autre que ESX) qui est pilotée par cette même VM. Reste que la baie qui pour le moment n'est pas très ouverte à la communication avec l'onduleur :(

        Born to Kill EndUser !

        • [^] # Re: Au boulot

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

          Déjà, si tu veux que ton onduleur marche, tu changes les batteries en préventif :)

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # syncthing

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

    J'utilise personnellement syncthing (https://syncthing.net/) sur les différentes machines de la maison, et une bécane envoie ce que je veux conserver en dehors de chez moi sur un serveur distant.

    Interface cli ou web-ui, assez discret en ressource, fait aussi de la préservation de fichier. Perso je l'utilise juste pour du clonage instantané.

    Si ça peut intéresser

    • [^] # Re: syncthing

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

      Et en plus il y a une version Android qui marche bien sur F-Droid.

    • [^] # Re: syncthing

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 01 octobre 2017 à 18:43.

      Syncthing c'est sympa, mais tu n'as qu'une image de tes données au moment du backup, tu n'as pas l'historique. Donc contre le ransomware, ça ne marche pas.

      Personnellement j'utilise restic qui backup tout dans le cloud (sur un object storage). C'est chiffré, il y a de la déduplication, et j'ai l'historique de tous mes backups, je peux revenir à la version que je veux. Par contre ce n'est pas automatique, il faudrait que je vois comment faire ça tout en protégeant ma passphrase.

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

      • [^] # Re: syncthing

        Posté par  . Évalué à 2.

        Heu non tu peux faire du versioning aussi.

        • [^] # Re: syncthing

          Posté par  . Évalué à 2.

          Ou des snapshots côté serveur qui sont alors backupée comme toutes autres données du serveur.

  • # Vérification

    Posté par  . Évalué à 9.

    C'est une question que je voulais poser dans les forums depuis un moment.

    Plusieurs commentaires proposent des solutions de sauvegarde (rsync, Unison, BorgBackup, SYncThing, …) mais y en a-t-il qui proposent nativement de vérifier que la sauvegarde tourne bien ?
    Lorsque ce journal a été posté j'étais justement en train d'écrire un script bash qui me permet de créer un fichier aléatoire dans mon arborescence locale et de s'assurer qu'il est bien présent dans l'arborescence distante (le backup). Ensuite je cron ce script quotidiennement pour recevoir une alerte en cas de bug. Je ne sais pas si c'est la meilleure manière de faire mais c'est ce que j'ai trouvé de plus simple (on peut calculer un hash de l'arbo par exemple mais sur plusieurs gigas c'est long…)

    • [^] # Re: Vérification

      Posté par  . Évalué à 5.

      La seule solution que je connaisse est :
      1. utiliser un logiciel (ou utilitaire, etc) qui prévienne du moindre pépin (erreur, avertissement, tout)
      2. utiliser un système de suivi automatisé : historique de la taille totale, historique du nombre de fichiers sauvegardés/modifiés/etc + alerte sur dépassement des seuils que tu fixes
      3. un script qui vérifie les caractéristiques de certains fichiers. Par exemple le fichier vital.db doit être présent dans la sauvegarde et faire entre 145 Gio et 150 Gio. Le fichier vérif.txt (fichier bidon fait uniquement pour contrôler la sauvegarde, il faut en mettre un peu partout) doit contenir un texte bien précis, etc
      Ca n'est pas parfait, mais globalement c'est relativement solide.

      La dernière fois que j'ai testé, je n'ai pas été convaincu par backupchecker.

    • [^] # Re: Vérification

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

      Ici c'est simple,
      deux salles serveurs dans deux bâtiments différant (relier en fibre ils sont à 50m d'un de l'autre les bâtiments)
      tout est doublé,
      j'ai deux machines dans chaque salles qui fait du rsnapshot sur les serveurs qui sont dans l'autre salle de l'autre bâtiment.
      Sur la supervision j'ai fait un script qui va regarder l'âge de hourly.0 et qui va remonter une alarme si il devient trop agée.
      Et ça arrive parfois (une machine de sauvegarde était dans les choux).

      Les sauvegardes sont régulièrement testé de deux façons:
      - un utilisateurs qui à massacré un fichier ou un partage réseau
      - on remonte une vm pour voir si ça marche (c'est con mais c'est pas une fois qu'on en aura besoin qu'il faudra voir que nos sauvegardes sont pas foireuse)

      A la maison j'utilise aussi rnapshot sur mon instance de nextcloud (j'ai un serveur dans ma cave) puis je fait un rsync sur un petit kimsufi, comme ça j'ai une copie du data de mon nextcloud à 900km d'ici.
      Bon je suis un chanceux j'ai une connexion 500/50 mbs donc c'est rapide.

    • [^] # Re: Vérification

      Posté par  . Évalué à 0.

      Bonjour, concernant la vérification, Borgbackup offre nativement cette possibilité : borg check permet de vérifier chaque archive et repository borgbackup(http://borgbackup.readthedocs.io/en/stable/usage/check.html)

      La commande borg extract avec l'option --dry-run va encore plus loin, je vous laisse prendre connaissance de la documentation officielle (http://borgbackup.readthedocs.io/en/stable/usage/extract.html)

      Évidemment, les rapports de sauvegardes sont fondamentaux (success ou fail) et même si Borgbackup n'offre pas nativement de notification mail, l'ajout d'un simple MAILTO=titi.toto@chezmoi.com dans le crontab joue parfaitement ce rôle.

      Cordialement.

    • [^] # Re: Vérification

      Posté par  . Évalué à 1.

      --checksum avec rsync

  • # Ici

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 30 septembre 2017 à 16:31.

    contre le rm -rf (y compris en local de la part de mes administrés)

    Perso, sur les serveurs, je rajoute ça: https://pastebin.com/JjVMYT76 dans le bashrc.

    Comme ça rm -fr plop fonctionne mais par contre rm -fr plop* si il existe plusieurs correspondances demande une confirmation.

    Parce que sur les claviers AZERTY, le * est vraiment trop proche de Entrée…

    • [^] # Re: Ici

      Posté par  . Évalué à 7.

      Je pertinente parce que ça pourrait servir mais

      "it is a bad idea to alias rm at all, because it will come back to bite you when you are in a shell that has no protective alias and your brain is accustomed to having a "safe" rm."
      "Better to use trash or similar command on your system that sends files to the (recoverable) "recycle-bin"."
      https://unix.stackexchange.com/a/261452

      • [^] # Re: Ici

        Posté par  . Évalué à 2.

        Se protéger contre les erreurs n'est pas la même chose que faire n'importe quoi en pensant qu'on est protégé.

        • [^] # Re: Ici

          Posté par  . Évalué à 5. Dernière modification le 02 octobre 2017 à 16:25.

          Va expliquer ça à ton cerveau et ses chemins cognitifs privilégiés :)

          Perso, je pense qu'il est bon que le rm mette un petit coup d'adrénaline avant de presser enter.

          Un bon compromis est de créer un alias/fonction "rmi" et de prendre l'habitude de l'utiliser à la place de rm. Comme ça pas de risque en changeant d'environnement.

    • [^] # Re: Ici

      Posté par  . Évalué à 4.

      Avec zsh : setopt no_rm_star_silent (http://bolyai.cs.elte.hu/zsh-manual/zsh_16.html)

    • [^] # Re: Ici

      Posté par  . Évalué à 1.

      Prend un clavier Azerty belge, il faut appuyer sur MAJ pour pouvoir utiliser la touche * à côté du ENTER.

      Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Ici

      Posté par  . Évalué à 6.

      Je crée un fichier appelé "-i" à certains endroits sensibles.
      echo " " > "-i"

      ça va demander la confirmation quand on fait rm -rf *

  • # Si votre disque dur a cramé à la reconstruction, c'est peut-être que ce n'était pas le bon disque

    Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 02 octobre 2017 à 09:46.

    Je lis plusieurs fois dans le journal et les commentaires qu'il y a eu des problèmes de disques morts à la reconstruction. En fait, avec les capacités et les fiabilités modernes, c'est probablement normal si on a essayé de reconstruire un RAID fait avec des disques « grand public ». Je détaille les calculs ici.

    Donc : pour faire du RAID, achetez des disques « spécial RAID » avec une haute fiabilité.

    La connaissance libre : https://zestedesavoir.com

  • # mon cloud à moi

    Posté par  . Évalué à 2.

    Mes fichiers sont gérés par owncloud hébergé sur un serveur physique chez un fournisseur professionnel pour 6€/mois mais qui couvre aussi d'autres usages.

    Owncloud gère un corbeille et du versioning. Il est donc possible de récupérer des fichiers supprimés par erreur ou malveillance.

    Un partie est en plus synchronisée sur un serveur à la maison avec une historisation jours/semaines/mois.

    La restauration est testée par le fait que les fichiers sont utilisées quotidiennement sur plusieurs machines. Je pourrai éventuellement ajouter un test d'intégrité complet et périodique.

    Le seul manque que j'ai à à l'heure actuelle est l'absence de chiffrement côté hébergeur.

    • [^] # Re: mon cloud à moi

      Posté par  . Évalué à 2.

      Le seul manque que j'ai à à l'heure actuelle est l'absence de chiffrement côté hébergeur.

      Tu peux faire du cryfs sur OwnCloud, ça devrait régler ton problème puisque tu n’as plus besoin de faire confiance à l’hébergeur, qui peut chiffrer (ou non) comme ça lui chante.

  • # moi aussi, moi aussi

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

    une nimage vaut mieux qu'un long discours

    PlanSauvegarde

    En résumé :
    - un NAS en RAID1 avec des disques de marque différentes
    - 1 anacron+rsync sur les PCs du parc qui pousse /home et /etc vers le NAS : 1 fois par jour
    - 1 sauvegarde incrémentale (via les outils synology) sur un disque USB : 1 fois par jour
    - 1 sauvegarde complète vers 1 disque USB : 1 fois par jour
    - 1 échange du sus-cité disque USB 1 fois par mois (tiroir fermé à clef au boulot)
    - 1 synchro des photos 1 fois par semaine (outils synology) avec le NAS d'un copain à 200km

    Pour le dernier point la synchro initiale a été faite via le réseau local. De même il sauvegarde ses photos chez moi.

  • # raid5 HS

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

    Question bête, est-ce que ton raid 5 qui a lâché était constitué de disques identiques ? Et quel age avaient-ils ?

    "La première sécurité est la liberté"

    • [^] # Re: raid5 HS

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

      Ils n'étaient pas identique, mais forte présence de WD Green. Ils n'étaient pas très vieux, il y en a même eu un qui a été remplacé gracieusement par WD.

      Les 2 qui ont lâché étaient des WD Green, mais pas achetés ensemble (donc pas de la même série).

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: raid5 HS

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

        C'est quoi pas très vieux ? 1 an ? 5 ans ?

        C'est pour mes stats perso pour faire du changement préventif de disque.

        "La première sécurité est la liberté"

        • [^] # Re: raid5 HS

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

          Pour tes stats, ça m'emmerde de te dire un truc à la louche, mais c'est sûr que l'un des 2 avait moins de 2 ans. L'autre je dirais pas bcp plus, style 3 ans.

          Mais le RAID permet d'éviter le changement préventif et justement d'attendre la panne en toute tranquillité non ? Ou ton but est justement d'éviter le RAID ?

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: raid5 HS

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

            J'avais un raid 0 perso, connaissant le problème de reconstruction d'un raid5. Mais bon, c'est chiant, les outils systèmes considèrent le raid comme une option à part et non comme du "mainstream".

            Je mise plus sur un disque "green" de 5400t/min à un seul plateau qui est censé être le plus fiable : chauffe moins car plus lent, le mode green limite les accélérations des têtes qui augmentent leur durée de vie, idem pour le monoplateau qui limite la quantité de mécanique.

            Restes à savoir quand le changer.

            "La première sécurité est la liberté"

            • [^] # Re: raid5 HS

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

              Ah oui, avec un RAID zero, t'as plutôt intérêt à faire gaffe…et à être à jour de tes sauvegardes ;)

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

              • [^] # Re: raid5 HS

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

                désolé raid 1, je me suis trompé.

                L’intérêt de faire faire un raid 0 de disque lent est pas top :) (avant les SSD j'ai eu 3 raptor en raid0, c'était pas mal…)

                "La première sécurité est la liberté"

                • [^] # Re: raid5 HS

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

                  du coup je vois pas l'intérêt d'anticiper. autant attendre que le disque meure. achète par avance un disque que tu gardes sous la main pour réagir vite, mais c'est tout.

                  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                  • [^] # Re: raid5 HS

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

                    Justement j'ai viré le raid1 qui était chiant à gérer. Et comme les backup sont nécessaires, je suis passé au mono disque.

                    "La première sécurité est la liberté"

            • [^] # Re: raid5 HS

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

              J'avais un raid 0 perso, connaissant le problème de reconstruction d'un raid5.

              C'est… disons, intéressant comme cheminement intellectuel. Remarque, en RAID0, l'avantage c'est que tu n'as absolument aucune incertitude sur les probas d'une reconstruction.

        • [^] # Re: raid5 HS

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

          Ah bin ça alors ! J'ai un disque qui vient de cramer !!

          Il répond pas au smartctl. J'éteins l'ordi, j'attends patiemment 5mn, je rallume… le BIOS le détecte même pas. Je vérifie la connectique (bon, le serveur dans le garage il bouge pas mais admettons)… rien à faire, il est mort de sa belle mort.

          Je ne sais pas exactement depuis quand je l'ai, mais c'est l'un des plus vieux 2To que j'ai.
          Date de fabrication : avril 2010. C'est un Seagate Barracuda Green 2To.

          Son remplaçant en WD Red est commandé.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

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