Sauvegarde SQL DB plus fréquente

10

J'ai actuellement une tâche planifiée qui se déclenche chaque nuit à 2 heures du matin qui appelle SQLCMD.exe et lui transmet un script .sql à exécuter pour la sauvegarde (illustré ci-dessous). Nous sommes une assez petite entreprise avec des besoins croissants en raison d'une croissance importante du côté des affaires. Perdre 1 jour de données à ce stade coûterait des dizaines de milliers de dollars contre quelques centaines l'année dernière. Jusqu'à ce que je puisse migrer cette plate-forme de base de données vers une autre solution où la mise en miroir des données se produit avec une redondance majeure comme SQL Azure, quelle est la meilleure chose que je puisse faire pour obtenir des sauvegardes plus fréquentes? Ce script ci-dessous force-t-il la base de données à être hors ligne? Puis-je exécuter ce script avec des utilisateurs interagissant avec la base de données?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Mettre à jour

Wow, évidemment une communauté DBA beaucoup plus dédiée ici que sur SO. Merci pour le retour jusqu'à présent. La seule chose qui manque est le «comment». J'ai montré la commande SQL ci-dessus que j'utilise pour effectuer des sauvegardes quotidiennes, mais les exemples de sauvegarde de journal incrémentielle sont MIA. Ce n'est pas une grande base de données, il fonctionne actuellement sur SQLExpress. Quand je dis HA ou SQL Azure, je fais spécifiquement référence à l'architecture en place que nous n'avons pas en tant que petite entreprise. Cette instance s'exécute actuellement sur notre SEUL serveur. Si ce serveur tombe en panne, notre temps de récupération devient un point critique. C'est pourquoi SQL Azure devient attrayant.

RSolberg
la source
modifié ma réponse à votre mise à jour, j'espère que cela aide

Réponses:

5

EDIT, à partir de votre mise à jour

Comme vous avez dit que vous pouvez perdre 1 jour de données, je mettrais simplement les bases de données en mode de récupération SIMPLE. Vous pouvez ensuite faire un COMPLET chaque matin et / ou soir. Si vous vouliez vous couvrir pendant la journée, vous pourriez effectuer une sauvegarde différentielle de la base de données, une de ces situations au cas où. Cela capturera toutes les modifications apportées depuis la sauvegarde complète. Si je connais un laps de temps où de nombreuses entrées se produisent, je pourrais lancer ce type de sauvegarde une fois terminé. Cela peut faire gagner du temps aux gens pour récupérer afin qu'ils n'aient pas à faire de saisie de données supplémentaires.

Puisque c'est votre seul serveur, je m'assurerais que vous exécutez DBCC CHECKDB sur les bases de données. Les sauvegardes ne servent à rien lorsque vous découvrez qu'elles sont corrompues (je pense que quelqu'un l'a également mentionné). Vous pouvez probablement trouver quelques scripts pour configurer une tâche planifiée afin de vérifier le SQL ERRORLOG pour le message DBCC afin de détecter toute erreur. SQL Server ne vous avertira pas nativement des erreurs renvoyées par les messages DBCC, donc à moins que vous ne vérifiiez manuellement chaque fois qu'un script qui le fait peut vous aider.

La commande de sauvegarde différentielle:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

la source
1
@Shawn: OP a déclaré que "perdre 1 jour de données à ce stade coûterait des dizaines de milliers de dollars contre quelques centaines cette fois l'an dernier", où a-t-il dit qu'il pouvait perdre 1 jour de données?!
Marian
8
  • Les sauvegardes dans SQL Server ne perturbent pas. C'est-à-dire que la base de données reste opérationnelle. Lisez la documentation.
  • Effectuez une sauvegarde complète tous les jours, suivie par des sauvegardes LOG (copiées) expédiées (encore une fois, la documentation contient ... de la documentation) plus régulièrement - comme toutes les 15 minutes environ.
TomTom
la source
4
Je pense que la sauvegarde est quelque chose pour laquelle vous n'avez pas besoin d'un guide, mais une lecture complète de la documentation - elle est critique pour l'entreprise ET elle est - sérieusement - importante. Ne pas faire cuire des œufs. Embauchez un pro.
TomTom
2
Dommage que je ne puisse pas voter contre les réponses sur ce site ...
RSolberg
1
@RSolberg: La réponse de TomTom est valide, avec les autres conseils que vous avez déjà reçus. Je dirais que vous ne vous attendez pas à ce que l'un des répondants vous montre vraiment la syntaxe de base de la sauvegarde. Même si je vois que Shawn a eu la gentillesse de le faire. Concevoir une stratégie de SAUVEGARDE ne suffit pas. Vous devez le coupler avec une stratégie RESTORE afin que tout soit valide lorsque vous en avez besoin.
Marian
2
@RSolberg: désolé de vous énerver. Ce n'est pas prévu. Mais comment cette communauté n'a-t-elle pas aidé? Vous avez de bonnes réponses (et commentaires) valides. Votre propre message était: "Perdre 1 jour de données à ce stade coûterait des dizaines de milliers de dollars contre quelques centaines cette fois l'an dernier." Vous avez donc besoin d'une solide stratégie de sauvegarde et de restauration pour ne pas y arriver. Une stratégie solide vient de connaître très bien les bases. Qui viennent de la lecture et de la compréhension du manuel. Désolé si vous avez compris autre chose!
Marian
2
Je suis d'accord avec @RSolberg que la plupart des réponses ici ne montrent pas "comment" le faire, mais c'est aussi parce que la question manquait en détail de "quoi" vous n'avez pas compris Russell. Vous devez nous en dire un peu plus sur ce dont vous avez besoin, mais je suis d'accord avec vous que le site ici n'est pas censé être sur "RTFM n00b". En outre, comme vous l'avez souligné, vous disposez de 10k sur Stack Overflow , vous comprenez donc sûrement les commentaires marquants qui sont impolis ou perturbateurs. À l'avenir, vous devriez le faire plus tôt, plutôt que de déborder de frustration.
jcolebrand
6

La première chose que vous devez faire est de déterminer la quantité de données que vous pouvez vous permettre de perdre. Jusque-là, vous n'aurez aucune idée de la fréquence de sauvegarde de la base de données. Ce n'est pas un nombre que vous devriez trouver. C'est quelque chose que l'entreprise (ou le PDG d'une petite entreprise) devrait décider. Le premier numéro avec lequel ils vont revenir est 0 minute. Ce qui peut être fait, mais cela coûtera très cher. En réalité, la plus petite quantité de données pour laquelle vous pouvez effectuer des sauvegardes est d'environ toutes les 2 minutes. Si la quantité de données changeant dans le système est suffisamment petite, vous pouvez effectuer des sauvegardes toutes les minutes.

Pour effectuer des sauvegardes du journal des transactions, ce que vous devrez faire, vous devrez mettre la base de données en mode de récupération complète.

Si vous pouvez vous permettre de perdre 5 minutes de données, vous voudrez probablement effectuer des sauvegardes complètes quotidiennement et des sauvegardes du journal des transactions toutes les 5 minutes. Si vous pouvez perdre 15 minutes de données, vous voudrez effectuer des sauvegardes complètes et des sauvegardes du journal des transactions toutes les 15 minutes.

Une autre option serait de faire des sauvegardes complètes hebdomadaires, des sauvegardes différentielles quotidiennes et des sauvegardes du journal des transactions toutes les x minutes comme je le dis ci-dessus.

Gardez à l'esprit que plus vous devrez effectuer de sauvegardes fréquemment, plus vous devrez restaurer de fichiers en cas de défaillance de la base de données ou de suppression des données. Il peut être judicieux d'effectuer des sauvegardes différentielles tout au long de la journée pour raccourcir le temps nécessaire à la restauration de la base de données.

Toutes les sauvegardes qui utilisant la base de données BACKUP et l'instruction BACKUP LOG sont effectuées en ligne et n'empêchent pas les utilisateurs d'accéder à la base de données.

mrdenny
la source
Je suis en fait tout à fait capable d'évaluer la quantité de données que nous pouvons perdre. Les petites entreprises exigent que les gens portent de nombreux chapeaux, car le DSI I a tendance à s'impliquer quotidiennement dans les décisions relatives à son secteur d'activité.
RSolberg
1
Cela raccourcira alors la discussion.
mrdenny
3

Disons que vous avez un scénario commercial commun avec votre période la plus occupée: 9h-17h du lundi au vendredi. Ensuite, je suggérerais: une sauvegarde complète le dimanche soir. Sauvegardes différentielles à 8 h, 18 h et 1 h (pour réduire le temps de récupération). Enregistrez les sauvegardes toutes les heures ou en fonction des besoins de votre entreprise.

Selon votre période de rétention, vous devriez avoir un travail de nettoyage automatique pour effacer les anciens fichiers de sauvegarde. Tous ces éléments peuvent être créés à l'aide de plans de maintenance SQL. Vérifiez ce lien pour SQL 2005 .

Vous devez stocker vos sauvegardes sur une certaine forme de disque redondant (en miroir), ou vous pouvez utiliser des bandes pour le stockage hors site. Les utilisateurs peuvent continuer à travailler sur le système pendant l'exécution des sauvegardes.

StanleyJohns
la source
2

Je ne ferais pas de sauvegarde complète tous les soirs. S'il s'agit d'une grande base de données, cela pourrait prendre très longtemps, sans parler de prendre beaucoup de place sur les médias. Effectuez une sauvegarde complète chaque week-end et une sauvegarde différentielle tous les soirs. Effectuez ensuite une sauvegarde du journal des transactions (en supposant que votre base de données est en pleine récupération) toutes les heures ou toutes les demi-heures, mais assurez-vous que ces fichiers .bak et .trn résident sur un disque distinct en cas de défaillance du disque.

Thomas Stringer
la source
Les balises ont été perdues, ce n'est pas une énorme base de données. Il s'exécute actuellement sur une instance SQLExpress.
RSolberg
1
Des dizaines de milliers de dollars, fonctionnant sur Express? Intéressant!
Andrei Rînea
Pas vraiment. Selon ce que vous stockez (pas de textes, pas de binaires) - soit 10 gigaoctets de données. Vous pouvez exécuter un système comptable pour une grande entreprise - GRAVEMENT grande entreprise - en 10 gigaoctets. Une boutique en ligne avec 100 000 commandes par jour peut facilement faire le côté boutique en 10 gigaoctets.
TomTom
1

Pouvez-vous synchroniser votre dossier de sauvegardes dans le cloud la nuit pour obtenir un stockage hors site? Étant donné que je suis sûr que c'est pour une entreprise de soins de santé, y en a-t-il qui sont suffisamment sécurisés pour la conformité HiPA? Ou peut-être simplement les super-crypter?

Le script place-t-il au moins une copie de la sauvegarde sur un partage réseau? De cette façon, si la boîte physique explose ...


la source
Oui à tout ce qui précède. En fait, nous sauvegardons sur un lecteur réseau en miroir et nous copions les données de cet environnement vers un centre de données sécurisé.
RSolberg