Existe-t-il un moyen de réduire le temps consacré à une récupération ponctuelle?
Je suis à peu près sûr de connaître la réponse à cette question, mais les limites d'une récupération à un moment donné m'époustouflent.
Supposons que j'ai une base de données de 2 To définie sur le mode de récupération FULL. Je prends avec diligence des sauvegardes complètes hebdomadaires, des sauvegardes différentielles quotidiennes et des sauvegardes de journaux toutes les 30 minutes.
Maintenant, je veux restaurer la base de données il y a 1 heure. Dois-je vraiment restaurer l'intégralité de la sauvegarde complète, des différences et des journaux il y a une heure? Ai-je raison de dire que cela prendra très longtemps?
N'existe-t-il aucun moyen de ROLLBACK les modifications à l'aide des fichiers journaux des transactions afin que ce type de récupération prenne quelques minutes?
Oui, vous devez restaurer la sauvegarde complète, au maximum une sauvegarde diff et toutes les sauvegardes de journaux nécessaires pour effectuer une récupération ponctuelle dans SQL Server. Dans SQL Server, vous ne pouvez pas restaurer des transactions déjà validées pour remonter dans le temps. Vous voudrez probablement utiliser la syntaxe STOPAT pour restaurer votre base de données à la position exacte souhaitée point dans le temps .
En fait, étant donné que vous effectuez des sauvegardes du journal des transactions toutes les 30 minutes, SQL Server efface également le journal des transactions à chaque sauvegarde du journal - donc pour revenir à une heure avant, SQL Server n'aurait même pas les informations nécessaires pour rouler revenir aussi loin, même si SQL Server avait une telle fonctionnalité (ce qui n'est pas le cas, malheureusement).
Je ne peux pas vous dire si cela prendrait "très longtemps" car le temps de restauration varie beaucoup en fonction de la taille de la base de données, du nombre de modifications contenues dans les sauvegardes de journaux/différences et du nombre de sauvegardes de journaux qui doivent être restauré. Pour une petite base de données qui n'est pas très occupée, la restauration peut être assez rapide, mais pour une base de données multi-téraoctets très occupée, cela peut prendre un certain temps.
Oracle a une fonctionnalité appelée Flashback qui vous permettra de faire ce que vous décrivez, mais SQL Server n'a pas de fonctionnalité équivalente.
Vous pouvez examiner l'utilisation de la fonction instantané de SQL Server selon votre cas d'utilisation. J'utilise la fonctionnalité avant d'exécuter des déploiements de production et dans des environnements non Prod lorsque je souhaite réinitialiser une base de données pour qu'elle corresponde à des conditions de démarrage de test spécifiques. Puisqu'il utilise des fichiers clairsemés, ne copie que les pages modifiées pour maintenir l'instantané et vous permet de conserver 1+ instantanés pour des points spécifiques dans le temps, ils peuvent être très efficaces, en particulier lors du suivi des changements infimes dans un paramètre VLDB. Une chose à surveiller est la quantité de pages modifiées car elles augmenteront la taille des fichiers clairsemés en conséquence et une panne peut se produire si vous manquez d'espace où se trouvent les fichiers clairsemés.
Oui en bref.
Vous devrez restaurer la dernière sauvegarde complète, la dernière sauvegarde différentielle et toutes les sauvegardes de journal depuis la dernière sauvegarde différentielle.
C'est la raison pour laquelle lorsqu'une base de données devient trop volumineuse, nous demandons généralement à l'équipe de développement de purger les anciennes données (plus anciennes que la période de conservation). Parfois, vous n'avez pas la possibilité de purger et devez y faire face.
Pour être mieux préparé, faites toujours un exercice de récupération de la base de données dans votre environnement de test, cela vous donnera une estimation approximative. Suite à l'estimation, un RTO peut être convenu.
Il y a quelques bonnes réponses 1 & 2 pourquoi vous ne pouvez pas simplement annuler. Dans la réponse de @AMtwo, il est question de la vitesse de récupération. Je voulais développer un peu cela et répondre à la question dans votre titre.
La récupération ponctuelle d'un serveur SQL prend-elle autant de temps qu'une récupération complète?
Étant donné que vous devez restaurer la sauvegarde complète et au moins un t-log pour une récupération ponctuelle (PIT), un PIT prendra toujours au moins aussi longtemps qu'une récupération complète.
Les sauvegardes différentielles sont généralement prises pour économiser de l'espace où vous stockez vos sauvegardes. S'il n'y a pas beaucoup de changements dans votre système, ceux-ci sont normalement beaucoup plus petits qu'une sauvegarde complète. Une seule sauvegarde complète, avec 6 différentiels et une semaine de t-logs prend normalement beaucoup moins d'espace que 7 sauvegardes complètes plus les t-logs.
Une sauvegarde différentielle capture uniquement les données qui ont changé depuis cette sauvegarde complète. Source
Un différentiel nécessite absolument une sauvegarde complète, pour être restauré en premier.
Si vous le souhaitez, vous pouvez ignorer le différentiel, restaurer la sauvegarde complète et toutes les sauvegardes t-log jusqu'à ce que votre PIT avec
stopatJe fais des tests de sauvegarde réguliers, et l'un des gros obstacles est le moment de déplacer l'ancienne sauvegarde de son emplacement sûr ( bande, stockage hors site, etc.) vers le serveur. Cela varie selon votre conception. Seule votre entreprise peut savoir quelle heure il est.
Une fois les sauvegardes sur le serveur, elles seront restaurées; En fin de compte, la différence de temps de récupération entre le plein et le PIT varie en fonction de l'ampleur des changements.
Dans mon expérience avec des centaines de restaurations PIT, le temps supplémentaire pour PIT sur un plein est mineur, quelques secondes ou une minute. Si vous placez le Full, le Differential et tous les t-logs dans un seul dossier, et utilisez l'interface graphique pour la restauration (SQL 2012+), sélectionnez-les tous et il les triera automatiquement et restaurez dans votre PIT, sans trop difficulté ou temps supplémentaire.
TL: DR Autre que quelques variables spécifiques à votre entreprise et à votre conception. une restauration ponctuelle du serveur prend à peu près le même temps qu'une restauration complète.
Il n'y a aucune garantie que les transactions précédentes seront toujours dans le journal des transactions actif, surtout si vous avez des sauvegardes toutes les 30 minutes. Malheureusement, vous devrez restaurer le dernier complet, suivi du dernier différentiel, puis de toutes les sauvegardes du journal des transactions effectuées depuis ce différentiel.