Non, pas que la vie m'est maintes fois prouvées leur utilité, mais le nombre de fois où mes mauvais choix m'ont mis en stress par absences de sauvegardes.
L'art de la sauvegarde doit être menée non par des scribes, mais au coin du feu en mangeant des chamallows grillés et en s'interrogeant sur nos valeurs.
- Sont-elles celles du sysadmins qui veut faire un truc chiadé et complexe sans couture ? (juste ça marche avec de la magie en dessous)
- Celles de l'utilisateur (que je suis aussi) qui veut qu'on change pas ses habitudes et que marche sans coutures (et sans magie)
- Le serial loser qui a donné dans les illusions du sysadmin et de l'utilisateur qui ne peut que constater les échecs répétés de ces deux stratégies
Il est temps de regarder les étoiles et de changer la manière dont on fait sa politique de sauvegarde en passant « battle tested » et « battle rejected ».
Actuellement, les documents numériques important que j'ai là, là, et que je veux sauvegarder sont de fait mais sauvegardes de pièces numériques ... Donc, j'ai en fait déjà un backup. J'ai peut être sérial losé, mais j'ai rattrapé de sources éparses en plein vols des sources et des copies de documents réels qui m'ont sauvé la vie.
Quelque part, je devrais souffler et me rappeler en regardant les étoiles et le ciel dégagé, que la foudre va pas me frapper de suite. Vu que j'ai aussi les pièces originales des copies que je sauvegarde.
Donc battle proven : AVOIR DES SAUVEGARDES C'EST BIEN, c'est même pour ça que je peux penser au sujet sans urgence.
En parlant de temps, et de serial loser, j'ai des vieux ordis que j'utilisais en serveur de sauvegarde, il est peut être temps de les rallumer pour voir ce qui traîne dessus...
Lol...
Content que les freeBSD soit conservatifs, car la procédure pour récupérer les mots de passes depuis le boot a pas changer. (noter ça dans bien et pas bien).
Une fois connecté, j'ai trouvé des photos non backupées que je voulais récupérer...
Sauf que le ssh était trop vieux.
J'ai voulu mettre à jour ssh, mais, les certificats SSL étaient tous expirés...
Bref, il me restait toujours le tournevis et une nappe pour disque 2.5"...
Mais j'ai réflêchi au lieu d'agir ... en me demandant ce que j'avais fait de bien et de négatifs dans tout ça, dans cette machine qui reboote...avec smartd annonnçant la fin, et encore un peu de temps pour récupérer les données uniques à cette machine ?
Déjà, j'ai eu raison à l'époque (2009) de prendre un mini pc comme serveur : ça m'a permis de l'emporter autour du monde, et de pouvoir toujours le réparer .... et d'imaginer lui donner une deuxième vie.
Ensuite, ce qu'il y a sur le serveur, c'était de la démo, et de la config de nom de domaine (auto-hébergé) ... ben ça, j'en ai plus besoin, et 60 photos dont 39 ratés, et 10 en doublons, ça peut s'oublier...
Bon, je vais les ramener, mais je m'en fous un peu, c'est pour ma femme qui aime faire des albums photos des lieux où l'on a vécu. Et on a pas beaucoup de photos de Montréal.
Bref, la sauvegarde c'est aussi une réflexion sur ce qui a de la valeur ou pas, et jusqu'à quels efforts on est prêt pour récupérer de la donnée.
Chaque complexité qu'on rajoute (OS, hardware, périphérique, taille) est un obstacle à récupérer les données.
C'est un travail d'orfèvre en ascétisme fonctionnel, le moins de parties « mouvantes » possibles, le plus de fonctionnalités possibles, mais on hésite pas à en sacrifier... (Ainsi que des données)...
Ce sera la job de ssh/sftp.
En plus c'est parfait freebsd propose déjà git-shell comme login restreint pour les comptes utilisateurs. Je peux aussi penser à migrer mon code quand je sens le krash boursier qui pourrait contraindre les comptes gits gratuits à disparaître sur l'autel de la réduction de coûts.
Sur ce coût, je vais être survivaliste git : je vais me r'auto-héberger. Ça fait qu'un seul protocole à sortir : ssh et en plus ça me permet de faire une stratégie de backup.
Qui a besoin de web en externe quand t'as un ssh en dmz ?
Tu as vraiment besoin du web ? Tu le ssh tunnelise depuis la DMZ et t'ouvres 0 ports.
Ben, c'est pratique un backup accessible de manière sécurisée depuis l'extérieur, non ?
Pour synchroniser une journée de code sur un projet sous git ...
Un serveur sécurisé, est un serveur surveillé, et la meilleure des surveillances c'est l'utilisation quotidienne, qui est l'alarme la plus précoce (après smart) de défaillance et besoin de maintenance.
Autrement dit, le paradoxe de la sauvegarde est de penser immédiatement un point unique de concentration des données. Un beau « Single Point Of Failure ». Mais en fait non, la situation change que l'on cause de photos (dont je me fous un peu) ou de code.
en code, quand je mets à jour mon git local, je fais une copie parfaite du dépôt distant. L'utilisateur local devient mon backup.
Malheureusement pour les assets statiques (photos, mails, documents) on a pas encore trouvé le graal du git qui sait se débrouiller avec la gestion des fichiers binaires.
Donc, bon, vu que j'ai résolu un choix de priorité, perso, je vais m'intéresser à donner une copie transparente aux archives.
Et ça tombe bien avec freeBSD j'ai openZFS, qui me permet de faire une redondance mirroir avec l'ajout d'un disque physique. Et comme ZFS est encore plus standard que lvm c'est mieux documenté. Lol.
Bref, je pourras penser à faire un backup distant plus tard à mondre coût avec rsync, et voilà. Il est temps d'arrêter de rêvasser et de terminer les tests d'utilisabilité de nautilus avec des dossiers montés à distance en sftp/scp pour que ma femme y mette ses photos.
No comments:
Post a Comment