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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Cybersécurité française 2026 : explosion des startups, ralentissement des scale-ups et virage stratégique de l’IA
- Le Cercle de l’Innovation décerne le Prix de l’Innovation du Public 2026
- Avec l’IA agentique, la robustesse des SI redevient stratégique
- Les erreurs du secteur bancaire dans son approche IA
Articles les + lus
Couchbase lance AI Data Plane pour industrialiser l’IA agentique
Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
À la une de la chaîne Tech
- Couchbase lance AI Data Plane pour industrialiser l’IA agentique
- Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
