La capacité de restauration réelle est la seule mesure fiable de l’efficacité d’un plan de sauvegarde.
En cas d’incident la vraie question n’est pas « Avons-nous des sauvegardes ? », mais « Sommes-nous capables de restaurer rapidement et correctement ? ».
Une sauvegarde non validée, non testée ou mal documentée équivaut en réalité à une absence de sauvegarde.
De plus, une sauvegarde mal protégée peut être altérée, copiée ou rendue inutilisable au moment où elle est la plus nécessaire.
SOLUTION COURANTE
Dans de nombreux environnements, la stratégie de sauvegarde repose sur :
La sauvegarde unique des données avec les outils RMAN et EXPDP
Sauvergarder uniquement les données applicatives, , sans toujours inclure ou vérifier la disponibilité des autres fichiers indispensables à une restauration complète, notamment :
- les fichiers de contrôle (control files) ;
- le SPFILE ou le PFILE ;
- le mode CDB/PDB ou base non multitenant ;
- les wallets (TDE, RMAN, identifiants);
- les mots de passe (SYS, SYSTEM, comptes applicatifs) ;
- les informations d’architecture (RAC ou non-RAC) ;
La vérification ponctuelle et visuelle des logs pour valider la bonne exécution des sauvegardes
Se limitant à constater la réussite apparente des jobs, sans valider la cohérence ni l’exploitabilité des sauvegardes en situation de restauration.
La conservation des fichiers de sauvegarde sur le serveur de production
Exposant ainsi l’ensemble des données et des sauvegardes aux mêmes risques (panne matérielle, corruption, attaque par rançongiciel ou compromission du système).
L’absence de tests documentés de la stratégie de restauration.
Laissant supposer que la restauration fonctionnera le moment venu, sans aucune garantie.
- le temps de reprise en temps réel ;
- l’intégrité des données ;
- les ressources humaines nécessaires;
- la capacité à reconstruire l’environnement dans son architecture exacte.
RECOMMANDATION
Vous pouvez aller plus loin en appliquant les règles suivantes:
Etendre la sauvegarde à tous les fichiers critiques (control files, spfile, wallets)
Une restauration réussie ne dépend pas uniquement des fichiers de données. Assurez-vous que votre stratégie de sauvegarde couvre l’ensemble des composants nécessaires à la reconstruction complète de la base de données, notamment :
- les fichiers de contrôle (control files) et spfile: très utilent pour les restaurations RMAN.
RMAN> show CONTROLFILE AUTOBACKUP;
show CONTROLFILE AUTOBACKUP;
RMAN configuration parameters for database with db_unique_name orcl are:
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default- Les fichiers de Wallet: indispensables pour ouvrir la nouvelle base de données. Vérifiez l’emplacement de votre magasin de clé et faites une sauvegarde physique de ce dossier.
SQL> Select * from V$ENCRYPTION_WALLET;
WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
-------------------- ---------------------------------------- ------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE /orabin/app/oracle/admin/orcltde/wallet OPEN PASSWORD SINGLE NONE NO
0
- Collectez les informations relatives à l’architecture de la base de données afin de préparer un environnement pouvant accueillir les données sauvegardées.
Automatiser la validation des fichiers de sauvegarde
Ne vous contentez pas de réussir les jobs de sauvegarde.
- Planifiez régulièrement des commandes de validation RMAN.
RMAN> restore database validate;
RMAN> RESTORE SPFILE VALIDATE;
RMAN> RESTORE CONTROLFILE VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE;
RMAN> validate database;
RMAN> validate archivelog all;- Pour les exports EXPDP :
- contrôlez automatiquement les logs ;
- vérifiez la taille et la cohérence des sauvegardes ;
- Testez périodiquement les importations sur une base de test.
Encrypter les sauvegardes et automatiser l’externalisation des fichiers générés
Activez le chiffrement des sauvegardes RMAN et des exportations EXPDP pour protéger les données contre le vol, la copie ou l’altération.
Le chiffrement doit être systématique, automatisé et accompagné d’une gestion rigoureuse des portefeuilles et des mots de passe qui y sont associés.
Activer le chiffrement RMAN par défaut
Cette configuration garantit que toutes les sauvegardes RMAN seront chiffrées, sans dépendre des scripts.
RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON;
RMAN> CONFIGURE ENCRYPTION ALGORITHM 'AES256';Oracle Data Pump propose le paramètre ENCRYPTION pour le chiffrement des sauvegardes
$ expdp hr schemas=HR directory=LABDIR schemas=HR dumpfile=hr.dmp logfile=exp_hr.log ENCRYPTION=ALL ENCRYPTION_PASSWORD=MyPasswordVous pouvez forcer l’encryptage via le portefeuille (Wallet) de la base de données en supprimant le paramètre ENCRYPTION_PASSWORD.
Documenter, planifier et exécuter périodiquement la stratégie de restauration
Une stratégie de sauvegarde n’a de valeur que si la restauration est :
- documentée ;
- testée ;
- répétable facilement.
Concrètement, il faut :
- Rédigez des procédures claires pour chaque scénario :
- perte d’un fichier de données,
- corruption logique, etc.
- perte totale de la base, etc.
- arrêt brusque d’un serveur
- restauration sur un nouveau serveur ;
- Planifiez des tests périodiques de restauration sur un environnement de test.
- Mesurez le temps de restauration réel et le comparez aux objectifs métier (RTO/RPO).
✨ EN BONUS
Assurez-vous que les sauvegardes expdp ne sont pas modifiées en utilisant le paramètre checksum (disponible à partir d’Oracle 21c)
$ expdp hr schemas=HR directory=LABDIR schemas=HR dumpfile=hr.dmp logfile=exp_hr.log checksum=yes checksum_algorithm=SHA256
$ impdp hr directory=LABDIR schemas=HR dumpfile=hr.dmp verify_only=yesAppliquez la règle du 3-2-1 aux fichiers de sauvegarde, qui consiste à conserver trois copies sur deux supports et une hors site.
- Maintenez trois copies de vos données : Il s’agit notamment des données originales et d’au moins deux copies. Cela garantit la redondance au cas où une ou deux copies seraient endommagées ou compromises lors d’une attaque par ransomware ou d’une défaillance matérielle.
- Utilisez deux types de support différents pour le stockage : Stockez vos données sur deux types de supports distincts : le stockage local et le cloud, le disque et la bande. Cette diversité permet d’assurer la protection contre les défaillances simultanées d’un même type de support.
- Conservez au moins une copie hors site : pour renforcer la sécurité des données, ajoutez une séparation géographique et réseau. Une chambre forte entièrement isolée, l’objectif consiste à isoler les données de sauvegarde de tout point de défaillance ou de faille unique au sein de votre environnement principal.
Ajoutez une sauvegarde périodique des archive logs
Les archivelogs jouent un rôle clé dans la réduction du RPO (Recovery Point Objective).
Sans leur sauvegarde régulière, la restauration ne peut se faire qu’à partir de la dernière sauvegarde complète, ce qui peut entraîner une perte de données significative.
Combinez la sauvegarde des archivelogs avec leur suppression contrôlée :
RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;
