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
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
