SQL Server suspend les log backups pendant l'exécution d'une sauvegarde de base de données complète. Vous risquez de perdre beaucoup de données en cas de défaillance d'un site frappant pendant une sauvegarde complète. Ce scénario peut sembler improbable, mais quand la sauvegarde de la base de données complète se compte
Quelle est votre stratégie de sauvegarde ? (2)
en heures, le risque de perte
de données augmente. S’il faut 8
heures pour sauvegarder la base de
données, votre site secondaire pourrait
bien avoir un retard de 8 heures
par rapport au moment d’une défaillance,
résultant en 8 heures de
perte de données si la sauvegarde
n’était pas terminée ou ne s’était pas
copiée sur l’emplacement secondaire.
Perdre 8 heures de données est inacceptable.
Et si un log backup pouvait se
dérouler pendant l’exécution d’une
sauvegarde différente ? Vous pourriez
ainsi envoyer des changements à un
autre site même pendant l’exécution
de vos grandes sauvegardes. Pour procéder
à des log backups chaque minute
(une bonne fréquence pour minimiser
la perte de données), vous
pourriez choisir de ne plus effectuer
du tout de sauvegardes de base de
données complète. En utilisant une
stratégie de sauvegarde par fichier et
groupe de fichiers, vous pourriez éviter
entièrement l’exécution d’une sauvegarde
de base de données complète,
de sorte que les log backups ne marqueraient
jamais de pause. Cette stratégie
permet aux données d’un site secondaire
de se trouver le plus près
possible de celles du site primaire et
réduit le risque de perte de données.
Certaines stratégies de sauvegarde
et de restauration présentent un petit
nombre de restrictions. Par exemple,
une sauvegarde de base de données
complète n’a pas de restrictions réelles – on peut l’effectuer à n’importe quel
moment.
En revanche, les stratégies de
sauvegarde de fichiers et de groupes
de fichiers sont un peu plus élaborées
et ont quelques exigences clé qu’il faut
bien comprendre. En premier lieu, les
sauvegardes du genre log backup doivent
être régulières.
Les log backups
sont un élément clé de la restauration
et sont nécessaires pour la reprise si
vous utilisez la stratégie de sauvegarde
de fichiers et de groupes de fichiers.
Pour permettre des log backups et minimiser
ainsi le risque de perte de travail,
vous devez d’abord régler le modèle
de reprise de la base de données
sur Full ou Bulk_logged.
Comme le
modèle de reprise Simple ne vous permet
pas de sauvegarder le journal des
transactions, ce modèle de reprise
n’est pas compatible avec la stratégie
de sauvegarde de fichiers et de
groupes de fichiers.
Téléchargez cette ressource
SIEM & PME : Comment construire la boîte noire de votre SI ?
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et accessible, pour anticiper, détecter et réagir efficacement aux attaques.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- La connectivité, nouvelle colonne vertébrale de l’expérience en magasin
- Assises de la Sécurité 2026 : osons remettre l’humain au centre et reprendre les commandes
- Réforme de la facturation électronique 2026 : de la contrainte réglementaire à un véritable enjeu différenciant
- IA : la sécurité se prépare aux accès agentiques
Articles les + lus
Continuer avec Exchange Server : quelles conséquences ?
Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
Sécurité : une approche dans la durée avant tout
À la une de la chaîne Tech
- Continuer avec Exchange Server : quelles conséquences ?
- Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
- Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
- Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
- Sécurité : une approche dans la durée avant tout
