Lorsque vous effectuez des sauvegardes à partir de bases de données, est-ce une "bonne pratique" d'utiliser un périphérique de sauvegarde logique pour l'emplacement de sauvegarde? Quel est l'avantage d'utiliser des périphériques de sauvegarde?
Imaginez que vous ayez beaucoup de jobs de sauvegarde. Sauvegardes complètes, sauvegardes différentielles, sauvegardes du journal des transactions ... Imaginez maintenant que vous devez déplacer toutes vos sauvegardes du disque local vers le SAN. si vous utilisez des périphériques de sauvegarde, il vous suffit de recréer les périphériques avec des chemins d'accès au nouveau disque. Mais si vos scripts de sauvegarde sont écrits pour utiliser des chemins d'accès complets, vous devez réécrire chaque travail, chaque étape du travail pour modifier ces chemins.
Mais il peut y avoir un scénario où vous n'avez pas besoin d'utiliser les périphériques de sauvegarde, par exemple, lorsque vous utilisez un scénario personnalisé dans lequel vous modifiez dynamiquement le chemin de sauvegarde ou le nom de fichier (par exemple, en ajoutant la date / heure au dossier ou au nom de fichier).
Je préfère un fichier par sauvegarde
Je ne veux pas:
Si vous avez une base de données de taille TB, des partitions, des groupes de fichiers et que vous souhaitez effectuer des sauvegardes / restaurations partielles, ces problèmes sont multipliés. Dans une situation DR, je veux que tout soit simple et clair.
La plupart des (grandes et petites) boutiques dans lesquelles je suis allé font cela: il est plus simple de gérer les fichiers auto-descriptifs.
Le concept de «périphérique» remonte à Sybase, SQL Server 6.5 et versions antérieures. Ici, vous aviez aussi des périphériques de disque Des MDF et LDF séparés ont été introduits avec SQL Server 7
la source
Un périphérique de sauvegarde logique n'est qu'une abstraction du périphérique physique.
Cela simplifie la commutation entre les périphériques physiques, car vous pouvez modifier la définition de périphérique logique plutôt que d'avoir à modifier vos scripts de sauvegarde ou vos packages de maintenance.
la source
J'ai utilisé un périphérique de sauvegarde logique pour un système de génération de rapports où nous voulions effectuer plusieurs restaurations et ne voulions pas écrire le chemin complet. Nous pourrions facilement changer la définition du périphérique de vidage sans avoir à changer nos scripts.
Je crois que le même concept s'applique à l'utilisation d'un périphérique de vidage logique pour les sauvegardes sur bande, bien que nous n'ayons jamais effectué de vidage directement sur bande.
Ce sont les seuls avantages que je connaisse actuellement.
la source
Bien qu'ils aient leurs utilisations, je préfère m'en tenir à une sauvegarde complète, différentielle ou de journal des transactions par fichier, car cela facilite l'exécution de scripts de nettoyage pour supprimer les anciennes sauvegardes et empêcher les lecteurs de sauvegarde de se remplir.
la source
À ma connaissance, les avantages de l'utilisation d'un périphérique de sauvegarde sont la simplification des scripts, ce qui facilite, si vous devez déplacer des lecteurs ou des périphériques et, le plus utile, à mon avis; être en mesure d'avoir un script de sauvegarde uniforme sur plusieurs serveurs où l'emplacement de sauvegarde peut être défini sur une base serveur par serveur, mais le périphérique de sauvegarde peut rester le même sur tous les serveurs. Par exemple, "Primary_Backup_Location".
la source
Outre ce qui a déjà été écrit ci-dessus, la seule autre raison pour laquelle je pourrais voir utiliser des périphériques de sauvegarde est si vous êtes limité en espace. Si vous disposez d'une base de données de 100 Go et de 2 disques avec chacun 60 Go d'espace libre, vous pouvez créer un périphérique de sauvegarde sur chaque disque et effectuer une sauvegarde sur les deux. La mise en garde est que vous devez ensuite restaurer les deux appareils.
-chris
- bien sûr, vous pouvez également écrire sur plusieurs fichiers de sauvegarde au lieu des périphériques ..
la source