Journal Comment supprimer une base de données et sa sauvegarde du même coup quand on est un boulet

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
43
28
sept.
2025

Bonjour 'Nal,

Permets-moi de te raconter une histoire d'horreur. Il était une fois, moi, hier soir, qui voulais mettre à jour mon serveur Mastodon personnel (avec un unique compte, le mien), pour bénéficier enfin d'une certaine fonctionnalité.

Avant toute chose, je fais une sauvegarde de la base de données au cas où il y ait un pépin pendant la migration. Comme je ne compte pas la sauvegarder au-delà, erreur du débutant, je la place dans /tmp, que j'ai l'habitude d'utiliser pour placer mes fichiers temporaires. Tu vois venir le coup.

Je lis les notes de version. Je constate que la version minimum requise de plusieurs dépendances a augmenté. Je lance un sudo apt upgrade complet : après tout, le serveur a besoin d'une mise à jour générale. L'opération prend un bon quart d'heure pendant lequel je fais autre chose, et je ne pense plus à la sauvegarde.

L'attente passée, je constate que le noyau Linux est aussi mis à jour. Pour que la machine se mette à utiliser la nouvelle version du noyau, je redémarre.

Une fois la machine de nouveau en route, je vérifie que tous les services sont en état de marche. Je constate que Mastodon affiche une page d'erreur. Allons-bon, me dis-je, j'ai dû casser quelque chose avec cette mise à jour, il y a peut-être un module qui doit être recompilé ou un problème de ce genre. Je lis dans les logs que le serveur n'arrive pas à établir de connexion avec la base de données.

Légèrement inquiet, je fais machinalement ls /tmp/ pour vérifier que ma sauvegarde est bien là. Je commence à frissonner en réalisant que j'ai redémarré entre-temps, donc /tmp/ a été vidé. Soit, il n'y a plus de sauvegarde. Mais qu'est-il arrivé à la base de données elle-même ?

C'est en relisant mon historique de commandes avec Control R et dans ~/.bash_history que j'ai eu le fin mot de l'histoire. Pour sauvegarder la base de données, j'étais passé à l'utilisateur postgres afin de pouvoir exécuter pg_dump. Comme j'étais encore dans /root/, où postgres n'avait pas les droits d'accès, j'ai fait pwd, pensant atterrir dans /home/postgres/, mais je me suis rendu compte ensuite que j'étais en fait dans /var/lib/postgresql/. C'est à ce moment que j'ai voulu déplacer la sauvegarde. Le hic : par inadvertance, au lieu de déplacer /var/lib/postgresql/mastodon-backup.sql dans /tmp/, j'ai déplacé le dossier /var/lib/postgresql/ entier. La base de données était dedans.

C'est officiel : je suis un boulet.

  • # Welcome to club !

    Posté par  . Évalué à 10 (+15/-0).

    T'inquiètes, on a tous été, un moment ou un autre dans notre carrière, un boulet :)

    Bienvenue au club, buddy !

  • # humain != machine

    Posté par  . Évalué à 2 (+0/-0).

    La preuve en est encore une fois faite

    Je vous le dis, … on a encore de l'avenir.

    "Si tous les cons volaient, il ferait nuit" F. Dard

  • # Quel est la différence entre un bon admin et un mauvais admin ?

    Posté par  . Évalué à 10 (+16/-0).

    Le mauvais admin, il va faire une connerie, c'est sur…

    Le bon admin, il l'a déjà faite !

  • # Heureusement que tu as des sauvegardes quotidienne

    Posté par  . Évalué à 9 (+7/-0).

    En mettant celle de la veille, tu auras pas perdu beaucoup de données.

  • # murphy

    Posté par  . Évalué à 7 (+5/-0).

    Tu as joué de pas mal de malchance.

    Heureusement, tu avais la sauvegarde automatique de la veille bien au chaud dans un lieu sûr et tu as pu la restaurer. N'est-ce pas ?

  • # Et voilà l'erreur

    Posté par  . Évalué à 3 (+2/-1).

    Avant toute chose, je fais une sauvegarde de la base de données au cas où il y ait un
    pépin pendant la migration.

    les backups c'est à minima chaque jour. Pas quand tu fais une maj :)

  • # Il y a 2 catégories

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Voici ce que je dis aux petits jeunes :

    Il y a 2 catégories d'ingénieur système linux :

    1. ceux qui ont fait une connerie avec root
    2. ceux qui vont faire une connerie avec root

    vous pouvez méditer …

  • # Je fais comme toi mais de façon plus radicale.

    Posté par  . Évalué à 10 (+10/-0).

    Je mets toutes mes données importantes dans /tmp, je trouve que sur le long terme ça prend moins de place.

  • # 3-2-1

    Posté par  . Évalué à 3 (+2/-0).

    Merci d’avoir fait part de ta boulette. Ça fait une piqûre de rappel à tout le monde que les erreurs arrivent, et que des stratégies comme la sauvegarde 3-2-1 en protège.

  • # /var/tmp vs /tmp

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Si tu te demandes pourquoi il y a un /var/tmp avec les mêmes attributs que /tmp sur toutes les distros, tu as découvert la réponse de façon douloureuse … :)

    /var/tmp ne sera jamais dans un tmpfs (du moins ça ne sera pas la faute de la distro), et si tu montes un /var distinct ça tombera pas plus mal, tes dumps ou manipulation de data resteront dans le même filesystem (donc des "mv" cheaps, ou "cp -a", etc).

  • # Supériorité de sysv

    Posté par  . Évalué à 2 (+0/-0).

    Je vais parler un peu à l’emporte pièce car j’ai la flemme de vérifier : de mémoire, avec sysvinit sous Debian, le /tmp n’est pas effacé. C’est avec l’arrivée de systemd qu’on a « forcé » ce nettoyage. J’ai même un souvenir encore plus flou que le comportement aurait changé pour sysvinit récemment pour s’aligner sur systemd, mais peut-être que j’invente.
    Et pour corriger un commentaire ci-dessus, ça n’est pas parce que /tmp serait en tmpfs : c’est toujours (par défaut) sur la même partition que /.

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.