[gull] Équivalent de Time Machine

Daniel Cordey dc at pxcluster.com
Fri Oct 2 15:32:05 CEST 2020



On 02.10.20 12:14, Laurent Franceschetti wrote:
> Syncthing est un très beau projet. C’est une alternative aux solutions 
> de type « Dropbox » (propriétaire) et « Owncloud » ("self-hosting").
> https://syncthing.net/

En fait j'utilise Seafile. Ce n'est pas une solution orientée backup, 
mais elle permet de sauvegarder mes fichiers de manière plus souple (à 
mon humble avis).

> A vrai dire ce n’est pas tout à fait une solution de backup. Mais il 
> peut certainement être inséré dans stratégie de DRP (Disaster Recovery 
> Planning), comme tu sembles le faire?

Oui. Pour moi, la notion de backup global est dépassée et n'a plus 
beaucoup de sens. Je préfère parler de sauvegarde régulière d'un projet 
sur lequel on est en train de travailler. De plus, les données que l'on 
manipule ont des "formes" différentes et nécessitent des stratégies de 
sauvegarde différentes. Un "backup" c'est bien, mais c'est souvent très 
bourrin et pas très subtile. Vu les masses de données actuelles, il me 
paraît plus judicieux d'adopter des stratégies de sauvegardes adaptées 
aux types de données. Ca sera aussi plus efficace en cas de Disaster 
Recovery. Quoique là encore j'ai adopté une nouvelle stratégie... plus 
de DR... mais la notion de non-stop & résilience (micro-services, 
kubernetes, Continuous Integration, etc.)

> Notamment, quel avantage y a-t-il, à ton avis, à mettre les données dans 
> des bases de données?

En cas de recherche... et permet d'archiver de manière plus 
intelligente. Souvent, on a des mélanges de type de données tel que :

address IPV4, IPV6
données numériques
dates de différents formats
texte en différentes langues
liste de données
Définition de procédeures
etc.

Stocker ses données dans une base (SQL ou non-SQL) offre mille fois plus 
de souplesse et de performance. En gros, comparer le stockage dans des 
fichiers avec une convention de nomage et utiliser grep ou des scripts 
évolués, par rapport à une DB, c'est comme comparer des tiroirs avec des 
fiches papier à un fichier Excel. Ca demande un peu plus d'effort de 
mettre les données dans le fichier, mais lorsque l'on a besoin des 
données on les retrouve plus vite.

Aussi, on sous-estime l'effet du temps sur les procédures de backup. 
Autrefois, les photos faisaient 1MB, aujourd'hui c'est entre 10 et 70 
fois plus. Ce qui fait que les backups enflent, les nombres de photos 
aussi, etc. Ce qui était valable il y a 15 ans n'a plus de sens 
aujourd'hui; il faut s'adapter. Les backup prennent plus de temps et les 
meta-données sont apparues. Mettre les meta-données dans le nom du 
fichier est une aberration totale. Ca rend les choses illisible et donc 
sujet à des erreurs. Une commande d’archivage de données plus vieilles 
qu'une certaine date est facile en SQL; par contre sujet à caution et 
source d'erreur si cette information est codée dans le nom du fichier 
(sans compter qu'avec le temps on a peut-être décidé de changer la 
convention pour nommer les fichier). Bien sûr, on peut tout faire avec 
find, tar, zip, sort, awk, etc. Mais ça reste du bricolage et pas très 
pro. Il faut toujours penser que notre travail doit pouvoir être repris 
par quelqu'un d'autre... dans 10 ou 15 ans.

Voilà pourquoi :-)

dc




More information about the gull mailing list