BD supprimée introuvable

Version imprimable

12/06/2024, 01h14
paco503

BD supprimée introuvable

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
12/06/2024, 14h42
escartefigue

Bonjour,
C'est dans le journal de transactions
12/06/2024, 17h30
Michel.Priori

Citation:

Envoyé par paco503

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 ?
12/06/2024, 17h38
Michel.Priori

Citation:

Envoyé par escartefigue

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
13/06/2024, 08h32
SQLpro

Citation:

Envoyé par escartefigue

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 +
13/06/2024, 10h35
Michel.Priori

Citation:

Envoyé par SQLpro

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 ?
13/06/2024, 14h26
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
13/06/2024, 17h47
Michel.Priori

Citation:

Envoyé par 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...

Merci Ced, tu m'as appris qqchose :merci:

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 :)
13/06/2024, 18h23
SQLpro

Citation:

Envoyé par Michel.Priori

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 +

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

Code:

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 +