Vous n'êtes pas identifié(e).
Bonjour à tous !
Je suis nouveau sur cette communauté et Postgres en général donc j'aimerais avoir un peu d'aide sur quelque chose d'assez préoccupant de mon côté.
Hier, l'OS de mon serveur (vps) a crash. Mon opérateur propose un mode appelé "rescue mode" mais ce dernier propose uniquement un accès FTP aux fichiers du serveur.
J'ai donc pu télécharger les fichiers de ma db en brut sans pouvoir télécharger de sauvegarde (car le rescue mode est trop restreint) ce qui m'a obligé de télécharger le dossier /var/lib/postgresql/13/main directement.
Je tiens à préciser que c'est un serveur matrix (pour donner plus d'informations)
J'ai donc réinstallé mon OS (avec les mêmes spécificité que l'ancien. Debian 11, 64 bits, même nombre de GB en stockage et en RAM)
Tout s'installe correctement sauf que pour Postgres, quand j'upload ma db, il y avais un problème avec le checksum data (problème que j'ai réussi à régler avec la commande pg_resetwal)
mais le problème qui survient c'est qu'il n'y a plus aucun role. Même le rôle Postgres (créé par défaut) ne fonctionne plus et la commande psql indique que le role n'existe pas.
Est-ce que des manipulations ou des commandes existent afin de pouvoir réutiliser correctement la db ?
Merci d'avance pour vos réponses !
Hors ligne
Bonjour,
Le service postgres était-il démarré lors de l'accès FTP en "rescue mode" ? Si oui, la copie est inutile et la base est corrompue. Sinon, la copie aurait du fonctionner, pour peu que vous ayez bien sauvegardé toutes les données (répertoire pg_wal s'il était ailleurs, tablespaces ...).
l y avais un problème avec le checksum data (problème que j'ai réussi à régler avec la commande pg_resetwal)
Vous n'avez pas réglé le problème, vous avez définitivement corrompu les données. Si vous avez toujours la copie originale il est possible de voir quel était le problème et peut être le régler, sinon il n'y a pas grand chose à faire.
Il est également possible que soit postgres soit l'OS étaient mal configurés et ne garantissaient pas qu'un fsync écrivait bien les données sur disque de manière durable. Si c'est le cas, il est fort probable que le crash ait définitivement corrompu les données.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Le service postgres était-il démarré lors de l'accès FTP en "rescue mode" ? Si oui, la copie est inutile et la base est corrompue. Sinon, la copie aurait du fonctionner, pour peu que vous ayez bien sauvegardé toutes les données (répertoire pg_wal s'il était ailleurs, tablespaces ...).
l y avais un problème avec le checksum data (problème que j'ai réussi à régler avec la commande pg_resetwal)
Vous n'avez pas réglé le problème, vous avez définitivement corrompu les données. Si vous avez toujours la copie originale il est possible de voir quel était le problème et peut être le régler, sinon il n'y a pas grand chose à faire.
Il est également possible que soit postgres soit l'OS étaient mal configurés et ne garantissaient pas qu'un fsync écrivait bien les données sur disque de manière durable. Si c'est le cas, il est fort probable que le crash ait définitivement corrompu les données.
Bonjour !
Tout d'abord, pour répondre au ftp, non. Le "rescue mode" est une fonctionnalité permettant d'accéder aux fichiers de la machine sans que cette dernière soit allumé. C'est vraiment à utiliser en cas de dernière nécessité, comme je l'ai fait.
Aussi, concernant pg_resetwall j'ai vue les conséquences de cette commande mais j'ai quand même pris soin de garder une backup avant toute modification.
Je reste donc ouvert à toute information sur cette dernière.
Hors ligne
Il nous faut plus de détail que "il y avais un problème avec le checksum data" pour pouvoir vous aider. Pouvez-vous préciser la version de postgres (version 13 j'imagine, mais quelle version mineure ?), la liste des répertoires utilisés par postgres (répertoire data, répertoire pg_wal, tablespace etc) que vous avez récupérés, la commande utilisée pour démarrer postgres ainsi que toutes les erreurs apparaissant dans la logs. Si vous avez également des précisions sur le système disque associé à votre serveur vps, notamment si vous avez la garantie qu'un fsync est bien durable et résiste à un crash de l'OS.
De plus, avec le packaging debian la majorité des fichiers de configuration se trouver dans /etc et non /var, avez-vous également récupérés ceux-ci?
Julien.
https://rjuju.github.io/
Hors ligne
Pouvez-vous préciser la version de postgres (version 13 j'imagine, mais quelle version mineure ?)
La version que j'utilise jusqu'à présent c'est la version 13.11.
Concernant la liste de répertoires utilisés par postgres, j'ai réussi à récupérer uniquement le /var/lib/postgresql. Pour des raisons que je ne connais pas encore, le rescue mode n'avais pas la permission de télécharger tous les dossiers de configuration sur le /etc (ce que j'ai clairement indiqué à mon opérateur).
En ce qui concerne le système disque, je n'ai aucune précision par rapport au fsync.
(je vais envoyer les fichiers logs plus tard dans la journée car je suis pas chez moi)
Hors ligne
bonsoir !
Bon, j'ai pris du temps à revenir avec mes logs, mais voici les logs après avoir remis la backup :
2023-08-15 19:53:25.461 UTC [4143969] FATAL: incorrect checksum in control file
2023-08-15 19:53:25.461 UTC [4143969] LOG: database system is shut down
pg_ctl: could not start server
Examine the log output.
Hors ligne
Ce message indique une corruption dans le fichier global/pg_control, fichier qui contient des informations critiques sur l'instance et notamment à partir d'où rejouer les données en cas d'arrêt brutal.
Si ce fichier est corrompu il n'est pas possible de démarrer l'instance sans perdre ou corrompre des données. Mais plus grave que ça, ce fichier est tellement critique qu'il contient moins de 512 octets, c'est-à-dire suffisament petit pour tenir sur un bloc physique d'un disque et donc garantir des écritures atomiques. Si ce fichier est corrompu, il est à peu près sûr qu'il y a eu un gros problème sur les disques et que le reste des données a également souffert, et qu'il n'y a pas grand chose à récupérer. Votre meilleur espoir est de repartir depuis votre sauvegarde la plus récente.
Julien.
https://rjuju.github.io/
Hors ligne
