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
- Maturité IA : chez les entreprises les plus avancées, le défi passe du déploiement au passage à l’échelle
- BeyondTrust accélère sur l’identité des IA
- IA au travail : les Millennials utilisent l’IA sans filet, la Gen Z avance mieux accompagnée
- Agents IA incontrôlés et rappel à l’ordre de Bruxelles : pourquoi la réponse doit être technique, pas seulement juridique
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
