SQL Server : Comment fonctionne une sauvegarde complète ?
La sauvegarde complète est l'une des bases de l'administration d'un serveur de base de données et donc de SQL Server. Et pourtant à mon sens relativement méconnue.
La sauvegarde des données dans SQL Server se fait à chaud, c'est-à-dire que la base de données est toujours accessible en lecture et en écriture pendant la phase de sauvegarde. Tout au plus remarquerez vous un léger ralentissement pendant cette dernière. Les données sont recopiées vers un ou plusieurs fichiers disques ou un ou plusieurs lecteurs de bande.
La sauvegarde complète se réalise avec la syntaxe suivante
BACKUP DATABASE AdventureWorks
TO <unité de sauvegarde>
Pour réaliser une sauvegarde vers le disque il suffit d'exécuter la commande suivante
BACKUP DATABASE AdventureWorks
TO DISK = 'C:\test\backup.bak'
L'extension de fichier .BAK n'est pas obligatoire c'est une convention fréquente avec SQL server pour les sauvegardes de données.
Comment la sauvegarde à chaud est elle possible ?
En fait SQL Server possède un journal de transaction pour chaque base de données (C'est le fichier portant par défaut l'extension LDF). Ce journal contient la liste de toutes les transactions (équivalent à toutes les requêtes modifiant les données) exécutées sur la base de données. Le processus de sauvegarde va en même temps qu'il démarre la copie des pages de données (bloc de 8ko) marquer le moment du début de cette opération (en fait on mémorise l'emplacement le plus ancien dans le journal correspondant soit à la plus ancienne transaction actuellement en cours, doit le dernier Checkpoint, soit le début de la sauvegarde) dans le journal de transaction. L'opération de sauvegarde peut durer plusieurs heures jusqu'à sa fin il est donc impossible d'avoir une version consistante de la base de données juste avec la copie des pages de données, c'est pour cela qu'à la fin de la sauvegarde, SQL Server marque à nouveau le journal est réalise une copie de ce dernier entre les 2 marques.
La restauration de la base de données revient dès lors à recopier les pages de données sauvegardées et à rejouer la portion de journal stockées dans la sauvegarde (donc à reéxecuter les requêtes ayant modifiées les donnés pendant la sauvegarde). La base de données est alors restaurée dans l'état dans lequel elle était à la fin de la sauvegarde.
Quelques conséquences pratiques
- Il faut impérativement mémoriser la date et heure de fin de vos opérations de sauvegarde, étant donné que l'on ne peut restaurer une base de données qu'à cette date et heure avec une sauvegarde complète.
- Le journal de transaction ne sera jamais tronqué pendant une opération de sauvegarde (il est susceptible de grossir pendant cette phase). C'est l'une des raisons pour lesquelles on conseille de réaliser la sauvegarde pendant une phase d'accalmie sur le serveur (la nuit en général).
- Le temps de restauration est fonction de la durée de la sauvegarde et aussi de l'activité d'écriture sur la base de données pendant la sauvegarde. Vous pouvez avoir un écart considérable de temps de restauration entre une base sauvegardée en journée ou dans la nuit. C'est aussi l'une des raisons pour lesquelles on conseille de réaliser la sauvegarde pendant une phase d'accalmie sur le serveur (la nuit en général).
Du nouveau dans SQL Server 2008 ?
Dans SQL Server 2008 sera ajoutée une fonctionnalité attendue depuis pas mal de temps, et déjà implémenté par de nombreux éditeurs tiers : la compression des sauvegardes. Cela à un double effet la diminution de la taille des fichiers de sauvegarde et la diminution de la durée de la sauvegarde. La conséquence négative est la plus forte consommation de processeur pendant la sauvegarde (modérée tout de même).
Cette option sera active par défaut dans cette version.
Bonne sauvegarde…
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :