Bienvenue > Outils de sauvegarde SQL Server de Bacula

Outils de sauvegarde SQL Server de Bacula

Effectuez des sauvegardes et des restaurations rapides et pratiques avec nos outils de sauvegarde MS SQL Server.

Parmi sa vaste gamme de fonctionnalités, Bacula Enterprise sauvegarde également vos données Windows avec une combinaison impressionnante de facilité et de fonctionnalité.

Cela inclut la possibilité d’effectuer des sauvegardes rapides et pratiques grâce à notre outil de sauvegarde MS SQL. Vous pouvez désormais sauvegarder avec précision de très grandes quantités de données spécifiques basées sur Windows dans votre serveur SQL pour une fraction des coûts de la concurrence – et réaliser une restauration ponctuelle du serveur SQL.

Utilisez Bacula pour éviter d’utiliser plusieurs solutions de sauvegarde, ou d’avoir une protection inadéquate contre les ransomwares.

sql server backup tool

Télécharger la version d’essai Voir le webinar sur la sauvegarde de Télécharger le whitebook MS SQL Backup

Demander d’Essai

Testez Bacula en 2 heures en essayant différents scénarios spécifiques

Télécharger le Webinar

Découvrez les meilleures stratégies de sauvegarde et de restauration après sinistre.

Récupération après sinistre Guide et Plan

Guide de restauration après sinistre et modèle de plan de restauration après sinistre des professionnels de Bacula.

Livres blancs sur la technologie Bacul

Améliorez votre stratégie de sauvegarde et réduisez vos dépenses en la matière.

Backup System Scorecard

Évaluez rapidement la robustesse de votre système de sauvegarde.

Plus d’options – Un logiciel de sauvegarde SQL plus sophistiqué

Le logiciel de sauvegarde SQL de Bacula Systems offre des performances exceptionnelles grâce à une architecture moderne très fiable et vous offre les fonctionnalités suivantes de l’outil de sauvegarde SQL Server :

Sauvegardes complètes, incrémentales et différentielles de SQL Server.
Sauvegarde SQL au niveau de la base de données
Restauration au point dans le temps (PITR)
Possibilité d’inclure/exclure des bases de données de la tâche de sauvegarde

Support pour les sauvegardes « Copy Only’’
Restauration des fichiers de sauvegarde MS SQL sur le disque
Envoi du flux de sauvegarde directement au Storage Daemon
Commande de plugin de somme de contrôle et option de restauration pour demander au serveur SQL de vérifier la somme de contrôle des données.

Outils de sauvegarde SQL Server – indépendants du moteur VSS

Le logiciel de sauvegarde MS SQL de Bacula n’utilise pas les snapshots VSS pour effectuer la sauvegarde, il est donc possible de spécifier « Activer VSS = non » dans le FileSet de Bacula. Cette solution de sauvegarde du serveur MSSQL permet d’obtenir des capacités avancées de sauvegarde et de restauration via l’API Microsoft pour SQL Server. Par conséquent, nous supportons également les mécanismes de sécurité et les types d’authentification fournis avec Microsoft SQL Server.

Cryptage et compression des sauvegardes SQL Server

Avec les capacités de compression de sauvegarde SQL Server de Bacula Enterprise, vous pouvez profiter d’une sauvegarde efficace avec compression et, par conséquent, avec une utilisation de la bande passante réseau bien moindre. Les technologies de sécurité de Bacula incluent le cryptage EFS ou TLS qui vous permet d’envoyer des sauvegardes MS SQL en toute sécurité du fichier au démon de stockage.

Sauvegarde du journal des transactions et PITR

Bacula Enterprise vous permet de restaurer un ensemble de données MSSQL ou un paramètre particulier à partir d’un moment très précis dans le passé. Avec les modèles de restauration complète ou en masse, vous pourrez faire un PITR ou utiliser les informations LSN pour restaurer l’état exact que vous souhaitez avoir. Vous pouvez restaurer exactement l’état requis de la base de données à un moment très précis dans le temps – même à la seconde près. À partir d’une sauvegarde du journal des transactions, une restauration composera l’état de la base de données à partir d’une variété de types de sauvegarde SQL Server choisis.

Automatisation des sauvegardes

Avec les capacités de planification et les fonctions de script de Bacula Enterprise, vous êtes en mesure de mettre en œuvre l’automatisation des sauvegardes SQL Server et de réduire le temps de gestion de vos sauvegardes. Les tâches de sauvegarde de votre serveur SQL peuvent être lancées en utilisant une logique de script et un planificateur.

Options du logiciel de sauvegarde SQL

Sauvegarde complète

La sauvegarde complète sauvegarde les fichiers de la base de données et le journal des transactions afin de fournir une protection complète contre les défaillances du support. Si un ou plusieurs fichiers de données sont endommagés, la restauration du support peut restaurer toutes les transactions engagées. Les transactions en cours sont annulées. Les bases de données master et mbdb sont toujours sauvegardées dans ce mode.

Sauvegarde différentielle

Une sauvegarde différentielle est basée sur la sauvegarde complète de la base de données la plus récente et précédente. Une sauvegarde différentielle capture uniquement les données qui ont changé depuis cette sauvegarde complète. Lorsque vous utilisez la fonction de sauvegarde différentielle, la chaîne de sauvegarde est très critique. Si pour une raison quelconque, la sauvegarde complète utilisée comme référence par MS SQL n’est pas disponible, les données différentielles ne seront pas utilisables. Les outils de sauvegarde et de restauration SQL de Bacula utilisent différentes techniques pour éviter ce problème, donc si un problème est détecté, la sauvegarde différentielle de la base de données peut-être automatiquement mise à jour vers une sauvegarde complète.

Sauvegarde du journal des transactions

La fonction MS SQL « Transaction Log Backup » est implémentée au niveau « Incrémental » avec Bacula. La base de données doit être configurée avec le modèle de restauration complète ou le modèle de restauration par lot. Si la base de données utilise le modèle de restauration simple, le fichier journal des transactions sera tronqué après chaque point de contrôle et la sauvegarde du journal des transactions ne permettra pas la restauration ponctuelle. La restauration complète sera possible, mais pas la restauration à un point dans le temps.

Configuration de la base de données MS SQL

La base de données maître doit être sauvegardée. Si la base de données maître est endommagée d’une manière ou d’une autre, par exemple à cause d’une défaillance du support, une instance de MS SQL peut ne pas être capable de démarrer. Dans ce cas, il est nécessaire de reconstruire master, puis de restaurer la base de données à partir d’une sauvegarde. Seules des sauvegardes complètes de la base de données master peuvent être créées.

Restauration du serveur SQL

Vous pouvez utiliser toutes les méthodes habituelles pour lancer une restauration. Cependant, vous devez vous assurer que si vous restaurez des données différentielles, la sauvegarde complète précédente est également restaurée. Cela se produit automatiquement si vous démarrez la restauration, dans bconsole, en utilisant les options de restauration 5 ou 12. Dans l’arbre de fichiers généré, vous devez marquer soit des bases de données complètes, soit des instances de bases de données.

Options de restauration

Bacula Enterprise est conçu pour offrir à l’utilisateur de nombreuses options dans le processus de restauration des données, et restaurer les données de différentes manières. Certaines de ces options sont couramment utilisées lors de la restauration comme :

Le paramètre Where : Comme pour les fonctionnalités habituelles de Bacula Enterprise, ce paramètre permet à l’administrateur de restaurer les données à un endroit spécifique.
Le paramètre Replace : Il est utilisé pour dicter comment Bacula doit se comporter avec les données existantes lors de la restauration.

En plus de cela, le plugin de sauvegarde SQL Server lui-même apporte des options de restauration plus complètes, telles que :

Instance : Comme MS SQL gère plusieurs instances, le plugin MS SQL de Bacula Enterprise vous permet de choisir laquelle restaurer. Une granularité fine est la clé. Ce paramètre est facultatif et s’il n’est pas défini, la restauration utilisera la valeur de sauvegarde et de restauration MS SQL définie au moment de la sauvegarde. Par défaut, le nom de l’instance est « MSSQLSERVER ».
Base de données. Cette option spécifie le nom des bases de données à restaurer, et utilise la valeur MS SQL Backup and Restore définie au moment de la sauvegarde. Ce paramètre est facultatif. Par défaut, le plugin utilise l’option Where pour déterminer le nom de la nouvelle base de données. Si Where et Database sont tous deux définis sur un nom de base de données valide, Database sera utilisé.
User. Il s’agit du nom d’utilisateur utilisé pour se connecter à l’instance MS SQL. Ce paramètre est facultatif, et s’il n’est pas défini, la restauration utilisera la valeur définie au moment de la sauvegarde.
Mot de passe. Le mot de passe utilisé pour se connecter à l’instance MS SQL. Ce paramètre est facultatif et s’il n’est pas défini, la restauration utilisera la valeur définie au moment de la sauvegarde.

Domaine. Il s’agit du domaine utilisé pour se connecter à l’instance MS SQL. Ce paramètre est facultatif et s’il n’est pas défini, la restauration utilisera la valeur définie au moment de la sauvegarde.
Restauration. Ceci spécifie si la base de données utilisera l’option RECOVERY ou NORECOVERY pendant la restauration. Par défaut, la base de données restaurée sera récupérée.
Stop_before_mark. Pour utiliser la clause WITH STOPBEFOREMARK = <point> afin de spécifier que l’enregistrement du journal qui se trouve immédiatement avant la marque est le point de restauration. Le point peut-être une date et une heure, un numéro LSN ou un nom de marque.
Stop_at_mark. Pour utiliser la clause WITH STOPATMARK = <point> afin de spécifier que la transaction marquée est le point de restauration. STOPATMARK effectue un roll forward jusqu’à la marque et inclut la transaction marquée dans le roll forward. Le point peut-être une date et une heure, un numéro LSN ou un nom de marque.
Stop_at=<datetime>. Pour utiliser la clause WITH STOPAT = <datetime> pour spécifier que la date-heure est le point de restauration.
Restrict_user. Pour utiliser la clause WITH RESTRICT_USER afin de restreindre l’accès à la base de données restaurée. La valeur par défaut est non.

Sur Bacula System’s BWeb Management Suite, les options du plugin sont disponibles dans l’onglet de restauration.

Restauration ponctuelle du serveur SQL

Cette rubrique n’est pertinente que pour les bases de données SQL Server qui utilisent les modèles de restauration complète ou bulk-logged. Dans le cadre du modèle de restauration bulk-logged, si une sauvegarde du journal contient des modifications bulk-logged, la restauration point-in-time n’est pas possible à un point de cette sauvegarde. La base de données doit être récupérée jusqu’à la fin de la sauvegarde du journal des transactions.

Il est possible d’effectuer une restauration ponctuelle d’une base de données MS SQL directement à partir du plugin MS SQL. Il est également possible de restaurer les fichiers localement et d’effectuer l’opération à partir de la console de gestion de Microsoft SQL Server pour avoir plus d’options.

Informations LSN

Les LSN sont utilisés en interne pendant une séquence RESTORE pour suivre le point dans le temps auquel les données ont été restaurées. Lorsqu’une sauvegarde est restaurée, les données sont restaurées au LSN correspondant à l’instant où la sauvegarde a été effectuée.

Le LSN d’un enregistrement de journal auquel un événement de sauvegarde et de restauration donné s’est produit peut-être visualisé en utilisant un ou plusieurs des éléments suivants :

Sortie du job de sauvegarde Bacula
Noms des fichiers journaux
Table msdb.backupset
Table msdb.backupfile

Lors d’un job de sauvegarde avec le module MS SQL, les informations suivantes concernant les numéros LSN seront affichées dans la sortie du job:

win-fd JobId 3: LSN for « db29187 »: First: 42000146037, Last: 44000172001

Le numéro First LSN correspond au dernier LSN de la dernière sauvegarde des journaux des transactions. Il peut s’agir de la toute première sauvegarde complète, ou de la dernière sauvegarde transactionnelle (incrémentielle). Le numéro Last LSN correspond à la dernière transaction enregistrée dans le journal.

Avec une sauvegarde du journal des transactions (Incrémentielle), le nom de fichier associé à cette base de données dans le travail Incrémentiel sera :

/@mssql/MSSQLSERVER/db29187/log-42000162001.trn

Le numéro dans le nom, ici 42000162001, correspond au dernier LSN du job précédent (Totale ou Incrémentale).

Dans l’exemple montré sur la Fig 2, si l’administrateur a besoin de restaurer la base de données à l’état qui correspond au LSN 14, il peut le faire avec les actions suivantes :

Utiliser l’option 5 du menu de restauration
Parcourir le répertoire de la base de données « /@mssql/db29187 ».
Sélectionner le dernier fichier de sauvegarde complète « data.bak » (LSN : 10)
Sélectionnez la sauvegarde incrémentale « log-10.trn ».
Spécifiez l’option stop_at_mark sur « lsn:14 ».
Exécutez le travail de restauration

ou si la dernière sauvegarde complète SQL n’est pas disponible mais que la sauvegarde complète précédente l’est.

Utilisez l’option 3 du menu de restauration, sélectionnez les jobids pertinents.
Parcourez le répertoire de la base de données « /@mssql/db29187 ».
Sélectionnez le fichier de sauvegarde complet « data.bak » (LSN : 2)
Sélectionnez les sauvegardes incrémentales « log-2.trn », « log-3.trn », « log-10.trn ».
Spécifiez l’option stop_at_mark sur « lsn:14 ».
Exécutez la tâche de restauration

Aperçu des scénarios de restauration SQL

Description	Où	Base de données	Exemple
Restaurer les fichiers sur le disque	Path		where=c:/tmp
Restaurer la base de données originale			where=/
Restaurer avec un nouveau nom	Nom		where=newdb
Restaurer avec un nouveau nom		Nom	database=newdb
Restaurer avec un nouveau nom et une nouvelle localisation du fichier	Path	Nom	where=c:/tmp database=newdb

Scénarios de restauration

Restauration avec le même nom

Pour restaurer une base de données avec le même nom, le paramètre where doit être vide ou « / » et l’indicateur replace= doit être défini sur always ou la base de données originale doit être abandonnée en premier.

* restore where=/ replace=always
…
Using Catalog « MyCatalog »
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/127.0.0.1-dir.restore.1.bsr
Where: /
Replace: Always
FileSet: Full Set
Backup Client: win2008-fd
Restore Client: win2008-fd
Storage: File
When: 2015-12-14 09:53:36
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no):

Restauration d’une base de données SQL avec un nouveau nom

Pour restaurer une base de données avec un nouveau nom, il peut-être nécessaire de déplacer les fichiers de la base de données sur le disque. Cela dépend si la base de données originale est toujours présente.

Si la base de données originale n’est plus disponible, le paramètre where ou la base de données « Plugin Options » peut contenir le nouveau nom de la base de données, et le plugin gérera automatiquement la création de la base de données avec le nouveau nom.

Si la base de données originale est toujours nécessaire, le paramètre where est utilisé pour relocaliser les fichiers sur le disque, et le nouveau nom de la base de données doit être défini dans le menu « Plugin Options » avec l’option database. Le fichier layout.dat doit être sélectionné dans l’arbre de restauration.

* restore where=c:/tmp replace=always
…
Using Catalog « MyCatalog »
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/127.0.0.1-dir.restore.1.bsr
Where: c:/tmp
Replace: Always
FileSet: Full Set
Backup Client: win2008-fd
Restore Client: win2008-fd
Storage: File
When: 2015-12-14 09:53:36
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod <—————–
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: When
7: Priority
8: Bootstrap
9: Where
10: File Relocation
11: Replace
12: JobId
13: Plugin Options
Select parameter to modify (1-13): 13 <—————–
Automatically selected : mssql: database=db29187
Plugin Restore Options
instance: *None*
database: *None*
username: *None*
password: *None*
domain: *None*
recovery: *None* (yes)
stop_before_mark: *None*
stop_at_mark: *None*
stop_at: *None*
Use above plugin configuration? (yes/mod/no): mod <——————
You have the following choices:
1: instance (Instance used to restore)
2: database (New database name)
3: username (Username used for restore)
4: password (Password used for restore)
5: domain (Domain name of user (default to local))
6: recovery (Start Recovery)
7: stop_before_mark (Stop the recovery before a mark (STOPBEFOREMARK).
8: stop_at_mark (Stop the recovery at a mark (STOPATMARK).
9: stop_at (Stop at (STOPAT). {datetime})
Select parameter to modify (1-9): 2 <——————
Please enter a value for database: newdb <——————
Use above plugin configuration? (yes/mod/no): yes <——————
Using Catalog « MyCatalog »
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/127.0.0.1-dir.restore.1.bsr
Where: c:/tmp
Replace: Always
FileSet: Full Set
Backup Client: win2008-fd
Restore Client: win2008-fd
Storage: File
When: 2015-12-14 09:53:36
Catalog: MyCatalog
Priority: 10
Plugin Options: User Specified
OK to run? (yes/mod/no): yes <—————–

Restauration SQL sur un disque local

En spécifiant where=c:/path/, les fichiers seront restaurés sur le système de fichiers local et l’administrateur MS SQL peut utiliser un TSQL ou la console de gestion du serveur Microsoft SQL pour restaurer la base de données. Les commandes SQL nécessaires à la restauration de la base de données sont imprimées dans la sortie du job, comme le montre l’exemple suivant.

* restore where=c:/tmp
Vous devez d’abord sélectionner un ou plusieurs JobIds qui contiennent des fichiers à restaurer. Plusieurs méthodes vous seront présentées pour spécifier les JobIds. Ensuite, vous serez autorisé à sélectionner les fichiers de ces JobIds qui doivent être restaurés.
Pour sélectionner les JobIds, vous avez les choix suivants :
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Select full restore to a specified Job date
13: Cancel
Select item: (1-13): 5
Automatically selected Client: win2008-fd
+——-+——-+———-+———-+———————+—————+
| jobid | level | jobfiles | jobbytes | starttime | volumename |
+——-+——-+———-+———-+———————+—————+
| 1 | F | 3 | 65,771 | 2015-12-14 09:52:31 | TestVolume001 |
| 2 | I | 2 | 65,771 | 2015-12-14 09:52:42 | TestVolume001 |
| 3 | I | 2 | 65,771 | 2015-12-14 09:52:52 | TestVolume001 |
+——-+——-+———-+———-+———————+—————+
You have selected the following JobIds: 1,2,3
Building directory tree for JobId(s) 1,2,3 …
6 files inserted into the tree.
You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the « all » keyword on the command line.
Enter « done » to leave this mode.
cwd is: /
$ cd @mssql
cwd is: /@mssql/
$ cd MSSQLSERVER
cwd is: /@mssql/MSSQLSERVER/
$ m db1684
6 files marked.
$ done
Bootstrap records written to /opt/bacula/working/127.0.0.1-dir.restore.1.bsr
The Job will require the following (*=>InChanger):
Volume(s) Storage(s) SD Device(s)
===========================================================================
TestVolume001 File FileStorage
Volumes marked with « * » are in the Autochanger.
2 files selected to be restored.
Using Catalog « MyCatalog »
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/127.0.0.1-dir.restore.1.bsr
Where: /tmp
Replace: Always
FileSet: Full Set
Backup Client: win2008-fd
Restore Client: win2008-fd
Storage: File
When: 2015-12-14 09:53:36
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): yes
Job queued. JobId=6
wait
You have messages.
* messages
$ done
17:18 dir JobId 6: Start Restore Job RestoreFiles.2015-12-14_17.18.18_14
17:18 dir JobId 6: Using Device « FileStorage » to read.
17:18 sd JobId 6: Ready to read from volume « TestVolume001 » on file device « FileStorage » (/tmp/regress/tmp).
17:18 sd JobId 6: Forward spacing Volume « TestVolume001 » to file:block 0:224.
17:18 fd JobId 6: RESTORE DATABASE [db1684] FROM DISK=’c:/tmp/@mssql/MSSQLSERVER/db1684/data.bak’
WITH BLOCKSIZE=65536, BUFFERCOUNT=10, MAXTRANSFERSIZE=65536, NORECOVERY , REPLACE
17:18 fd JobId 6: RESTORE DATABASE [db1684]
FROM DISK=’c:/tmp/@mssql/MSSQLSERVER/db1684/log-34000000014400001.bak’
WITH BLOCKSIZE=65536, BUFFERCOUNT=10, MAXTRANSFERSIZE=65536, NORECOVERY
17:18 fd JobId 6: RESTORE DATABASE [db1684]
FROM DISK=’c:/tmp/@mssql/MSSQLSERVER/db1684/log-34000000018400001.bak’
WITH BLOCKSIZE=65536, BUFFERCOUNT=10, MAXTRANSFERSIZE=65536, NORECOVERY
17:18 fd JobId 6: RESTORE DATABASE [db1684]
FROM DISK=’c:/tmp/@mssql/MSSQLSERVER/db1684/log-34000000029100001.bak’
WITH BLOCKSIZE=65536, BUFFERCOUNT=10, MAXTRANSFERSIZE=65536, NORECOVERY
17:18 sd JobId 6: End of Volume at file 0 on device « FileStorage » (/tmp/regress/tmp), Volume « TestVolume001 »
17:18 fd JobId 6: RESTORE DATABASE [db1684]
FROM DISK=’c:/tmp/@mssql/MSSQLSERVER/db1684/log-36000000017200001.bak’
WITH BLOCKSIZE=65536, BUFFERCOUNT=10, MAXTRANSFERSIZE=65536, NORECOVERY
17:18 sd JobId 6: Elapsed time=00:00:01, Transfer rate=9.372 M Bytes/second
17:18 fd JobId 6: RESTORE DATABASE [db1684]
17:18 dir JobId 6: Bacula dir 8.4.8 (22Feb16):
Build OS: x86_64-unknown-linux-gnu archlinux
JobId: 6
Job: RestoreFiles.2015-12-11_17.18.18_14
Restore Client: win2008-fd
Start time: 14-Dec-2015 17:18:20
End time: 14-Dec-2015 17:18:22
Files Expected: 6
Files Restored: 6
Bytes Restored: 9,371,785
Rate: 4685.9 KB/s
FD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Restore OK

Restaurer la base de données « master »

Les instructions sur la façon de restaurer la base de données « master » sont détaillées dans cet article : https://technet.microsoft.com/en-us/library/aa213839%28v=sql.80%29.aspx

Base de données dans l’état de restauration

À la fin d’une restauration, si l’option de restauration du plugin était définie sur no, la base de données restaurée sera dans l’état « restauration ». Pour terminer le processus de restauration, le processus de restauration doit être exécuté. Cela peut-être fait avec la commande SQL suivante :

RESTORE [yourdatabase] WITH RECOVERY;