SQL Always On COPY ONLY backups - quel est l'intérêt si je ne peux pas restaurer l'AG à partir de ces sauvegardes?
Je pense que je connais déjà la réponse à cela, mais je vais quand même demander.
La situation est:
- SQL 2012 Always On - 2 répliques synchrones.
- 7 TB valeur de DB Sharepoint dans 1 AG.
- Avant de patcher - je veux une sauvegarde complète de la base de données.
- Le partage de sauvegarde se trouve sur le serveur secondaire B.
- Sauvegarde du serveur A vers le partage de sauvegarde sur le serveur B = 12 heures.
- Sauvegarde du serveur B vers le partage de sauvegarde sur le serveur B = 6 heures, MAIS les sauvegardes doivent être copiées UNIQUEMENT.
Si j'essaye de les restaurer et de créer un AG - cela échoue. Je dois prendre une AUTRE sauvegarde complète de la base de données = encore 6 heures, avant de pouvoir recréer l'AG.
Les sauvegardes COPY ONLY sont donc inutiles. A moins que je manque quelque chose? Quel est leur intérêt?
Les sauvegardes de copie uniquement sont généralement utilisées dans les situations où vous devez restaurer les données pour une raison inhabituelle sans perturber la chaîne de sauvegarde actuelle (en supposant qu'il y en ait une). Les raisons typiques sont les restaurations dans les boîtes de développement pour tester le code ou regarder une irrégularité dans les données. Vous avez eu l'idée.
En remarque, prendre des sauvegardes des secondaires AG est une sorte d'âne. Si l'AG est en retard, vos sauvegardes sont en retard. Si vous n'utilisez pas déjà le secondaire comme réplique lisible, ils en font un appareil de sauvegarde arrière coûteux, car vous devez maintenant le licencier entièrement (en supposant que vous disposez d'une assurance logicielle, et tout cela).
Une base de données doit disposer d'une sauvegarde complète avant de pouvoir être ajoutée à un groupe de disponibilité, et la méthode de création de la base de données n'a aucun impact sur cette exigence.
Vous devez effectuer une sauvegarde complète sur une base de données avant de l'ajouter à un groupe de disponibilité, que vous:
- Créer une nouvelle base de données
- Restaurez-le à partir d'une sauvegarde complète (y compris toute combinaison de différentiels et de journaux)
- Restaurez-le à partir d'une sauvegarde en copie seule
- Attachez-le
Donc, si vous vous retrouvez dans une situation où vous devez restaurer la base de données, vous devrez retarder son ajout au groupe de disponibilité jusqu'à ce que vous ayez effectué une sauvegarde complète, quel que soit le type de sauvegarde restauré. Selon Backup to NUL , vous pouvez sauvegarder sur un périphérique NUL pour satisfaire cette exigence. Ce serait la méthode la plus rapide possible pour remettre la base de données dans le groupe de disponibilité. Je ne l'ai pas testé, je ne peux donc pas confirmer que cela fonctionne.