Ben oui, ce sujet m’intéresse car je suis motivé par la préservation de ce que je considère comme précieux dans les données que je crée ou récupère sur mon PC. En tant que bidouilleur j’ai moi aussi créé un outil pour cela. Il correspond à mon besoin et j'en suis satisfait. Voici mon cheminement.
J’ai fait une recherche sur LinuxFR.org avec le mot sauvegarde et j’ai trouvé des articles et des réactions toutes très intéressantes. Les besoins, les solutions, les mises en œuvre sont très variées. Chacun choisit ou crée selon son ressenti et finit par être satisfait de ce qu’il fait. Chacun partage son expérience, en espérant qu’elle profitera à d’autres. À mon tour.
Le meilleur outil de sauvegarde est celui qu’on utilise et en lequel on a confiance.
Je te propose un jeu : demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter (photos familiales, documents…). Demande ensuite s’il fait des copies et/ou des sauvegardes. Pour beaucoup, tu seras catalogué comme vilain geek alarmiste. Il y a du travail de prise de conscience !
Sommaire
- Notion de sauvegarde
- Que demande-t-on à un outil de sauvegarde ?
- Un script shell écrit sur un coin de table (au début)
- Scripts bash tzsauv
- Subtilités et pièges
- Conclusion
Notion de sauvegarde
Une analyse très courte de la fonction sauvegarde serait « ranger quelque part des données qui permettront de restituer ce que je considère comme précieux ».
Les mots clés sont « ranger » « quelque part » « données » « restituer » « précieux ».
On a deux verbes « ranger » « restituer », deux localisations de données « quelque part » « ce qui est précieux », et une notion de filtrage dans le mot « précieux ».
Un autre point de vue serait de dire qu’une information précieuse doit résider en deux endroits, pour que la défaillance de l’un puisse être compensée par l’autre. Une des conséquences consiste à doubler les archivages : la libération des espaces précieux par la suppression de données inactives doit être précédée de l’archivage des données à supprimer vers deux supports distincts. Une autre conséquence est d’utiliser un média spécifique pour recevoir les sauvegardes (autre que celui où sont les données à sauver).
La défaillance peut être de plusieurs origines : matérielle, corruption du média, utilisateur qui efface/écrase…
Que demande-t-on à un outil de sauvegarde ?
Si je rédigeais un cahier des charges pour un outil de sauvegarde, je ferais les listes suivantes. Je suis dans mon contexte de PC isolé, ayant accès éventuellement à un petit serveur sur le réseau local.
Fonctionnalités de base :
- sauver juste ce qui a été modifié depuis la sauvegarde précédente => opération rapide,
- compression des fichiers archives => prend peu de place sur l’espace de sauvegarde,
- facile à lancer et rapide en exécution => sera lancé souvent => sécurisation accrue,
- filtrage => possibilité de conserver dans les espaces sauvés des fichiers qui n’encombreront pas les sauvegardes,
- robuste => confiance.
Fonctionnalités nécessaires :
- vérification de l’intégrité des fichiers archives engendrés,
- restitution facile malgré le grand nombre de fichiers archives à exploiter,
- restitution qui permette de régénérer (ailleurs) l’espace sauvegardé dans le même état que ce qu’il était au moment d’une des opérations de sauvegarde (accès aux états antérieurs),
- recherche/extraction de fichiers dans le grand nombre de fichiers archives obtenus,
- traçage pour vérifier le bon déroulement des opérations.
On peut ajouter aussi :
- algorithme ouvert et source fourni,
- qui s’accommode de tous types de support de stockage,
- qui utilise des formats standard,
- qui a toutes ses fonctionnalités accessibles en ligne de commande.
Le dernier point permettra d’utiliser l’outil comme une commande classique. On pourra le lancer dans un script bash qui adaptera l’usage au besoin spécifique du moment (ajout de montage/démontage du média de sauvegarde, rsync réseau des fichiers générés…). C’est une commodité qui me manque quand je suis coincé dans l’usage d’un outil cliquodrome.
Un script shell écrit sur un coin de table (au début)
J’ai rencontré le shell lors de mon premier contact avec Unix, en 1987. Au début j’ai eu le sentiment de régresser par rapport à la syntaxe COM des Vax/VMS. Depuis, j’ai appris à apprécier le bash, bien plus commode que ses ancêtres sh csh. Une des philosophies du shell est de combiner des commandes simples et robustes pour en faire une réponse à un besoin. Par exemple ls | wc -l renvoie le nombre de fichiers/répertoires du répertoire courant. Toutefois, il y a des cas sournois où le résultat est faux, on verra plus loin ce que je qualifie de pièges.
Avec les pipelines, les redirections, les variables, les traitements de chaînes de caractères, et tout le reste, on peut construire à l’infini des séquences d’opérations qui s’appuient sur des commandes simples à lancer mais puissantes (genre outil de compression, outil de parcours d’une arborescence de fichiers…). Beaucoup des fonctionnalités du système GNU sont construites comme cela. Un bidouilleur système ne peut pas ignorer le bash. En plus, emacs permet un accès très commode aux man. Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.
Comme j’aime bien bidouiller, à la fin du 20e siècle j’avais dans l’idée de faire un outil de sauvegarde basique qui s’appuie sur un pipeline : une commande find qui sélectionne les fichiers modifiés, tar pour les copier et gzip pour compresser. J’ai fait divers essais. En 2021, je m’y suis mis sérieusement et j’ai découvert beaucoup de subtilités du bash.
Un des problèmes des sauvegardes incrémentales est de deviner si un fichier doit être sauvé, sans avoir à comparer son contenu avec la version sauvée dernièrement (ça coûte trop cher). Il faut se baser sur les paramètres du système de fichiers. Il faut bien choisir ces paramètres (on surveille leur changement), au risque de rater certains fichiers ou alors d’en sélectionner trop. Je me suis arrêté sur la date de modification du statut et le numéro d'inode.
Scripts bash tzsauv
Je pense être arrivé au bout des spécifications avec l’outil tzsauv que j’ai écrit en bash. Il est disponible sur mon site.
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2ᵉ disque ou sur clé USB. Je fais aussi un miroir du répertoire disque des fichiers archives vers GoogleDrive (ceinture et bretelles). Je fais aussi une sauvegarde à longue périodicité (six mois) sur une clé USB dédiée (double ceinture).
Les opérations principales utilisent les commandes standard find sed tar zstd md5sum, le bash sert à enchaîner tout ça et sert aux dialogues. Pour installer, il suffit de copier deux scripts sur le média de sauvegarde (SauverTZ_ProjXY_01.bash tzsauv.bash, total 96k, ajouter éventuellement l’aide Alire.txt), et modifier quelques paramètres dans l’un des scripts (le script lanceur SauverTZ_*.bash). Le lancement peut se faire en ligne de commande ou via l’explorateur de fichiers par Clic-Droit/Actions/LancerDansKonsole.
L’interprétation du bash prend des ressources, mais je pense qu’elles sont négligeables par rapport à celles prises par les E/S et les commandes standard citées ci-dessus. Le compresseur zstd semble être très performant, en temps et en taux de compression. De plus, il est multithread, ce qui lui permet de tirer avantage des processeurs actuels qui gagnent en puissance en augmentant le nombre de cœurs. Le paramétrage de tzsauv permet de choisir parmi plusieurs formats d’archives.
Pour la sauvegarde vers le 2e disque, j’ai copié sur le Bureau le lanceur de Konsole, puis j’ai renommé la copie et dans ses Propriétés/Application j’ai modifié l’argument (-e ./SauverTZ_ProjXY_01.bash) et le dossier de travail. Du coup, avec juste un double-clic je lance la sauvegarde en mode interactif (-> question « … TOTALE o/n/q ? »). Elle est pas belle la vie ?
Subtilités et pièges
Je fais régulièrement des petits programmes bash pour explorer des détails de fonctionnement soit du bash, soit des commandes. Les man ont beau être détaillés, ils ne peuvent pas tout dire. Pour un bug de tar je suis allé jusqu’à consulter le source C, le corriger par plaisir et vérifier que c’était OK. La remontée du bug n’a pas abouti (personne n’utilise l’option -u de tar ! C’est de la tétrapilectomie, je suis xyloglotte mais pas encore alopécique).
Si tu lances sous bash ls | wc -l puis touch -- 'a'$'\n''b' puis de nouveau ls | wc -l, le nombre renvoyé aura augmenté de deux alors que tu n’as ajouté qu’un seul fichier. C’est normal car le nom du fichier ajouté tient sur deux lignes ! Solution : ls -q | wc -l ou ls --zero | tr '\n\0' '\0\n' | wc -l. Pour voir le résultat de ls -q envoyé à wc -l via le pipeline, entrer ls -q | cat.
Les deux seuls caractères interdits dans les noms de fichiers/répertoires *unix* sont « / » et « \0 » (à méditer).
Je t’invite à créer sous bash un fichier piège par echo "abcd" > $' xyza\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC ', à le sauver avec ton outil, puis à le restituer. Tu verras si ça passe et si le nombre de fichiers est correct. Pour le détruire rm -i *xyza* devrait convenir.
Essaye aussi avec un sous-répertoire mkdir $' xyzp\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC '. Mets-y un fichier, puis fais une sauvegarde totale, modifie le fichier et fais une incrémentale. Ensuite fais un essai de restitution. Joue aussi à modifier le nom du répertoire parent du sous-répertoire piège.
Pour jouer avec ces choses dangereuses, je te conseille de faire une zone à part, ne fais pas courir de risque à ta production. Sur ma Mageia9.2-official, le navigateur Dolphin n’arrive pas à détruire le répertoire piège. Je passe par la ligne de commande.
J’ai rencontré tout plein de pièges et j’en ai imaginé d’autres : un fichier de nom -f, un répertoire de nom -, comment détruire le fichier ? Comment faire un cd vers le répertoire ?
Solutions : rm -f -- -f et cd -- -/ et si le nom du répertoire est dans la variable var cd -- "${var%/}/" (prévoir le cas où var="/").
J’ai découvert que zstd en mode filtre lancé par tar, se met en erreur s’il existe un sous-répertoire de nom - dans le répertoire courant (c’est très particulier, en effet). L’examen des sources de tar et de zstd m’a confirmé le problème, la solution m’a parue simple (inverser l’ordre de deux tests dans le source de zstd) mais la remontée de bug n’a pas abouti. Ce n’est pas grave, je sais maintenant qu’il ne faut pas utiliser tar ... --zstd ..., et je mets plutôt zstd -c[d] dans un pipeline.
J’en raconte un maximum dans le fichier notes01.bash. Toute cette expérience me permet de créer des scripts bash robustes.
Conclusion
Ton outil de sauvegarde est le meilleur, car il te convient.
Fais-toi une idée claire
- de tous tes espaces contenant des fichiers précieux à tes yeux,
- de tous tes espaces de sauvegarde,
- des mécanismes de sauvegarde et de restitution.
Cela participe à la confiance.
N’oublie pas de faire de temps en temps un contrôle d’intégrité des archives et un exercice de restitution. C’est un peu de travail, juste pour vérifier qu’une mise à jour, ou une donnée inhabituelle, ou autre chose, n’a pas mis en défaut la capacité à restituer comme tu l’entends.
Si la restitution est rendue impossible, c’est comme si tu n’avais jamais sauvegardé !
La confiance, en informatique ça se surveille du coin de l’œil
L’informatique est une science exacte pour la machine, pas pour l’homme ; il compense par l’humilité et l’empirisme
# Restic ?
Posté par Franck Routier (Mastodon) . Évalué à 9 (+8/-0).
j'ai découvert Restic (https://restic.net/) en cherchant exactement ce qui est décrit: un outil de sauvegarde qui coche toutes les cases.
Je l'utilise quotidiennement sur environ 1 To de données (1,8 million de fichiers), vers un disque USB local et vers une sauvegarde dans les nuages (chez pcloud).
La sauvegarde incrémentale vers les deux environnements, y compris les vérifications automatiques met environ 10 minutes, ce qui me semble raisonnable.
[^] # Re: Restic ?
Posté par cg . Évalué à 6 (+4/-0).
Voyant ces métriques, je me suis dit que je passe peut-être à côté de quelque chose. Je fais habituellement mes sauvegardes avec rclone sur Swiss Backup (chez Infomaniak). C'est assez long, environ 10-15 minutes pour vérifier, et on arrive facilement à 30 minutes quand il y a du volume à sauvegarder.
Donc j'ai essayé restic. La sauvegarde initiale a pris 23 minutes, et la vérification 8 secondes !
Mon laptop a soufflé pendant la sauvegarde, et pour cause : les 4 coeurs étaient à 100%, et la bande passante bien utilisée (pics à 500Mbps). Rien à voir avec rclone. Ça va vite !
Bref, je vais sans doute passer à restic ! Merci.
Le truc qu'il faut que je trouve maintenant, c'est comment chiffrer le fichier de "config" (le truc qui met les variables d'env, en fait) pour ne pas avoir mon mot de passe de sauvegarde en clair dedans.
[^] # Re: Restic ?
Posté par yned . Évalué à 2 (+2/-0).
La variable d'environnement
RESTIC_PASSWORD_COMMANDpermet d'utiliser un gestionnaire de mot de passe.# D'autres solutions intéressantes
Posté par HubTou (site web personnel) . Évalué à 3 (+3/-0). Dernière modification le 12 juillet 2024 à 20:06.
Bonjour,
Pour la partie smartphone (que votre article ne couvrait pas), j'utilise un serveur dédié NextCloud avec son app iOS ou Android pour synchroniser les données de mon smartphone (photos, vidéos). Sur iPhone, c'est un excellent remplacement d'iCloud ! J'utilise également le client desktop pour synchroniser les répertoires sensibles de mes machines Windows…
Pour mes serveurs Unix, après avoir longtemps utilisé BackupPC, je suis passé aujourd'hui à BorgBackup, qui répond à presque tous mes besoins (hormis l'absence de déduplication au niveau bloc plutôt que fichiers).
En bon paranoïaque, j'évite de faire tourner des serveurs chez moi (pour ne pas risquer un départ de feu quand je ne suis pas à côté !) et je backupe mon serveur de backup sur un autre serveur dédié dans un autre datacenter :-) (les disques durs sont si fragiles)
Ils ne jouent pas dans la même ligue :-)
Le shell (Bash ou autres) reste bien pratique, mais pour tout développement significatif il vaut mieux passer à autre chose. Personnellement, je n'ai jamais vraiment accroché sur Perl (Write Once Read Never !) mais j'adore Python, ses bibliothèques et tous les paquets associés.
Tu as un bouquin en ligne sympa pour découvrir ce langage au travers de cas d'usages courants sur le site Automate the boring stuff with Python.
Et j'ai mis plein d'exemples de commandes Unix écrites en Python sur mon projet PNU, dont une en rapport avec le sujet de la restauration de sauvegardes, dcmp - directory compare, pour analyser les différences entre différentes versions de backups…
Ca te donnera peut-être l'envie de manger du serpent ?
[^] # Re: D'autres solutions intéressantes
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
En bon paranoïaque je ne suis pas administrateur du serveur de backup. Je ne veux pas être le SPOF. Varier les administrateurs c'est à mon avis aussi important que changer de DC parce que l'erreur matérielle n'est qu'une des façons de perdre des données.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: D'autres solutions intéressantes
Posté par HubTou (site web personnel) . Évalué à 1 (+1/-0).
C'est sûr mais il y a plein de façon de gérer ça : l'automatisation, les procédures, l'accès à d'autres compétences informatiques via le mariage, la procréation et/ou les amis :-) et donc à nouveau les procédures.
Pour rajouter quelques trucs auxquels on pense parfois moins :
[^] # Re: D'autres solutions intéressantes
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Borg fait de la déduplication au niveau bloc.
[^] # Re: D'autres solutions intéressantes
Posté par HubTou (site web personnel) . Évalué à 2 (+2/-0).
Ah, en effet, au temps pour moi, je l'avais zappé ou oublié. Merci pour la rectification !
D'après le comparatif posté dans le fil de discussion, il a même l'air d'être plus avancé que la concurrence sur ce point, ce qui en fait donc une solution quasi parfaite de mon point de vue (les critères de rapidité, consommation de mémoire et double chiffrement n'étant pas importants pour mes cas d'usage).
# Comparaison
Posté par cosmocat . Évalué à 4 (+2/-0).
Restic vs Borg vs Kopia:
https://faisalrafique.com/restic-vs-borg-vs-kopia/
Personnellement, j'utilise Borg que je trouvais bien mais j'ai un comportement que je n'explique pas et qui m'a refroidi un peu:
J'ai des dépôts avec des snapshots qui lorsque je les montent avec une version plus récente apparaissent vide donc sans aucun snapshot et sans que borg n'affiche aucune erreur. J'ai mis un bon moment avant de comprendre qu'il fallait que j'utilise une vieille version (pourtant c'est pas un saut de version majeur et j'ai pas trouvé de changement cassant). Et maintenant je sais pas s'il faut que je migre mes dépôt surtout que la prochaine version 2 annonce un changement de format…
[^] # Re: Comparaison
Posté par wilk . Évalué à 3 (+1/-0).
J'utilise Kopia depuis quelques années autant pour des sauvegardes sur le long terme que pour des sauvegardes sur la journée.
Je le lance toutes les demi-heures, ça prend 3s (pour 15Go de code, mails etc) ça me permet de rattraper des erreurs de manip et en même temps de vérifier régulièrement si la sauvegarde est bien effectuée.
Je ne vois pas trop la différence avec Borg que j'utilisais avant, c'est juste plus facile à installer, un binaire, et peut-être plus rapide.
Les fonctionnalités sont très nombreuses (UI et tout) mais je trouve ça plutôt dommage, j'aurai préféré quelque chose de plus simple pour être plus confiant.
[^] # Re: Comparaison
Posté par mahikeulbody . Évalué à 2 (+0/-0).
Il y a des erreurs assez grosses dans l'article, celle-là par exemple :
Users of Restic, Borg, and Kopia can configure their credentials with AWS for use of S3 backups as backup solutions.
A ma connaissance, Borg ne s'interface pas avec AWS S3.
[^] # Re: Comparaison
Posté par cosmocat . Évalué à 2 (+0/-0).
Plutôt d'accord même si ça se fait assez facilement avec rclone https://rclone.org/
[^] # Re: Comparaison
Posté par mahikeulbody . Évalué à 3 (+1/-0).
Certes mais le résultat n'est pas le même, il y a un single point of failure : la corruption du dépôt local borg entraîne la corruption de sa copie sur S3. La règle 3-2-1 suggère deux sauvegardes indépendantes.
Pour ma part, j'utilise borg pour avoir une sauvegarde locale et restic sur un bucket S3 (wasabi) pour avoir une sauvegarde distante. L'avantage est que outre l'application stricte de la règle 3-2-1, j'ajoute le fait d'utiliser deux logiciels différents. Les deux logiciels permettant un montage fuse, il est facile de faire un diff entre un snapshot local (borg) et un snapshot distant (restic) pour vérifier qu'ils sont identiques.
# et par rapport a rsync ?
Posté par Osourcier . Évalué à 5 (+4/-0). Dernière modification le 13 juillet 2024 à 02:00.
super projet mais rsync ne fait il pas la meme chose ? je vais creuser, si j'ai compris, fonctionnement a la git ?
[^] # Re: et par rapport a rsync ?
Posté par mahikeulbody . Évalué à 3 (+1/-0).
rsync utilisé seul n'est pas, à proprement parler, un outil de backup, c'est un outil de copie ; or la copie, ce n'est pas du backup (erreur très courante). Il peut bien sûr être une pièce maîtresse de certains logiciels de backup (backintime, par exemple) mais ces logiciels n'offrent pas la déduplication.
[^] # Re: et par rapport a rsync ?
Posté par cg . Évalué à 4 (+2/-0).
Sans que ce soit aussi sophistiqué qu'un logiciel dédié type Borg, on peut aller assez loin avec rsync en terme de sauvegardes, quand même.
--backupet--backup-dirpermettent d'historiser les versions.--hard-linkset--link-destpermettent de faire une déduplication au niveau fichier (pas au niveau bloc).De mémoire, c'est peu ou prou ce que fait backintime, comme tu dis ;).
Un défaut de rsync pour les sauvegardes, je trouve, est de devoir donner un accès ssh quand on fait une sauvegarde distante. Mais j'ai trouvé ce script : rrsync qui permet de limiter les possibilités d'accès distant.
[^] # Re: et par rapport a rsync ?
Posté par Pol' uX (site web personnel) . Évalué à 4 (+3/-1).
Perso j'ai utilisé dirvish pendant quelques années, qui offre un système de gestion de backup basé sur rsync. Mais ça dédup mal et je suis passé à Attic puis Borg depuis belle lurette.
Les options comme
--hard-linkssont un minimum syndical qui ne permettent pas par exemple de gagner de la dédup sur des fichiers copiés plusieurs fois à différents endroits de l'arborescence. (Du coup selon ce qu'on backup ça peut ne pas se révéler performant.)Adhérer à l'April, ça vous tente ?
[^] # Re: et par rapport a rsync ?
Posté par mahikeulbody . Évalué à 4 (+2/-0).
A noter que l'intérêt de la déduplication ne se limite pas gagner de la place en cas de fichiers copiés plusieurs fois à différents endroits de l'arborescence. Un gros plus pour moi (par rapport aux hard-links) est que si on change le nom des fichiers ou leur emplacement, ça n'augmente pas la taille du backup.
# Duplicity
Posté par chimrod (site web personnel) . Évalué à 3 (+1/-0).
Suis-je le seul à utiliser duplicity ? Pour moi, il a l’avantage de déporter le chiffrement des sauvegardes (en utilisant GPG), ce qui me permet d’envoyer les sauvegardes dans le cloud en confiance.
Je le vois rarement mentionné, est-ce parce que les autres outils proposent la même chose (j’avoue ne pas faire de veille sur le sujet — ça fonctionne pour moi) ou parce que l’outil n’est pas plus connu que ça ?
[^] # Re: Duplicity
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
LinuxFr.org l'utilise. Un des intérêts est de chiffrement la sauvegarde avec la clé GPG de chacun des admins, ce qui permet à n'importe quelle personne de l'équipe d'admin de restaurer sans avoir un secret partagé.
[^] # Re: Duplicity
Posté par lin4dd . Évalué à 2 (+3/-1). Dernière modification le 25 juillet 2024 à 07:55.
Bonjour à tous,
Non @chimrod et @Benoît Sibaud, vous n'êtes pas les seuls à utiliser Duplicati.
Ah ces fameuses sauvegardes que personne ne fait, sauf ceux qui ont déjà perdus des données !
Dans mon entreprise on utilise pour nos clients et nous même, Duplicati, depuis 4 ans.
Et cela après avoir fonctionné pendant des années avec des scripts "sur mesure".
On le couple avec le projet Duplicati Monitoring, et un système interne de surveillance.
L'outil est complet, multi-OS, gérant le cryptage, utilisable en application, en service, en graphique ou en lignes de commandes et surtout avec le support natif de la déduplication.
Pour l'utiliser souvent, la gestion des restaurations est vraiment bien faite (nos clients sont souvent maladroits).
Je vous laisse découvrir ces outils.
P.S. Merci à linuxFR.ORG et aux différents auteurs, pour les articles de qualité, la veille (libre ou pas) et un peu d'humour !
C'est un truc de ... MALADE !
[^] # Re: Duplicity
Posté par chimrod (site web personnel) . Évalué à 3 (+1/-0).
Je ne connais pas duplicati, mais cela semble être une autre application. Par contre, elle ne m’a pas l’air d’être empaquetée par défaut dans ma distribution (debian). Pour une gestion des sauvegardes (et la possibilité de faire des restauration en toute confiance), il s’agit d’un critère vraiment important pour moi.
[^] # Re: Duplicity
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Moi j'ai utilisé il y a quelques années…jusqu'à me rendre compte que des jobs ne démarraient pas sur le pc (windows 10) de ma compagne ce qui m'a fait douter de la fiabilité du truc.
# 3-2-1: Et la sauvegarde hors-site ?
Posté par Skilgannon . Évalué à 1 (+0/-0).
Avant de choisir l’outil avec lequel faire ses sauvegardes, il faut déjà savoir comment s’y prendre / quelle méthode utiliser.
Je suppose que tout le monde connaît la règle des 3-2-1.
3 copies des données dans 2 supports différents avec 1 copie hors-site.
Pour les copies sur 2 supports différents, c’est assez simple, vos données de production disposées par exemple sur un NAS, sur un disque dure externe.
Par contre comment faites-vous pour la copie hors-site ?
D’après ce que je peux lire, certaines personnes utilisent des disques dures dans des datacenters.
Ok, mais premièrement la dernière fois que j’avais regardé cela revenais assez chers dès que l’on avait plusieurs To à sauvegarder.
Deuxièmement comment envoyez-vous les données aux DC ? Vous laissez l’outil que vous utilisez s’en charger tout seul ? Ou mettez vous en place un VPN et l’outil sauvegarde à travers celui-ci ?
Mon interrogation vient de la situation suivante :
Site A ; un serveur proxmox avec VM-Yunohost-Nextcloud, la VM est sauvegardée chaque semaine par un serveur proxmox backup sur un disque externe mais toujours localisé dans le site A.
Site B ; Plusieurs partages NFS situés sur NAS sauvegardés la aussi toutes les semaines sur un disque dure externe localisé sur le site B (solution de sauvegarde intégrée au NAS, il me semble que c’est du rsync ou copie de snapshot-btrfs?).
Vous feriez comment pour la sauvegarde hors site ?
Copie de A vers B et B vers A via VPN + borg ou autre outils ?
Tout mettre dans Nextcloud en actif-actif ou actif passif sur les 2 sites ?
(Pas de problème pour l’espace disque, j’avais vu un peu trop gros lors de l’achat des disques dures pour le serveur du site A et le NAS du site B).
PS: le NAS est un vieux NAS Asustor.
[^] # Re: 3-2-1: Et la sauvegarde hors-site ?
Posté par cg . Évalué à 2 (+0/-0).
La sauvegarde croisée de deux sites est un classique pour se conserver ses données après un incendie/inondation/vol. En effet via un VPN s'il n'y a pas d'interconnexion directe.
Par contre, ça ne prémunit pas forcément d'une attaque type ransomware, qui va commencer par effacer/corrompre les sauvegardes, puis les données en ligne. Pour se protéger de ça, il y a diverses techniques, comme utiliser des trucs proprios (style Rubrik), des trucs proprio en cloud (type S3 avec Object Lock et mise en place de politiques de rétention "immuables" - mais pour le moment ni rclone, ni duplicati, ni restic ne sont vraiment compatibles avec l'Object Lock), ou à défaut, monter un réseau de sauvegarde dédié, avec annuaires/identifiants séparés et gestion très stricte des droits et des politiques de rétention. Une autre solution est d'avoir plusieurs jeux de sauvegarde, dont un toujours hors ligne, type bandes LTO, et faire une rotation.
Tout dépend de jusqu'où tu veux aller pour protéger tes sauvegardes :-/.
[^] # Re: 3-2-1: Et la sauvegarde hors-site ?
Posté par Skilgannon . Évalué à 1 (+0/-0).
Note j'évoque ici le cas d'une sauvegarde de données de type familiale; non professionnel donc.
Ce que je voudrais empêcher et la perte des donnes pour cause de vole certes, mais surtout de perte en cas d'incendie ou surtension dans l'un des deux sites. D'autant que les disques dures externes sont les deux cas branché à la machine qu'ils sont sensé sauvegarder. Pas terrible.
D'où l'idée de faire une troisième sauvegardes hors site. Le problème étant comment faire ?
Il y'a la possibilité des grands clouds publique + moyen de chiffrement. Mais si c'est pour payer d'un coups + un kg d'or par mois sans prévenir … Je suis moyen chaud.
Autre solution les offres de type 'Backup', 'Swiss Backup' d'Infomaniak en l'ocurence mais j'ai plusieurs To d'espace disque vide dans les deux sites, ça serait un peu d'image de pas les utiliser et de payer en plus en abonnement.
Reste donc la sauvegarde de A vers B et B vers A. Problèmes, on a des offres fibre grand publique. Dont un avec ipv4 non fixe. ( C'est facilement contourna le mais ça rajoute un point supplémentaires à surveiller).
Ce point régler, comment sauvegarder ? Via VPN j'imagine… Ou alors dernière idée que j'ai eu: utiliser les ipv6 qui elles sont sensé être fixe et n'autoriser que les deux IP des machines à dialoguer entre elles. Je sais pas si ça peut fonctionner à voir.
Pour en revenir à la corruption de données, j'imaginais, à tord? Que des solutions comme duplication ou autre permettaient de contourner le problème dans le sens où ce n'est que la différence qui est sauvegardée, donc seul la sauvegarde N serait touchée, pas la N-1. Faut il encore s'en apercevoir avant de supprimer cette N-1. Certes.
A contrario, je ne vois pas en quoi un stockage en mode bloque gène les attaque type ransomware
[^] # Re: 3-2-1: Et la sauvegarde hors-site ?
Posté par cg . Évalué à 2 (+0/-0).
Dans ton cas, la sauvegarde de A vers B et B vers A semble idéale.
Si tu as des IPv6 fixes, tu peux les utiliser, en effet. À défaut un truc du genre dyndns peut dépanner. Mais ça n'empêche pas de monter un VPN entre A et B, qui a l'avantage de chiffrer tout ce qu'il se passe.
Concernant les protections contre les ransomwares, ça fonctionne dans le cas du Object Lock dans un stockage S3, car si tu as mis une limite côté stockage du type "rétention de 2 semaines avant de pouvoir modifier/supprimer", alors un pirate qui souhaite chiffrer tes données ne le pourra pas, ce sera bloqué par l'interface S3. Cette page explique bien le principe, mais la fonction existe chez d'autres fournisseurs que Amazon (Backblaze, Infomaniak ou OVH, par exemple). Pour Rubrik c'est le même principe mais avec du matériel que tu héberges (pas familial du tout).
[^] # Re: 3-2-1: Et la sauvegarde hors-site ?
Posté par chimrod (site web personnel) . Évalué à 3 (+1/-0).
duplicity (cité un peu plus haut) permet de séparer le contenu des archives et des indexes ; et d’utiliser deux règles de destinations différentes pour l’un et l’autre. J’envoie donc les archives dans un glacier OVH (qui ne coûte pas grand chose tant qu’on ne les consulte pas) et les indexes dans un stockage type S3.
Je fais confiance à GPG pour conserver les données protégées.
J’ai un article en brouillon sur mon blog qui explique en détail la configuration mise en place.
[^] # Re: 3-2-1: Et la sauvegarde hors-site ?
Posté par Vlobulle . Évalué à 2 (+0/-0). Dernière modification le 02 août 2024 à 19:26.
J'ai un pote. On copie l'un chez l'autre.
# Jettez un oeil du côté de Vorta
Posté par yosch . Évalué à 3 (+3/-0).
Ne pas oublier Vorta.
Tous les Trekkies savent bien que les Vortas sont passés maîtres dans l'art du clonage génétique et peuvent facilement remettre en route une copie d'eux-mêmes.
# Code obfuscation
Posté par zyphos . Évalué à 2 (+2/-1).
Merci pour l'outil et l'article.
Le script tzsauv.bash a beau être OpenSource et j'ai quelques notions de Bash (quelques scripts à mon compte), mais là pour comprendre le code ou le maintenir, il faut être sacrément persévérant. On dirait du "code obfuscation" (utilisé surtout par les malwares).
Ceci est bien sûr une critique, qui se veut constructive, voir ci-dessous.
Je ne peux que recommander l'apprentissage de Python, qui est une pépite, en termes de facilité d'apprentissage, de beauté de code, d'efficacité, et de puissance de l'outil.(Certes ce n'est pas aussi rapide que du code compilé.)
Le développement du langage Python est très sérieux (sauf le passage de Python2 à Python3), via les PEP. (pas comme PHP qui part dans tous les sens, en utilisant des rustines sur des rustines, sans aucunes logiques ou réflexions, je programme en PHP depuis PHP3, soit plus de 20 ans sans discontinuer)
Python, c'est un peu le nouveau BASIC. (en beaucoup mieux, mais tout aussi facile)
Il vaut vraiment le coup, d'ailleurs beaucoup d'écoles l'enseignent maintenant (c'était le cas de Java à l'époque également, --troll inside--).
Perl est moins lisible.
En langage compilé, équivalent C/C++ (je pense à Badblocks 2), Rust est à la mode.
Il a une très grande communauté, et a une nouvelle approche de programmation. (moins facile à apprendre)
Il est très strict, a une gestion des scopes très restrictive, mais ces efforts sont récompensés, par normalement, aucune fuite de mémoire ou autre buffer overflow.
Il y a moyen de passer les sécurités interne (en utilisant unsafe), mais ce n'est pas conseillé évidement.
Les gros problèmes de Rust:
Plus difficile à apprendre
il n'y a aucune vérification des "Crates" (bibliothèques publiques), et cela point de vue sécurité, c'est un peu compliqué.
voir entre-autres:
https://internals.rust-lang.org/t/crates-io-is-at-risk-of-wormable-malware/18873
il faut le recompiler pour chaque plateforme, c'est compliqué de faire un binaire qui fonctionne partout et qui est léger (< 1MB).
# restauration et droits
Posté par gpe . Évalué à 3 (+1/-0).
Bonjour,
Comment ça se passe dans le cas d'une sauvegarde d'éléments systèmes, par exemple si je veux sauvegarder /etc ?
Pas mal de fichiers n'ont que les droits rwx pour l'utilisateur root.
Et lors d'une restauration il faut aussi avoir les droits root, non ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.