Discussion :

[paco503]

Bonjour,

à la date du 07/06/2024 j'ai eu une surprise sur une base de donnée postgres en production, toutes les tables étaient supprimées

heureusement, on avais une sauvegarde de J-1

j'aimerais de l'aide pour voir quel user ou IP a effectuer ces suppressions

Merci

[escartefigue]

Bonjour,
C'est dans le journal de transactions

[Michel.Priori]

C'est dans le journal de transactions

Que les transactions soient dans le journal = pas de doute.
Par contre :
* Est-ce que dans le journal on a le compte à l'origine de la transaction ?
* Comment "remonter" le journal pour lire en clair les opérations ?
* Vu que
**-- le demandeur précise qu'il a une sauvegarde de la veille, je crains qu'il ne soit pas en archivage continu.
**-- la restauration a eu lieu, comment lire les WAL à froid (si les fichiers ont été récupérés avant restauration !)

note : PITR = https://docs.postgresql.fr/10/continuous-archiving.html

[SQLpro]

Bonjour,
C'est dans le journal de transactions

Pas forcément, car la suppression a pu être physique : suppression du répertoire.... ou des fichiers. PostgerSQL ne protégeant pas les fichiers, même quand il est en marche, contrairement à SQL Server ou Oracle sous Windows....

A +

[Michel.Priori]

Pas forcément, car la suppression a pu être physique : suppression du répertoire.... ou des fichiers.

Bonjour Frédérick, soit je vais apprendre un truc, soit tu te mélanges les pinceaux.
La description du problème est : "sur une base de donnée postgres en production, toutes les tables étaient supprimées"
Question : quels sont les fichiers à supprimer pour obtenir strictement ce résultat : "1 base de donnée, toutes les tables" ?

Ne confondrais tu pas avec MySQL ?

[ced]

Dans le répertoire $PGDATA (celui qui stocke les données de l'instance PostgreSQL tel que spécifié dans le fichier de configuration), il y a un répertoire nommé "base" qui contient un sous-répertoire par base de données sur l'instance (dont le nom est l'OID de la base de données).
Et dans ces répertoires, on trouve les fichiers contenant les données des tables (plus d'autres fichiers nécessaires au fonctionnement du moteur MVCC). Si on supprime ces fichiers physiquement, on supprime les tables...

ced

[Michel.Priori]

Dans le répertoire $PGDATA (celui qui stocke les données de l'instance PostgreSQL tel que spécifié dans le fichier de configuration), il y a un répertoire nommé "base" qui contient un sous-répertoire par base de données sur l'instance (dont le nom est l'OID de la base de données).
Et dans ces répertoires, on trouve les fichiers contenant les données des tables (plus d'autres fichiers nécessaires au fonctionnement du moteur MVCC). Si on supprime ces fichiers physiquement, on supprime les tables...

Merci Ced, tu m'as appris qqchose

Ceci étant dit, pour répondre à la demande, on devrait trouver dans les fichiers de log (alert) des erreurs d'entrée-sortie, ce qui permet de préciser la date-heure de la manip. Correct ?
et en remontant au Sudoer trouver qui était connecté à ce moment.

Autre hypothèse, TERRAFORM.
De manière assez stupide ce module "descend" jusqu'à la base ; supprimant les bases surnuméraires et recréant les bases à vide les bases supprimées, au lieu de s'arrêter à la conf.

Ce serait bien que Paco503 nous donne plus de retours

[SQLpro]

Bonjour Frédérick, soit je vais apprendre un truc, soit tu te mélanges les pinceaux.
La description du problème est : "sur une base de donnée postgres en production, toutes les tables étaient supprimées"
Question : quels sont les fichiers à supprimer pour obtenir strictement ce résultat : "1 base de donnée, toutes les tables" ?

Ne confondrais tu pas avec MySQL ?

pas du tout.....
Contrauirement à Oracle, DB2 ou MS SQL Server qui gèrent directement le stockage de leurs bases de données, PostGreSQL ne fait que déléguer cela à l'OS. Il utilise donc la notion de répertoire comme lieu et place d'une base et y place de nombreux fichiers, au moins 1 (mais très souvent beaucoup plus) par table + les index.
Ces fichiers étant désolidarisé de PostgreSQL il est alors très facile de les supprimer par un simple commande OS...
Ce qui a pu t'arriver !
Commence par voir si les tables systèmes de ta base "voient" lesdites tables utilisateur. Si ces requêtes te présentent les tables, mais que tu n'as plus les fichiers c'est que quelqu'un les a supprimé.

A +

[SQLpro]

Utilise la requête suivante pour "voir" ou sont stockées les tables de tes bases :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT *, 
       CASE WHEN 
            pg_catalog.pg_tablespace_location(oid)
               = '' AND spcname = 'pg_default' 
              THEN (SELECT setting 
                    FROM   pg_catalog.pg_settings 
                    WHERE  name = 'data_directory')
                || '/base'
            WHEN
            pg_catalog.pg_tablespace_location(oid)
                = '' AND spcname = 'pg_global' 
              THEN (SELECT setting 
                    FROM   pg_catalog.pg_settings 
                    WHERE  name = 'data_directory') 
                || '/global' 
            ELSE 
             pg_catalog.pg_tablespace_location(oid)
       END AS directory_location
FROM   pg_catalog.pg_tablespace

A +

[Michel.Priori]

j'ai eu une surprise sur une base de donnée postgres en production, toutes les tables étaient supprimées

Quelques questions :
1- Est-ce qu'il y a plusieurs bases "utilisateurs" dans cette instance, ou est-ce la seule ?
2- Est-ce que toutes les tables étaient dans le schéma public ?
3- Quels sont les comptes qui ont les GRANT nécessaires pour pouvoir faire ça ?