Stratégie de sauvegarde SQL Server 2005

Question

Je gère une application Web pour un client avec les spécifications suivantes:

• ASP.net 3.5 s'exécutant sur un serveur Web Windows 2003 virtuel
• SQL Server Standard hébergeant la base de données
• Taille actuelle de la base de données de 6 Go, avec un taux de croissance de 1 Go / mois
• Une seule table est responsable de 98% de la taille et contient les données les plus critiques pour le client
• Le journal n'est pas conservé pour cette grande table, seules les sélections sont effectuées dans cette table
• 50 Go d’espace FTP disponible pour la sauvegarde

Compte tenu de ce scénario, quelle serait la meilleure stratégie pour une sauvegarde SQL et quel outil conviendrait le mieux à cette tâche (applications commerciales incluses, le client peut payer les frais de licence)?

Answer 1

Voici la stratégie que nous utilisons pour CodePlex.com:

• Tous les serveurs SQL exécutés avec un serveur homologue utilisant la mise en miroir SQL
• Sauvegarde hebdomadaire complète (stockée sur un lecteur distinct des bases de données)
• Sauvegarde différentielle quotidienne (stockée sur un lecteur distinct des bases de données)
• Sauvegarde du journal des transactions toutes les 5 minutes (stockée sur un lecteur distinct des bases de données)
• Sauvegarde quotidienne sur bande
• Sauvegardes sur bande effectuées hors site chaque semaine

Il est également très important de tester vos sauvegardes! Des études ont montré que plus de 30% des procédures de sauvegarde non testées sont erronées. Voici notre stratégie de test de sauvegarde:

• Toutes les 30 minutes, vérifiez que le fichier de sauvegarde complet existe (à l'aide d'une tâche planifiée)
• Toutes les 30 minutes, vérifiez que le fichier de sauvegarde différentielle existe (à l'aide d'une tâche planifiée)
• Toutes les 30 minutes, vérifiez que le fichier de sauvegarde du journal des transactions existe (à l'aide d'une tâche planifiée)
• Toutes les 30 minutes, vérifiez que la mise en miroir de la base de données est configurée (à l'aide d'une tâche planifiée)
• Chaque jour, effectuez une restauration test de la sauvegarde complète + différentielle et indiquez le nombre de lignes de la table (à l'aide de la tâche planifiée)
• Une fois par mois, effectuez un test de restauration de la dernière sauvegarde sur bande et vérifiez les données

Answer 2

Cela dépend de la gravité des données. Voici cependant comment je le ferais.  1. Exécutez une sauvegarde complète chaque jour.  2. Exécutez une sauvegarde différentielle toutes les 4 heures.  3. Exécutez une sauvegarde du journal transactionnel toutes les 15 minutes.  4. Conservez une copie sur le site et déplacez-en une copie dès que la sauvegarde est terminée.

La base de données n’est pas trop grosse et c’est faisable.

Utilisez un outil tiers tel que Redgate SQL Backup . va automatiquement compresser et chiffrer la sauvegarde de la base de données pour vous. Je l'ai beaucoup utilisé et je suis un grand fan.

En outre, si vous disposez d'un autre site disponible et que les données sont très critiques, vous pouvez également envisager de configurer l'envoi des journaux.

Answer 3

Ceci est un VPC? Pouvez-vous installer des applications?

http://www.jungledisk.com/

C’est ce que nous utilisons: créer un travail SQL qui envoie une sauvegarde tous les jours, puis utiliser ce service pour renvoyer une copie au service Amazons S3. Sinon, vous pourriez avoir une application locale qui récupère la sauvegarde sur une machine, puis la / le service Web S3, ou toujours avec Jungledisk.

Ceci est important! Si votre application tombe en panne, ça fait mal! Assurez-vous également de sauvegarder votre application déployée et les ressources stockées là-bas ... c.-à-d. Le contenu téléchargé dans le répertoire de stockage de votre application.

Answer 4

Je devais taper ma réponse à votre question, mais je me suis rendu compte qu’il existe de nombreuses ressources beaucoup plus importantes quelque part, comme cet article dans SQLServerCentral.com . Vous pouvez également trouver de nombreuses "meilleures pratiques de sauvegarde". comme celui-ci .

Answer 5

Vous pouvez également prendre en compte la quantité de données que vous pouvez vous permettre de perdre et le temps qu'il vous faudra pour restaurer la base de données. Votre client peut décider de ne jamais perdre plus de 15 minutes de données, ou de perdre jusqu'à quelques jours de données, ce qui est acceptable pour lui.