1. Vue d’ensemble — DBA classique, mais niveau production
Préparer une fiche de poste DBA orientée exploitation traditionnelle ou virtualisée : instances installées sur VM ou serveurs physiques, haute disponibilité, réplication, pool de connexions, sauvegarde, restauration, PRA/PCA et supervision opérationnelle.
Cette thématique correspond au DBA de production historique : le moteur est installé sur un serveur Linux, une VM, un cluster on-prem, ou une infrastructure virtualisée. Le DBA n’est pas seulement responsable du SQL. Il doit garantir la disponibilité, la cohérence, la sauvegarde, la restauration, la sécurité, les performances et la capacité à redémarrer après incident.
Ce que l’entreprise attend réellement
| Domaine | Ce qu’il faut savoir faire | Ce qu’il faut démontrer en entretien |
|---|---|---|
| Exploitation | Démarrage/arrêt, patching, suivi des logs, gestion espace disque, connexions, locks, incidents. | Tu sais diagnostiquer vite, sans paniquer, avec une méthode claire. |
| Haute disponibilité | Replica, standby, cluster manager, failover, switchover, split brain, VIP/proxy. | Tu sais que la HA n’existe que si elle a été testée. |
| Sauvegarde | Backup full, incrémental, WAL/binlog/archivelog, catalogue, rétention, chiffrement. | Tu sais choisir entre dump logique, backup physique et restauration point-in-time. |
| Restauration | Restore complet, restore partiel, PITR, test régulier, preuve de restauration. | Tu répètes : un backup non restauré n’est pas un backup validé. |
| PRA/PCA | RPO/RTO, site secours, bascule, retour arrière, procédures de crise. | Tu distingues continuité de service, reprise d’activité et simple sauvegarde. |
Les 16 blocs du guide
- Vue d’ensemble et posture DBA production.
- Infrastructure traditionnelle ou virtualisée.
- PostgreSQL standalone.
- Streaming replication PostgreSQL.
- Patroni pour haute disponibilité PostgreSQL.
- pgBouncer pour pooling de connexions.
- Oracle Database administration courante.
- Oracle RMAN backup/recovery.
- Oracle Data Guard.
- MySQL/MariaDB administration courante.
- Réplication asynchrone et semi-synchrone.
- MariaDB Galera Cluster.
- Stratégie de sauvegarde.
- Tests de restauration.
- PRA/PCA, RPO/RTO, runbooks.
- Check-list entretien et infrastructure de lab.
2. Infrastructure traditionnelle ou virtualisée
Les bases classiques tournent généralement sur des VM Linux ou serveurs physiques. Le DBA doit connaître l’OS, le stockage, le réseau, les fenêtres de maintenance, les sauvegardes système, les limites CPU/RAM et les mécanismes de fencing ou de bascule.
Architecture de lab recommandée
| Composant | Minimum lab | Version crédible entretien | Objectif |
|---|---|---|---|
| VM PostgreSQL | 2 VM | 3 VM + 1 proxy | Primary, standby, Patroni, HAProxy, pgBouncer. |
| VM Oracle | 1 VM XE ou Free | 2 VM pour Data Guard lab | Administration, RMAN, archivelog, standby. |
| VM MySQL/MariaDB | 2 VM | 3 VM + proxy | Réplication, GTID, semi-sync, Galera. |
| Backup server | 1 répertoire NFS | Serveur dédié + stockage objet | Rétention, restore, séparation des responsabilités. |
| Monitoring | Scripts + logs | Prometheus/Grafana ou Zabbix | Alerting CPU, RAM, disque, lag, backup failed. |
Arborescence serveur recommandée
/srv/db-platform/
postgres/
data/
wal_archive/
backup/
scripts/
logs/
oracle/
backup/
archivelog/
scripts/
logs/
mysql/
data/
binlog_archive/
backup/
scripts/
logs/
runbooks/
monitoring/
inventory/Points d’infrastructure à vérifier
Type disque, latence, IOPS, cache, RAID, LVM, snapshots, extension volume, rétention.
Latence entre nœuds, DNS, VIP, load balancer, firewall, MTU, routage site secours.
Kernel, huge pages Oracle, limites fichiers, systemd, journald, NTP/chrony, timezone.
Comptes OS, sudo, SSH, chiffrement, certificats, rotation mots de passe, audit.
Alertes disque, lag réplication, durée backup, locks, sessions, mémoire, erreurs logs.
Procédures bascule, restore, montée de version, incident disque, incident réplication.
3. PostgreSQL standalone — socle d’administration
PostgreSQL standalone désigne une instance principale isolée, généralement installée sur une VM. Avant de parler Patroni ou réplication, il faut maîtriser le socle : configuration, journaux WAL, connexions, sécurité, sauvegarde, vacuum et diagnostic.
Paramètres essentiels
| Paramètre | Rôle | Point de vigilance |
|---|---|---|
shared_buffers | Cache mémoire PostgreSQL. | Souvent 25 % RAM serveur comme point de départ, à ajuster par mesure. |
work_mem | Mémoire par opération de tri/hash. | Attention multiplication par nombre de sessions/opérations. |
max_connections | Nombre maximal de connexions. | Trop haut = mémoire gaspillée ; préférer pgBouncer. |
wal_level | Niveau de journalisation WAL. | Nécessaire pour réplication et PITR. |
archive_mode | Active l’archivage WAL. | Obligatoire pour PITR sérieux. |
autovacuum | Maintenance MVCC. | Un autovacuum mal réglé crée bloat et lenteurs. |
Exemple de configuration de base
listen_addresses = '*'
port = 5432
max_connections = 200
shared_buffers = '4GB'
effective_cache_size = '12GB'
work_mem = '16MB'
maintenance_work_mem = '1GB'
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /srv/db-platform/postgres/wal_archive/%f && cp %p /srv/db-platform/postgres/wal_archive/%f'
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
log_min_duration_statement = 1000
log_checkpoints = on
log_connections = on
log_disconnections = onContrôles quotidiens DBA
SELECT datname, numbackends, xact_commit, xact_rollback
FROM pg_stat_database
ORDER BY numbackends DESC;
SELECT pid, usename, state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;
SELECT schemaname, relname, n_dead_tup, last_autovacuum, last_vacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;4. PostgreSQL streaming replication
La streaming replication PostgreSQL consiste à envoyer les WAL du primary vers un ou plusieurs standby. Le standby peut servir de secours, de lecture read-only, ou de base pour un PRA. PostgreSQL distingue bien le serveur primary, qui envoie les WAL, et le standby, qui les reçoit.
Préparation du primary
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'change-me';
SELECT pg_create_physical_replication_slot('standby_01');
SELECT pg_create_physical_replication_slot('standby_02');host replication replicator 10.10.20.11/32 scram-sha-256
host replication replicator 10.10.20.12/32 scram-sha-256Création d’un standby avec pg_basebackup
systemctl stop postgresql
rm -rf /var/lib/postgresql/18/main/*
pg_basebackup \
--host=10.10.20.10 \
--port=5432 \
--username=replicator \
--pgdata=/var/lib/postgresql/18/main \
--format=plain \
--write-recovery-conf \
--slot=standby_01 \
--checkpoint=fast \
--progress
systemctl start postgresqlCommandes de diagnostic
| Sur primary | Sur standby | Interprétation |
|---|---|---|
SELECT * FROM pg_stat_replication; | SELECT pg_is_in_recovery(); | Le primary voit ses standby ; le standby confirme son mode recovery. |
SELECT * FROM pg_replication_slots; | SELECT now() - pg_last_xact_replay_timestamp(); | Contrôle slots, rétention WAL et lag de rejeu. |
SELECT pg_current_wal_lsn(); | SELECT pg_last_wal_replay_lsn(); | Compare la position WAL primary/standby. |
5. Patroni — haute disponibilité PostgreSQL
Patroni automatise la haute disponibilité PostgreSQL. Il s’appuie sur un Distributed Configuration Store comme etcd, Consul, ZooKeeper ou Kubernetes pour décider quel nœud est leader et orchestrer failover/switchover.
Composants à préparer
| Composant | Rôle | Point de vigilance |
|---|---|---|
| Patroni | Contrôle PostgreSQL, leader election, failover, switchover. | Ne pas modifier PostgreSQL directement sans comprendre Patroni. |
| etcd / Consul | Consensus, état du cluster, verrou leader. | Quorum obligatoire ; éviter un seul nœud en production. |
| HAProxy | Route écritures vers leader et lectures vers replicas. | Health checks Patroni REST API. |
| Watchdog | Protection contre split brain. | Très important sur infrastructure critique. |
Exemple patroni.yml simplifié
scope: pg-prod
name: pg-node-01
restapi:
listen: 0.0.0.0:8008
connect_address: 10.10.20.10:8008
etcd3:
hosts: 10.10.30.10:2379,10.10.30.11:2379,10.10.30.12:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
use_slots: true
parameters:
wal_level: replica
hot_standby: 'on'
max_wal_senders: 10
max_replication_slots: 10
initdb:
- encoding: UTF8
- data-checksums
postgresql:
listen: 0.0.0.0:5432
connect_address: 10.10.20.10:5432
data_dir: /var/lib/postgresql/18/main
bin_dir: /usr/lib/postgresql/18/bin
authentication:
superuser:
username: postgres
password: change-me
replication:
username: replicator
password: change-meHAProxy devant Patroni
listen postgres_write
bind *:5432
option httpchk GET /primary
http-check expect status 200
default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
server pg-node-01 10.10.20.10:5432 check port 8008
server pg-node-02 10.10.20.11:5432 check port 8008
server pg-node-03 10.10.20.12:5432 check port 8008
listen postgres_read
bind *:5433
option httpchk GET /replica
http-check expect status 200
server pg-node-01 10.10.20.10:5432 check port 8008
server pg-node-02 10.10.20.11:5432 check port 8008
server pg-node-03 10.10.20.12:5432 check port 80086. pgBouncer — pooling de connexions PostgreSQL
PostgreSQL gère mal les très grands nombres de connexions directes. pgBouncer agit comme un pooler léger entre l’application et PostgreSQL. Il réduit le coût d’ouverture des connexions et protège le serveur contre les pics applicatifs.
Modes de pooling
| Mode | Principe | Usage | Risque |
|---|---|---|---|
session | Une connexion serveur reste liée à la session client. | Compatibilité maximale. | Moins efficace. |
transaction | La connexion serveur est rendue au pool à la fin de chaque transaction. | Mode le plus courant pour web apps. | Attention aux sessions stateful, prepared statements, temp tables. |
statement | Libération après chaque statement. | Cas très spécifiques. | Transactions multi-statements interdites. |
Exemple pgbouncer.ini
[databases]
appdb = host=10.10.20.100 port=5432 dbname=appdb
[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 50
min_pool_size = 10
reserve_pool_size = 20
server_idle_timeout = 600
server_lifetime = 3600
ignore_startup_parameters = extra_float_digits
admin_users = postgres, dba_admin
stats_users = dba_readonlyCommandes utiles
SHOW POOLS;
SHOW CLIENTS;
SHOW SERVERS;
SHOW STATS;
SHOW CONFIG;
PAUSE appdb;
RESUME appdb;
RELOAD;7. Oracle Database — administration courante
Oracle Database demande une discipline particulière : instance, listener, spfile/pfile, control files, datafiles, redo logs, archivelog, tablespaces, users, rôles, jobs, AWR/ASH et patching. Le DBA doit savoir opérer l’instance et lire les symptômes.
Objets et composants fondamentaux
| Composant | Rôle | Surveillance |
|---|---|---|
| Instance | SGA + processus background. | Alert log, mémoire, sessions, wait events. |
| Database | Fichiers physiques : datafiles, redo logs, control files. | État fichiers, checkpoints, corruption, espace. |
| Listener | Entrée réseau des clients. | Port, services, logs, firewall. |
| Tablespace | Conteneur logique des segments. | Autoextend, free space, fragmentation. |
| Redo / Archive logs | Journalisation transactionnelle. | Switch rate, destination pleine, archiver stuck. |
Commandes Oracle courantes
SELECT instance_name, status, database_status
FROM v$instance;
SELECT name, open_mode, database_role, log_mode
FROM v$database;
SELECT tablespace_name, ROUND(used_percent, 2) AS used_percent
FROM dba_tablespace_usage_metrics
ORDER BY used_percent DESC;
SELECT dest_id, status, destination, error
FROM v$archive_dest_status
ORDER BY dest_id;
SELECT username, status, lock_date, expiry_date
FROM dba_users
ORDER BY username;Opérations DBA classiques
Tablespaces, datafiles, autoextend, segments volumineux, purge, archivelogs.
Users, profiles, roles, grants, audit, comptes verrouillés, rotation passwords.
AWR, ASH, wait events, plans SQL, stats optimizer, index, sessions bloquantes.
Patching, sauvegarde, contrôle corruption, jobs, alert log, listener.
Data Guard, RAC éventuel, services, switchover, failover, redémarrage propre.
Inventaire, versions, paramètres, schémas critiques, RPO/RTO, dépendances.
8. Oracle RMAN — backup et recovery
RMAN est l’outil Oracle de référence pour les sauvegardes et restaurations physiques. Il sait gérer les datafiles, control files, archivelogs, catalogues, incrémentaux, validation et recovery. Le DBA doit savoir créer une stratégie, pas seulement lancer une commande.
Stratégie RMAN standard
| Élément | Décision DBA | Contrôle attendu |
|---|---|---|
| Mode archivelog | Obligatoire pour recovery point-in-time sérieux. | SELECT log_mode FROM v$database; |
| Backup full | Hebdomadaire ou selon volumétrie. | Durée, taille, validation. |
| Backup incrémental | Quotidien ou plus fréquent. | Recoverability et fenêtre RTO. |
| Archivelogs | Sauvegarder et purger selon politique. | Destination jamais pleine. |
| Control file autobackup | À activer systématiquement. | Restore possible même en perte sévère. |
Configuration RMAN
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;Script RMAN backup quotidien
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/oracle/%d_%T_%U.bkp';
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup/oracle/%d_%T_%U.bkp';
BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 DATABASE TAG 'DAILY_LEVEL_1';
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG 'ARCHIVELOG_BACKUP';
BACKUP CURRENT CONTROLFILE TAG 'CONTROLFILE_BACKUP';
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}
CROSSCHECK BACKUP;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT OBSOLETE;Validation RMAN
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;
VALIDATE CHECK LOGICAL DATABASE;9. Oracle Data Guard — standby, switchover, failover
Data Guard maintient une ou plusieurs bases standby à partir d’une base primary. Le but est la haute disponibilité, la reprise après sinistre et parfois le reporting read-only avec Active Data Guard.
Concepts à maîtriser
| Concept | Rôle | Question d’entretien |
|---|---|---|
| Physical standby | Copie bloc à bloc transactionnellement cohérente. | Comment vérifier le apply lag ? |
| Redo transport | Envoi des redo logs vers standby. | Différence sync/async ? |
| Redo apply | Application des redo sur standby. | Que faire si le apply est bloqué ? |
| Switchover | Bascule contrôlée, sans perte, planifiée. | Quand l’utiliser ? |
| Failover | Bascule d’urgence après perte primary. | Quelle conséquence sur l’ancien primary ? |
Contrôles Data Guard
SELECT name, database_role, open_mode, protection_mode, protection_level
FROM v$database;
SELECT dest_id, status, error, recovery_mode, destination
FROM v$archive_dest_status
ORDER BY dest_id;
SELECT name, value, unit, time_computed
FROM v$dataguard_stats
ORDER BY name;
SELECT process, status, thread#, sequence#, block#, blocks
FROM v$managed_standby
ORDER BY process;Switchover contrôlé avec Data Guard Broker
DGMGRL> CONNECT sys@primary_db
DGMGRL> SHOW CONFIGURATION;
DGMGRL> VALIDATE DATABASE primary_db;
DGMGRL> VALIDATE DATABASE standby_db;
DGMGRL> SWITCHOVER TO standby_db;
DGMGRL> SHOW CONFIGURATION;10. MySQL / MariaDB — administration courante
MySQL et MariaDB restent très présents en environnement traditionnel. Le DBA doit connaître InnoDB, binlogs, users, réplication, sauvegarde physique/logique, slow query log, buffer pool et opérations de maintenance.
Paramètres importants
| Paramètre | Rôle | Vigilance |
|---|---|---|
innodb_buffer_pool_size | Cache principal InnoDB. | Souvent la clé de performance sur serveur dédié. |
binlog_format | Format des événements binlog. | ROW recommandé pour réplication robuste. |
server_id | Identifiant unique réplication. | Chaque serveur doit avoir un ID distinct. |
gtid_mode | Gestion des transactions globales. | Facilite failover et resynchronisation. |
slow_query_log | Détection requêtes lentes. | Base du tuning SQL. |
Exemple MySQL my.cnf
[mysqld]
server_id = 101
bind-address = 0.0.0.0
port = 3306
innodb_buffer_pool_size = 8G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_replica_updates = ON
slow_query_log = ON
long_query_time = 1
log_error = /var/log/mysql/error.logContrôles quotidiens
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW BINARY LOGS;
SHOW PROCESSLIST;
SELECT user, host, plugin, account_locked FROM mysql.user ORDER BY user, host;11. MySQL / MariaDB — réplication asynchrone et semi-synchrone
La réplication MySQL classique repose sur le binlog du source et le relay log des replicas. Par défaut elle est asynchrone : le source peut valider une transaction sans garantie qu’un replica l’ait reçue. La semi-synchrone ajoute une attente d’acquittement.
Comparaison réplication
| Mode | Avantage | Risque | Cas d’usage |
|---|---|---|---|
| Asynchrone | Simple, rapide, peu bloquant. | Transactions perdues possibles si source crash avant envoi. | Read replicas, reporting, PRA avec RPO non nul. |
| Semi-synchrone | Réduit le risque de perte. | Latence commit plus élevée, dépend des replicas. | Production critique avec besoin de meilleure durabilité. |
| GTID | Failover et repositionnement facilités. | Demande discipline de configuration. | Clusters modernes et procédures de bascule. |
Création d’un utilisateur de réplication
CREATE USER 'repl'@'10.10.40.%' IDENTIFIED BY 'change-me';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.10.40.%';
FLUSH PRIVILEGES;Configuration replica avec GTID
CHANGE REPLICATION SOURCE TO
SOURCE_HOST = '10.10.40.10',
SOURCE_PORT = 3306,
SOURCE_USER = 'repl',
SOURCE_PASSWORD = 'change-me',
SOURCE_AUTO_POSITION = 1;
START REPLICA;
SHOW REPLICA STATUS\GSemi-synchrone MySQL
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
SET GLOBAL rpl_semi_sync_replica_enabled = 1;
SET GLOBAL rpl_semi_sync_source_timeout = 10000;
SHOW VARIABLES LIKE 'rpl_semi_sync%';
SHOW STATUS LIKE 'Rpl_semi_sync%';12. MariaDB Galera Cluster
Galera fournit une réplication virtuellement synchrone et multi-primary. C’est une solution de haute disponibilité puissante, mais elle exige de bien comprendre quorum, certification, latence réseau, SST/IST et split brain.
Concepts clés Galera
| Concept | Définition | Vigilance |
|---|---|---|
| Quorum | Majorité nécessaire pour rester Primary Component. | Préférer nombre impair de nœuds. |
| SST | State Snapshot Transfer, resynchronisation complète. | Coûteux, peut impacter production. |
| IST | Incremental State Transfer, rattrapage incrémental. | Dépend de la taille du gcache. |
| Certification | Validation des transactions concurrentes. | Conflits possibles en multi-writer. |
| Flow control | Ralentissement global si un nœud ne suit pas. | Latence réseau et nœud lent critiques. |
Exemple galera.cnf
[mysqld]
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
bind-address = 0.0.0.0
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = prod_galera
wsrep_cluster_address = gcomm://10.10.50.10,10.10.50.11,10.10.50.12
wsrep_node_address = 10.10.50.10
wsrep_node_name = galera-node-01
wsrep_sst_method = mariabackup
wsrep_sst_auth = sst_user:change-meContrôles Galera
SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_ready';
SHOW STATUS LIKE 'wsrep_connected';
SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_flow_control_paused';13. Stratégie de sauvegarde
Une stratégie de sauvegarde sérieuse combine fréquence, type de backup, journalisation transactionnelle, stockage externe, rétention, chiffrement, immutabilité éventuelle et tests de restauration. Elle doit être liée aux RPO/RTO métiers.
Types de sauvegarde par moteur
| Moteur | Backup logique | Backup physique | Journal transactionnel | Outils |
|---|---|---|---|---|
| PostgreSQL | pg_dump, pg_dumpall | pg_basebackup, pgBackRest, Barman | WAL archive | pgBackRest, Barman, WAL-G. |
| Oracle | Data Pump | RMAN | Archived redo logs | RMAN, catalog, Data Guard. |
| MySQL | mysqldump, MySQL Shell dump | Enterprise Backup, Percona XtraBackup | Binary logs | xtrabackup, mysqlbinlog. |
| MariaDB | mariadb-dump | mariabackup | Binary logs / Galera state | mariabackup, MaxScale tools. |
Planning type
| Fréquence | Action | Objectif | Validation |
|---|---|---|---|
| Toutes les 5-15 min | Archivage WAL/binlog/archivelog. | Réduire le RPO. | Contrôle retard et destination. |
| Quotidien | Backup incrémental ou différentiel. | Restauration rapide. | Logs backup + checksum. |
| Hebdomadaire | Backup complet. | Base de récupération. | Restore test en environnement isolé. |
| Mensuel | Backup longue rétention. | Conformité / audit. | Inventaire et preuve d’intégrité. |
Exemple PostgreSQL avec pg_basebackup
backup_dir="/backup/postgres/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$backup_dir"
pg_basebackup \
--host=127.0.0.1 \
--port=5432 \
--username=backup_user \
--pgdata="$backup_dir" \
--format=tar \
--gzip \
--checkpoint=fast \
--wal-method=stream \
--progress14. Tester les restaurations
Tester une restauration est l’acte le plus important du DBA. Une entreprise ne paie pas seulement pour des backups ; elle paie pour la certitude de pouvoir récupérer un service, des données et un historique dans un délai acceptable.
Types de restauration
| Type | Exemple | Compétence attendue |
|---|---|---|
| Restore complet | Perte serveur ou corruption massive. | Reconstruire instance complète depuis backup. |
| PITR | Suppression accidentelle à 10:42. | Revenir à 10:41:59 sans appliquer l’erreur. |
| Restore partiel | Table supprimée ou schéma altéré. | Restaurer ailleurs puis réinjecter sélectivement. |
| Restore DR | Perte site primaire. | Basculer vers site secours avec procédure métier. |
Runbook de test restore
- Choisir un backup précis et noter son identifiant.
- Provisionner un serveur ou environnement isolé.
- Restaurer fichiers de données et journaux transactionnels.
- Appliquer la récupération jusqu’au point choisi.
- Ouvrir la base en mode contrôlé.
- Vérifier comptes, tables critiques, volumes, cohérence applicative.
- Mesurer durée réelle de restauration.
- Documenter écarts par rapport au RTO attendu.
PostgreSQL PITR conceptuel
restore_command = 'cp /srv/db-platform/postgres/wal_archive/%f %p'
recovery_target_time = '2026-06-01 10:41:59+02'
recovery_target_action = 'promote'Oracle restore validation
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG FROM TIME "SYSDATE-1" VALIDATE;
RECOVER DATABASE VALIDATE;15. PRA/PCA — reprise et continuité d’activité
Le PRA vise la reprise après sinistre. Le PCA vise la continuité de service. Le DBA doit relier les architectures de réplication, backup et standby aux besoins métier : perte acceptable de données, durée d’interruption acceptable, priorité des applications.
RPO / RTO
| Indicateur | Définition | Exemple | Impact architecture |
|---|---|---|---|
| RPO | Quantité maximale de données que l’on accepte de perdre. | 5 minutes | WAL/binlog/redo très fréquents, réplication proche temps réel. |
| RTO | Durée maximale acceptable avant reprise du service. | 30 minutes | Standby prêt, runbook, DNS/VIP, équipe entraînée. |
| MTTR | Durée moyenne de réparation. | 45 minutes | Mesure opérationnelle, amélioration continue. |
Matrice PRA/PCA par technologie
| Moteur | PRA minimal | PRA avancé | PCA / HA |
|---|---|---|---|
| PostgreSQL | Backup physique + WAL archive. | Standby distant + PITR. | Patroni + HAProxy + replicas. |
| Oracle | RMAN + archivelogs externalisés. | Data Guard site distant. | Data Guard Fast-Start Failover ou RAC selon contexte. |
| MySQL | Backup physique + binlogs. | Replica distant + GTID. | Semi-sync + orchestrateur/proxy. |
| MariaDB | mariabackup + binlogs. | Replica distant ou Galera multi-site prudent. | Galera local 3 nœuds + proxy. |
Runbook de crise
Identifier impact, moteur, instance, symptômes, heure de début, données à risque.
Choisir restore, switchover, failover, rollback applicatif ou attente.
Appliquer procédure validée, tracer actions, informer parties prenantes.
Contrôles techniques, tests applicatifs, cohérence métier, supervision.
Réintégration ancien primary, rebuild replica, retour DNS/proxy si nécessaire.
Timeline, cause racine, écarts RTO/RPO, actions préventives.
16. Check-list entretien et lab de préparation
Pour cette fiche DBA classique, tu dois préparer un discours orienté production : disponibilité, sauvegarde, restauration, réplication, diagnostic, sécurité et méthodes d’exploitation. Il faut aussi savoir poser les bonnes questions.
Lab personnel conseillé
| Bloc | Ce que tu dois monter | Preuve à montrer |
|---|---|---|
| PostgreSQL | 1 primary, 2 standby, pg_basebackup, WAL archive, PITR. | Capture failover manuel + restore PITR. |
| Patroni | 3 nœuds Patroni + etcd + HAProxy. | Switchover et failover testés. |
| pgBouncer | Pool transaction devant PostgreSQL. | Comparatif connexions directes vs poolées. |
| Oracle | Instance lab, archivelog, RMAN full/incrémental. | Restore validate et rapport backup. |
| MySQL/MariaDB | Source + replica GTID, puis semi-sync. | SHOW REPLICA STATUS propre et test failover. |
| Galera | 3 nœuds Galera. | Contrôle quorum, perte nœud, resync IST/SST. |
Questions à poser au recruteur
- Quels moteurs sont réellement en production et dans quelles versions ?
- Les bases tournent-elles sur VM, bare metal, cloud IaaS ou appliance ?
- Quels sont les RPO/RTO par application critique ?
- Les restaurations sont-elles testées ? À quelle fréquence ?
- Quel outil de sauvegarde est utilisé : RMAN, pgBackRest, Barman, XtraBackup, mariabackup ?
- Qui décide d’un failover en production ? DBA, astreinte, comité de crise ?
- Existe-t-il des runbooks validés et maintenus ?
- Quel outil de supervision : OEM, Zabbix, Prometheus, Grafana, Datadog, Dynatrace ?
- Les environnements de préproduction permettent-ils de tester les restores ?
- Quel est le niveau d’automatisation attendu ? Scripts, Ansible, Terraform, procédures manuelles ?
Réponses fortes à préparer
“Je considère qu’un backup n’est validé qu’après restauration testée, mesurée et documentée.”
“La réplication améliore la disponibilité mais ne remplace jamais une sauvegarde indépendante.”
“Je distingue switchover planifié, failover de crise et retour arrière. Chaque cas doit avoir son runbook.”
“Je relie toujours la solution technique au couple RPO/RTO métier. Sinon, on fait de la technologie sans contrat de service.”
Références utiles à garder en tête
| Sujet | Référence officielle |
|---|---|
| PostgreSQL replication | Documentation PostgreSQL — Runtime replication settings, standby servers, pg_basebackup. |
| Patroni | Documentation Patroni — HA PostgreSQL with distributed configuration store. |
| pgBouncer | Documentation pgBouncer — pooling modes and configuration. |
| Oracle RMAN | Oracle Backup and Recovery User’s Guide. |
| Oracle Data Guard | Oracle Data Guard Concepts and Administration. |
| MySQL replication | MySQL Reference Manual — replication and semisynchronous replication. |
| MariaDB Galera | MariaDB Galera Cluster documentation. |
