Pourquoi TO DISK = N’NUL’?
Je ne comprends pas pourquoi vous utilisez TO DISK = N’NUL’:
BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’
Si vous faites cela, la sauvegarde est enregistrée dans NUL(c'est-à-dire. = Nulle part / rien) et ne peut pas être utilisée car son fichier n'existe pas.
Bien qu'il NULpuisse également être utilisé comme destination pour les sauvegardes de LOG, il ne doit pas être utilisé non plus, en particulier sur les serveurs Prod car les LOG seront perdus et la chaîne de sauvegarde sera rompue. (~ similaire à a SHRINKFILE)
Sauvegarde du LOG
Avant d'ajouter une base de données au groupe, vous devez la préparer. Lorsque vous souhaitez préparer une base de données secondaire, au moins 1 sauvegarde du journal des transactions doit être effectuée et restaurée. Le miroir l'utilise pour déterminer quelles transactions ont déjà été synchronisées sur la base de données secondaire et quelles transactions ne sont pas encore synchronisées avec la base de données principale.
Par conséquent, vous devez sauvegarder les journaux de transactions sur la base de données principale:
BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak'
WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
L' COPY_ONLYoption doit être utilisée. Il s'assure que les journaux ne sont pas tronqués à la fin de la sauvegarde du journal.
Chaîne de sauvegarde DB principale
Cependant, vous ne pouvez pas restaurer une sauvegarde de journal seule, c'est-à-dire sans chaîne de sauvegarde (voir également la réponse de Kin). Cela signifie que la sauvegarde du journal des transactions doit être effectuée après une sauvegarde complète de la base de données (+ un différentiel facultatif si nécessaire).
Étant donné que l' COPY_ONLYoption ne rompt pas la chaîne de sauvegarde, elle ne crée pas non plus de chaîne de sauvegarde. L' COPY_ONLYoption ne peut pas être utilisée pour la sauvegarde de la base de données.
Sauvegardes dans l'ordre:
- Sauvegarde complète de la base de données sans l'
COPY_ONLYoption
- Sauvegarde différentielle en option
- 1 sauvegarde de LOG avec
COPY_ONLYoption
- une autre (ou plus) sauvegarde LOG si nécessaire ...
Restaurer la base de données secondaire
Ensuite, la sauvegarde de la base de données doit être restaurée (+ différentielle) sur le secondaire.
Il doit être restauré avec l' NORECOVERYoption car vous souhaitez également restaurer la ou les sauvegardes LOG une fois la sauvegarde complète restaurée.
Enfin, vous restaurerez la sauvegarde LOG. Vous devez toujours utiliser l' NORECOVERYoption, car le miroir continuera de restaurer les transactions une fois en place.
- Restaurer la sauvegarde complète avec l'
NORECOVERYoption
- Restaurer la sauvegarde DIFF avec l'
NORECOVERYoption
- Restaurer toutes les sauvegardes LOG dans l'ordre avec l'
NORECOVERYoption
Permet de tout assembler (l'adapter à votre env)
Sur l'exécution du serveur principal:
USE master
Go
BACKUP DATABASE [test0916aj8CJ] TO DISK = N'....bak'
WITH FORMAT, INIT, NAME = N'test0916aj8CJ-Full Database Backup', STATS = 10
GO
BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak'
WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
GO
Sur le serveur secondaire, exécutez:
USE master
Go
RESTORE DATABASE [test0916aj8CJ] FROM DISK = N'....bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE LOG [test0916aj8CJ] FROM DISK = N'....bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
Vous pouvez ensuite ajouter la nouvelle base de données secondaire au groupe de disponibilité ...
Actions facultatives
- Il est préférable de définir l'option DISK sur un dossier partagé disponible à partir des serveurs principal et secondaire.
- Il est également préférable de stocker les fichiers DB sur un disque et un emplacement similaires sur les serveurs principal et secondaire.
