Journal Sauvegarde le retour du retour

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
10
11
avr.
2021

'lut les moules,

Les déboires récentes de perte de données évoquées dans un récent journal m'ont rappelé qu'il fallait que je te fasse un retour des solutions mises en place suite à mon précédent journal sur la sauvegarde des données.
Tout d'abord je tiens à vous remercier pour toutes les bonnes idées suggérées dans ce dernier journal qui m'ont été à la fois extrêmement instructives et utiles. Il m'a fallu mener une petite analyse et faire des choix adaptés au mieux à mes modestes besoins.

Résumé des épisodes précédents

Tout d'abord un résumé rapide des épisodes précédents, j’ai perdu des données suite à un problème disque bas bruit, non détecté, conduisant à une corruption de données qui a corrompu également la sauvegarde saine. Quand je m'en suis rendu compte, il était bien trop tard et mes outils de sauvegarde et restauration basés sur rsync ne m'ont pas été d'une grande utilité.

Mon nouveau dispositif de sauvegarde

Vos commentaires m'ont donc ouverts les yeux et j’ai revu de fond en comble ma stratégie de sauvegarde qui ressemble maintenant à quelque chose comme cela :
Titre de l'image
On retrouve mon serveur Dell avec son RAID 1 hard système et le RAID 5 hard de données partagées avec des données copiées sur d'autres PC du réseau et sur 2 unités de disques externes.

Le principe de la sauvegarde

Sur le principe de sauvegarde, suite à vos judicieux conseils j’ai maintenant distingué les données chaudes et les données froides. Les données froides sont les données qui évoluent peu ou pas du tout, typiquement des photos ou des vidéos le plus souvent, a contrario les données chaudes sont celles qui évoluent plus régulièrement comme les mails par exemple. Les stratégies de sauvegarde seront différentes suivant que les données soient froides ou chaudes.
Pour les données froides qui évoluent peu, je choisis des copies manuelles, cela permet de s’assurer de leur intégrité, les données chaudes sont copiées automatiquement, avec toutefois un test d’intégrité au préalable des disques.

Cette stratégie de sauvegarde est basée sur différents outils, dont le détail de configuration est donné dans les différents liens, pour les données froides ça sera :

  • le système de fichier btrfs qui intègre intrinsèquement des fonctionnalités facilitant la sauvegarde,
  • unison un outil graphique qui gère les sauvegardes en mode manuel.

Et pour les données chaudes :

  • l’outil borg qui permet de mettre en place très facilement des sauvegardes incrémentales que j’utilise plutôt pour les données chaudes

Plus précisément les données chaudes sont sauvegardées incrémentalement sur un disque externe branché au serveur. Les données froides sont sauvegardées sur le même disque externe sous forme de snapshots btrfs et copiées via unison sur d’autres postes du réseau. Les snapshots btrfs sont également copiés sur un Terramaster D5-300c qui regroupe un ensemble de disques durs divers dont je ne savais pas trop quoi faire. Pour encore plus de sécurité, je stocke un disque de données froides issu du Terramaster dans mon coffre au boulot.

Les tests d'intégrité

Parallèlement j’ai mis en place des tests d’intégrité des disques avec smartmontools et btrfs même si je suis plus réservé quant à leur efficacité, les disques ayant tendance à crasher sans crier gare.

La suite

La suite ? Et bien je dirais on se donne rendez vous au prochain crash :-) on verra si mon dispositif a été efficace.

En toute rigueur, il me manquerait sans doute à passer mes disques systèmes en btrfs et mettre en place une stratégie de sauvegarde pour mes disques système. OpenSuse le propose par défaut, ce n'est pas le cas de ma Mageia où il faut bricoler un peu, mais j'estime que ce n'est pas primordial, un disque système se reconstitue assez vite, d'autant que je prends la précaution quand même de sauvegarder, en sauvegarde froide, les fichiers les plus importants du système pour ne pas avoir à les reconstruire.

J'envisage également de placer certaines données dans le "cloud", alors certes le cloud peut également partir en fumée, mais ce n'est pas plus mal de multiplier les supports de sauvegarde.

Je reste preneur évidemment de vos commentaires et retours d'expérience.

  • # Éloignement géographique des backups

    Posté par  . Évalué à 2.

    Joli retour d'expérience.

    Penses peut-être aussi à éloigner géographiquement tes sauvegardes … en cas de vol ça serait con que les voleurs partent avec "tout" (dans ce cas un "long" cable usb et le disque externe planqué dans le faux plafond par exemple (ou un mini nas avec du rj45 si pb de distance)).

    En cas d'incendie ou de gros dégâts des eaux c'est encore plus problématique.

    -> Un petit serveur chez un membre de ta famille qui a la chance d'avoir une connexion fibre et le problème est réglé. Modulo le fait de penser à chiffrer les données sauvegardées si jamais tu veux te prémunir contre le vol de tes données si celles ci sont "sensibles" (en vérité tout est sensible pour moi mais bon).

    eric.linuxfr@sud-ouest.org

  • # [HS]Les liens vers funix.org sont brisés

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

    Juste pour te dire que les liens de ton nal pointent tous vers la même page : https://www.funix.org/fr/linux/index.php

    Merci pour ce journal et pour tout le boulot que tu as fait sur funix.org.

    « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # Nextcloud local & Rclone

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

    Bonjour à tous

    Chez moi, 2 portables, 2 personnes pouvant allez sur n'importe lequel des portables, une carte odroid avec un disque de 1To et une freebox delta avec des disques de récup.

    La carte odroid sert de de NAS pour les photos, musiques et autres données ne bougeant pas.
    Une VM debian sur la freebox qui fait tourner un Nextcloud qui synchronisent les 2 portables et qui sert de sauvegarde.

    Pour les grincheux qui pensent que synchro n'est point sauvegarde ; chaque fois qu'un fichier est créé sur un des 2 portables, ce fichier est dupliqué sur Nextcloud en live. (En local, c'est quasi immédiat) Chaque fois qu'un fichier est supprimé d'un des portable, le fichier du Nextcloud va dans la "corbeille" de Nextcloud. Chaque fois qu'un fichier est modifié sur un des portable, le fichier d'origine de Nextcloud va dans un dossier files_version.

    Quoique qu'il se passe sur un des portable, c'est reporté sur l'autre au démarrage. De plus, aucun fichier ne peut donc être accidentellement supprimé ou altéré. Un exemplaire est toujours récupérable sur Nextcloud.

    Et si mon appart prend feu ? Scripts de backup Rclone chiffré du Nextcloud et du NAS chez OVH tout les soirs !

    Jamais eu de problème pour l'instant, à si, c'est la sauvegarde OVH qui a prit feu …

    • [^] # Re: Nextcloud local & Rclone

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 11 avril 2021 à 19:13.

      Pour les grincheux qui pensent que synchro n'est point sauvegarde

      J'en suis un, mais ce que tu fais est très bien : tu fais est bcp plus que de la synchro. Ce qui est dangereux c'est bien évidemment la synchro non versionnée.

      Et si mon appart prend feu ? Scripts de backup Rclone chiffré du Nextcloud et du NAS chez OVH tous les soirs !

      Yep, pour moi c'est la bonne utilisation du cloud : une archive "au cas où".

      Mais en gros tu maitrises toi-même un premier niveau de sauvegarde.

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

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3. Dernière modification le 13 avril 2021 à 15:37.

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

      • [^] # Re: Nextcloud local & Rclone

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

        Si le fichier est corrompu tu dupliques un fichier corrompu.

        Comme une sauvegarde : tu peut rsync depuis plus de 10 ans tes photos corrompues, tant que tu ne les regarde pas :)

        Pour l'historique, je m'en fou. Je ne "sauvegarde" que quelques dossiers utilisateurs persos. Et si tout crame chez moi (Ordinateurs & Nextcloud), j'ai une sauvegarde chez OVH.

        rclone copy SecStorage: ./restore

        Ce n'est pas parfait, mais cela correspond à ce que j'ai besoin, un truc qui marche tout seul par défaut (synchro Nextcloud entre les 2 pc + téléphones) et un "cron rclone dans cloud" toutes les nuits.

        La seule chose qui m'embête, c'est où sauvegarder le fichier de conf de Rclone, parce ce que si tout crame chez moi je risque de pleurer la clef USB :)

    • [^] # Re: Nextcloud local & Rclone

      Posté par  . Évalué à 2.

      J'ai grossomodo le mm setup : owncloud chez OVH et rsync chez moi.

      OVH a une meilleure dispo que moi et une meilleure bande passante. Donc je préfère avoir le owncloud chez eux.

      Les clients owncloud sont vraiment performants. Sur desktop, la synchronisation est quasi immédiate et ça prend peu de ressources.

      Tout est automatique et bien rangé ; c'est plutôt plaisant comme dispositif.

  • # S3 ?

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

    Est-ce que l'un de vous connais des outils simples pour envoyer des données vers un serveur S3 sur le cloud ? J'avais tenté chez ovh, mais cela avait l'air bien complexe à première vue.

    rclone semblait un bon candidat pour chiffrer sur le client, mais il demande une sacré liste de paramètre cryptique.

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

    • [^] # Re: S3 ?

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

      Chez OVH :
      1. Tu as ou tu ouvre un compte (https://www.ovh.com/manager).
      2. Public cloud -> Créez un conteneur d'objet.
      3. Créez un utilisateur (Notez le mot de passe).
      4. Téléchargez le fichier de conf rclone (OVH le fournit)
      5. Ajoutez le mot de passe dans le fichier
      6. copiez ce fichier sous ~/.config/rclone/rclone.conf
      exemple de fichier :

      [BackupStorage]
      type = swift
      env_auth = false
      auth_version = 3
      auth = https://auth.cloud.ovh.net/v3/
      endpoint_type = public
      tenant_domain = default
      tenant = xxxxxxxxxxxxxxx
      domain = default
      user = xxxxxxxxxxxxx
      key = xxxxxxxxxxxxx
      region = GRA

      Puis
      rclone -v mkdir BackupStorage:test

      Après, le site de Rclone fournit le liste des commandes et des exemples.

    • [^] # Re: S3 ?

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 12 avril 2021 à 15:38.

      Il y a différrntes manières.

      minio, s3cmd en ligne de commande.

      Il y a des systemes basés sur fuse.

      je backup sur s3 via restic.

      j'ai une instance perso nextcloud paramétrée pour utiliser un stockage s3 chez wasabisys

      Il y a des clients androids

      Et plein d'autres trucs auxquels je ne pense sans doute pas.

    • [^] # Re: S3 ?

      Posté par  . Évalué à 1.

      Honnêtement rclone est super (s3cmd m'a parfois posé des problèmes), je te déconseille d'utiliser autre chose. La config est bien documentée et il y a un mode wizard.

      Pour backup j'utilise des buckets S3 versionnés chez AWS. Il faut finalement donner les bons droits à rclone pour qu'il n'aie pas la possibilité d'affecter les versions précédentes des fichiers.

    • [^] # Re: S3 ?

      Posté par  . Évalué à 1.

      Moi j'envoie vers Backblaze B2 (avec rclone), c'est pas cher du tout (moins qu'Amazon), et l'interface client est pas imbitable comme celle d'OVH

    • [^] # Re: S3 ?

      Posté par  . Évalué à 2.

      J'utilise https://github.com/kopia/kopia ça permet à la fois d'envoyer sur S3 en même temps c'est dédupliqué, compressé, incrémental etc… Sinon en rclone marche très bien aussi.

  • # Mes backups

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

    J'ai revu mon système de backup également récemment, principalement pour backuper mon PC et ceux de la famille. C'est l'occasion de faire un retour d'expérience.

    J'ai 3 niveaux de backup:
    - un rsync de tous les PC vers un disque dur externe (chiffré en LUKS)
    - archives borg vers un autre disque dur externe
    - archives borg vers un serveur distant

    Borg est vraiment sympa:
    - incrémental: on ne renvoie pas tout à chaque fois
    - chiffré: le serveur n'a pas accès aux données
    - dédupliqué: un même (bout de) fichier présent plusieurs fois dans une même archive ou dans plusieurs archives n'est stocké qu'une fois
    - facile à utiliser
    - un snapshot est un peu comme un commit git sur le principe (donc pas de différenciation "full" vs "incrémental" comme dans d'autres systèmes)
    - on peut "monter" une archive via FUSE (borg mount) pour naviguer dedans, ce qui est très pratique

    Pour le serveur distant, après de nombreuses années à l'envoyer sur une machine que je contrôlais chez mes parents, j'ai finalement opté pour un service de stockage en ligne chez LimaLabs, avec un accès SSH et borg. En "archive storage", c'est $15/an par block de 500GB (il y a aussi rsync.net et BorgBase sinon).

    Je réalise les backups manuellement régulièrement (il faut que le disque dur externe soit branché, que les machines que je backup soient allumées, etc., et ça permet de ne pas stocker une passphrase SSH quelque part).

    Pour le backup incrémental, certaines données sont un peu pénibles à backuper par contre.

    Il y a d'un côté les données qu'on veut sauvegarder mais qui changent beaucoup pour pas grand chose.
    - .thunderbird contient un gros fichier INBOX qui contient tous les mails (10G sur certaines machines): dès qu'un nouveau mail est reçu, le fichier change parfois complètement (pour mes propres mails, je backup le Maildir sur le serveur directement, ça résout le problème)
    - .mozilla/firefox a un peu le même problème
    - le .git des projets (j'ai souvent plein de branches locales pushées nulle part, donc c'est important à sauvegarder), car git packe les objets dans des gros fichiers. D'un jour sur l'autre sur vlc par exemple, j'ai 750Mo de données incrémentales, alors que presque rien n'a changé.

    Et il y a aussi les données qu'on ne veut pas backuper mais qui sont longues à lister manuellement et à maintenir (par exemple dès qu'on crée un nouveau builddir pour un projet, à moins de se forcer à respecter un certain nommage).

    Comme compromis, je rsync tout le home, à l'exception de très gros dossiers facilement excluable (.cache, .ccache, .cargo, .gradle, .rustup). Si le disque dur meurt (ce qui est le plus probable), je peux restaurer rapidement l'intégralité.

    Et je n'archive dans borg (local et distant) que les trucs "importants" (Documents/, les albums photos, les dotfiles, pas .mozilla/firefox complet mais juste key4.db et logins.json, le .git des projets importants uniquement…).

    blog.rom1v.com

  • # Je vais donner l'impression de troller mais ... BTRFS ?

    Posté par  . Évalué à 1.

    En passant sur Fedora 33, je suis passé à btrfs, c'est le fs par défaut pour le profil "Workstation".
    J'ai survolé les caractéristiques de btrfs et ça n’excitait pas mal. Les snapshots et les volumes logiques qui partagent un même volume physique (j'ai oublié les termes techniques).

    Puis j'ai creusé un peu la doc de btrfs. J'ai vu 2 défauts (pour moi).
    Désolé mais j'ai oublié un des défauts (je crois que c'est lié au raid où les perfs ne sont pas toujours au niveau attendu, mais c'est un peu accessoire ici).

    Le gros défaut (pour moi hein) est que btrfs ne gère pas les "badblocks". Il m'est arrivé d'avoir des disques avec quelques secteurs défectueux et qui marchent encore durant des années. Évidemment, si les données sont précieuses, on peut bien casquer pour avoir des disques sans secteurs défectueux. Surtout que les disques sont peu chers (sauf si on stocke du lourd genre beaucoup de vidéos).

    Bref, je suis retourné à ext4. Formatage et tout, un peu pénible de refaire ce qu'on vient faire.

    Je ne dissuade pas d'utiliser btrfs qui est un bon fs avec des fonctionnalités très alléchantes. Surtout que les SDD, de plus en plus courants, gèrent eux-même les badblocks.
    Je donne cette info car j'ai remarqué qu'elle était pas très connue et que j'étais très surpris de constater ce manque.

Suivre le flux des commentaires

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