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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Fraude par identité synthétique : comment l’IA peut redonner confiance aux entreprises et à leurs clients
- VirtualBrowser protège la navigation web à la source
- Innovation et performance : le rôle clé du consulting dans la transformation numérique
- Sekoia.io : l’alternative européenne qui s’impose dans la cybersécurité
Articles les + lus
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
À la une de la chaîne Tech
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
