J'ai besoin de sauvegarder 10 à 20 bases de données SQL Server 2008 R2 avec des tailles comprises entre 10 et 50 Go, alors qu'elles sont en ligne et utilisées simultanément par une seule application d'entreprise. J'ai également besoin de les restaurer dans un état largement synchronisé sur toutes les bases de données (je peux me permettre jusqu'à quelques secondes de désynchronisation entre les bases de données). Le but est de capturer les données de production pour les environnements QA / DEV.

Je voudrais fortement ne pas exiger de bases de données exécutées en récupération complète et proposer une méthode de sauvegarde dédiée à la capture de données pour les environnements QA et qui reste indépendante d'un processus de sauvegarde principal qui n'est pas sous mon contrôle.

Pour mes clients, il faudra 1 à 2 heures pour capturer 20 sauvegardes complètes à ~ 30 Go chacune. Cela rend la prise de sauvegardes complètes séquentiellement inacceptable car les bases de données seraient trop désynchronisées lors de l'exécution dans une récupération simple.

Je cherche une idée meilleure que celles-ci:

IDÉE 1: Instantané au niveau SAN des disques VM. xcopy MDF / LDF à partir d'un instantané.

Une fois les fichiers copiés attachés à une autre instance de serveur, son processus de récupération devrait produire des bases de données cohérentes qui sont à peu près instantanées.
La recherche sur Google m'a convaincu que c'est une mauvaise idée, au moins parce que je peux obtenir une désynchronisation par rapport à master / msdb / etc.

IDEA 2: orchestrez une sauvegarde et une synchronisation-restauration complexes sur toutes les bases de données

Cela me demande des bases de données exigeantes exécutées en récupération complète, ce que je ne veux pas. Lancez des sauvegardes parallèles pour toutes les bases de données bien avant la date limite (T0). Une fois T0 atteint, sauvegardez tous les journaux (cela devrait prendre au plus quelques minutes). Prenez la myriade de sauvegardes qui en résulte et essayez de les restaurer et de faire défiler les journaux vers l'avant / l'arrière pour obtenir un état quelque peu cohérent entre les bases de données, par rapport à T0.
Cela nécessite beaucoup de planification et de script pour l'utiliser de manière fiable, donc je ferais tout mon possible pour l'éviter.

Suis-je en train de manquer une autre solution?

PS1: J'aurais adoré pouvoir utiliser des instantanés db . L'idée était de lancer un instantané sur chaque base de données (qui devrait se terminer en quelques secondes), puis de sauvegarder intégralement chacune de manière séquentielle au cours des minutes / heures suivantes. Ensuite, restaurez-les tous sur un serveur différent et restaurez chacun sur l'instantané. AFAIK ce scénario n'est pas possible car les instantanés ne peuvent pas être sauvegardés avec la base de données. Ils ne peuvent être restaurés que sur le serveur où ils ont été créés. De plus, ils nécessitent Enterprise Edition que je n'ai pas pour tous les clients.

PS2: Si vous connaissez une solution tierce capable de produire des sauvegardes synchronisées cross-db, veuillez la mentionner.

J'ai besoin de sauvegarder 10 à 20 bases de données SQL Server utilisées simultanément par une seule application d'entreprise, alors qu'elles sont en ligne, de manière à les restaurer dans un état largement synchronisé sur toutes les bases de données

Ce que vous recherchez est une sauvegarde cohérente dans toutes vos bases de données clients, vous devez utiliser des sauvegardes complètes avec Marked Transactions(accentuation en gras ajoutée):

Lorsque vous effectuez des mises à jour associées à deux bases de données ou plus, des bases de données associées , vous pouvez utiliser des marques de transaction pour les récupérer à un point logique cohérent . Toutefois, cette récupération perd toute transaction qui est validée après la marque qui a été utilisée comme point de récupération. Le marquage des transactions ne convient que lorsque vous testez des bases de données connexes ou lorsque vous êtes prêt à perdre des transactions récemment validées.

Assurez-vous de prendre la sauvegarde ad hoc du journal des transactions avec COPY_ONLY, sinon votre récupération sera pénible, car toute sauvegarde ad hoc du journal des transactions sans COPY_ONLYinterrompra la chaîne de journaux. Par mesure de précaution, vous pouvez restreindre les utilisateurs à utiliser uniquement des COPY_ONLY sauvegardes .

J'ai besoin d'une solution pour les versions de SQL Server 2008 R2 et ultérieures. Les tailles de base de données peuvent atteindre 50 Go par base de données et le temps de sauvegarde de chacune d'entre elles est probablement supérieur à 1 à 2 heures.

Les transactions marquées fonctionneront pour votre situation. La seule chose à faire des sauvegardes parallèles est pour STRIPEeux, mais vous finissez par vous assurer que vous ne perdez pas vos bandes de sauvegarde. Pour les rendre plus rapides, vous pouvez jouer avec BUFFERCOUNTet MAXTRANSFERSIZE.

Vous devez utiliser la compression de sauvegarde et activer l'initialisation instantanée des fichiers .

Faire référence à

• Utilisation de transactions marquées (modèle de récupération complète)
• Comment augmenter la vitesse de sauvegarde complète de la base de données SQL à l'aide de la compression et des disques SSD?

Si vous exécutez des sauvegardes complètes ainsi que des sauvegardes du journal des transactions (et vous devriez si vous considérez ces données importantes), vous pouvez simplement copier les sauvegardes et les sauvegardes du journal des transactions sur le système de test et effectuer une restauration ponctuelle pour restaurer les bases de données dans + - en même temps.

Selon que toutes les bases de données résident sur la même machine SQL Server ou selon la synchronisation des horloges des serveurs, vous devriez être en mesure de correspondre à la cible de «quelques secondes de désynchronisation».

Cela peut être un peu une solution de pansement mais répondrait aux exigences et serait assez simple et peu coûteux.

Si vous ne disposez pas de sauvegardes complètes et de sauvegardes du journal des transactions de vos bases de données importantes (qui sont en pleine récupération), vous devez vraiment réviser votre stratégie de sauvegarde. Les instantanés au niveau du SAN évitent vraiment d'avoir une base de données en mode de récupération complète, car vous ne pourrez de toute façon pas effectuer de restauration à un point dans le temps.

Veuillez lire ce que MrDenny a à dire à ce sujet

Dans les circonstances que vous avez indiquées, avez-vous examiné les sauvegardes VSS via un fournisseur VSS tiers ou basé sur Microsoft? Vous pouvez effectuer une sauvegarde COPY_ONLY qui ne cassera pas votre chaîne de récupération de production et vous devriez vous retrouver avec une sauvegarde de toutes les bases de données que vous pouvez ensuite récupérer ailleurs dans vos marges raisonnables. Gardez à l'esprit qu'une sauvegarde VSS possède certains des mêmes mécanismes et défaillances que les instantanés de base de données dans la mesure où une base de données très active peut provoquer un problème d'espace disque en raison des fichiers épars utilisés. Jetez un œil aux ressources TechNet sur le service SQL Writer ici et aux sauvegardes VSS de SQL Server ici .

Pour ce faire via la sauvegarde de Windows Server, vous suivrez les étapes de l'assistant pour une sauvegarde manuelle en vous assurant de sélectionner la sauvegarde de copie VSS dans les paramètres de configuration personnalisés sous Paramètres VSS. Cela permettra à votre sauvegarde Windows Server de ne pas interférer avec les autres sauvegardes effectuées sur le serveur. Voir la référence de sauvegarde de Windows Server pour plus de détails.

Je voterai @ Kin's comme réponse car c'était la première correspondant à la question posée. J'ai fini par trouver une réponse supplémentaire et je vais la décrire ci-dessous.

Pour les clients utilisant un modèle de récupération simple, j'exigerai une copie des MDF et LDF extraits d'un instantané de disque temporaire pris à T0 au niveau de l'hyperviseur ou du SAN. Je peux les utiliser pour récupérer le dbs à l'état de T0.

Pour les clients utilisant un modèle de récupération complète, je demanderai:

• Copies de leur processus de sauvegarde PRINCIPAL de la dernière sauvegarde complète terminée avant T0 + chaîne minimale de sauvegardes ultérieures du journal des transactions couvrant T0. Je peux ensuite effectuer une récupération ponctuelle à T0.

• Accès pour effectuer mes propres COPY_ONLYsauvegardes auxiliaires . Je vais tous les démarrer en parallèle à T0, ce qui ne devrait pas prendre plus de quelques secondes et était ma principale préoccupation n ° 1. Ensuite, à la restauration, j'effectuerai une récupération ponctuelle sur FirstLSN à partir de chaque sauvegarde. La beauté de cela est qu'il ne nécessite pas du tout que j'interagisse avec le processus de sauvegarde MAIN, ce qui était mon autre préoccupation, ils peuvent même tronquer les journaux pendant que mes COPY_ONLYsauvegardes s'exécutent sans affecter leur cohérence.

Je le fais plusieurs fois par an pour le contrôle qualité et d'autres environnements qui sont des copies de production. Pour les restaurations, le mode de récupération complète est vraiment nécessaire et la restauration à un moment donné fonctionne bien. Il y a également beaucoup de réplication et il est rare que nous ayons des erreurs de «ligne non trouvée» après la restauration à un moment donné. Nous utilisons également la méthode SAN clone / snapshot pour une copie de production géographiquement éloignée et qui fonctionne également bien pour synchroniser les bases de données.