Quelle est la meilleure stratégie de sauvegarde SQL Server pour les grandes bases de données avec peu de tables et beaucoup de données immuables?
Nous avons une grande base de données (500 Go et en expansion). 95% + des données sont stockées dans 3 tables (une table a 2 milliards + lignes). Les données sont en grande partie immuables - c'est-à-dire qu'une fois ajoutées, elles ne sont lues qu'après. Nous ne pouvons pas archiver les anciennes données.
Nous utilisons SQL Server 2017 qui permet des sauvegardes compressées, mais même dans ce cas, la sauvegarde et la copie sur le serveur vers le serveur prennent beaucoup de temps.
Nous aimerions accélérer ce processus (et à des fins de reprise après sinistre, avoir les sauvegardes dans le cloud - probablement Azure) - Les sauvegardes différentielles sont assez petites, mais je pense que nous aurions encore besoin de prendre régulièrement des sauvegardes complètes (par exemple complètes chaque week-end et différentiel chaque nuit est toujours un problème pour nous)
Mon sentiment est d'utiliser le partitionnement pour diviser les grandes tables sur une colonne sensible (groupée sur l'ID d'identité), puis nous pouvons sauvegarder les anciennes partitions une seule fois et les marquer comme en lecture seule et pas besoin de tout sauvegarder à nouveau.
Ce n'est pas une situation idéale car nous allons devoir continuer à ajouter plus de partitions à l'avenir. De plus, la base de données ne peut pas être supprimée pendant plus de quelques minutes, donc je pense que je vais devoir faire une version fantôme des données avec les partitions, puis faire un basculement afin de réduire les temps d'arrêt, ce qui est un peu risqué et compliqué.
Si quelqu'un a des stratégies de sauvegarde pour ce type de configuration de base de données qui, selon lui, fonctionneraient mieux (ou peuvent confirmer que cela semble être une bonne idée compte tenu des contraintes que j'ai), je serais heureux d'entendre :)
Informations supplémentaires:
Calendrier de sauvegarde actuel:
Sauvegarde complète (tous les soirs) - les sauvegardes compressées sont d'environ 100 Go (500 Go non compressés) et prennent environ 40 minutes ( avec compression)
Sauvegardes des journaux (toutes les 10 minutes) - Presque instantané et seulement environ 20 Mo chacune.
Maintenant, je sais que, pour certains, 40 minutes ne sont pas très longues et que 100 Go ne sont pas un fichier très volumineux, mais je sais également que, étant donné que 95% + des données sont immuables et ne peuvent être sauvegardées en toute sécurité qu'une seule fois , les sauvegardes pourraient prennent moins de quelques minutes et représentent quelques gigaoctets (et c'est prudent).
Je crois que partitionnement est l'un des outils utilisés pour aider à gérer les sauvegardes et spécifiquement pour ce type de scénario, et j'espère avoir quelqu'un avec une expérience du monde réel avec cela (ou SQL Alternatives basées sur le serveur pour mon scénario) pour faire la lumière sur ce qui fonctionne pour eux.
Je pense que vous devriez examiner envoi de journaux une fois que vous l'avez configuré, vos journaux de 10 minutes peuvent être envoyés au serveur, donc seules les modifications sont mises à jour.
En supposant que la destination d'envoi des journaux est également l'endroit où vous souhaitez conserver vos sauvegardes, vous pouvez y effectuer des sauvegardes. Autre que la sauvegarde initiale, vous pouvez exécuter pendant des années et expédier uniquement les journaux.
Vous pouvez effectuer des sauvegardes complètes à votre destination principale et d'envoi de journaux. De cette façon, vous auriez des sauvegardes dans les deux emplacements, et vos seules données qui se déplacent quotidiennement sont les journaux expédiés.
Alternativement, vous pouvez utiliser AlwaysOn au lieu de l'envoi des journaux pour le même effet.
Licence: je ne suis pas un expert en matière de licence, mais je crois comprendre que si l'instance de destination de l'envoi de journaux (ou AlwaysOn) est uniquement destinée à la reprise après sinistre, il n'y a aucun coût supplémentaire.
Je vais écrire une réponse, mais cela dépend vraiment de l'infrastructure dont vous disposez, ou vous pouvez vous permettre:
- Pourquoi conserver les données en lecture seule et les transactions dans une seule base de données? Peut-être que les données en lecture seule doivent se trouver sur un ensemble distinct de fichiers/base de données/disque/serveurs. Je ne crois pas que vous lisez en permanence un fichier de données de 500 Go tout le temps et partout. La séparation vous donne la possibilité de sauvegarder uniquement cette partie qui est modifiée. Il peut s'agir d'une sauvegarde en tant que réplication vers un serveur de base de données distinct.
- Vous pouvez rechercher la déduplication des données en relation avec les protocoles de boost de données. Cela signifie que quelque chose (agent logiciel) pendant la sauvegarde compare les données modifiées et déplace uniquement la partie modifiée (comme dans la sauvegarde différentielle). La différence est que sur le stockage dédupliqué, ces systèmes peuvent construire hors ligne synthétique sauvegarde complète. Même si cela nécessite des rdbms effectuant une sauvegarde complète classique, le transfert des données n'est qu'une différence. En fonction de divers facteurs, vous pouvez en conséquence obtenir une sauvegarde complète beaucoup plus rapide.
- Vous pouvez rechercher la technologie d'instantané de divers fournisseurs. Certaines de ces solutions sont capables d'effectuer des instantanés cohérents pour divers rdbms de base de données. Il peut s'agir d'une solution entièrement certifiée.
À la fin, est allé pour l'option de partitionnement:
Partitionné les principaux tableaux "data" (avec 95% de données), traçant la ligne "archive/lecture seule" il y a 6 mois.
Le sous-produit était que les tables tertiaires (5% de données) étaient dans leur propre partition et pouvaient être restaurées indépendamment (utile pour ces messups de métadonnées!)
Utilisera également Log-shipping pour DR, mais comme il nécessite des licences supplémentaires pour pouvoir supprimer les sauvegardes secondaires, il nous reste encore des sauvegardes locales.
Expérimentez également avec Microsoft Azure Backup Server pour ajouter des avantages hors site supplémentaires.
La meilleure stratégie dépend de votre objectif RPO-Recovery Point, ainsi que du RTO - Recovery Time Objective aka à quelle vitesse devez-vous le restaurer ainsi que de la quantité de données que vous êtes autorisé à perdre .
Vous pouvez en fait diviser une base de données en groupes de fichiers qui ont des SLA différents où 1 table est sauvegardée plus fréquemment que d'autres. De plus, lorsque vous travaillez avec de grandes bases de données (nous avons celles qui font plusieurs To), vous ne pouvez pas sauvegarder une base de données entière car la sauvegarde elle-même prendra plus de temps que celle que votre infrastructure peut supporter ... une sauvegarde quotidienne échouera si la sauvegarde jusqu'à prend plus d'une journée ...
Nous avons généré un serveur de contrôle qui possède toutes les bases de données de l'organisation ainsi que leur RTO et SLA et exécutons une sauvegarde en fonction de la quantité de données modifiées ainsi que des derniers serveurs connus IO données.
Ce que nous faisons, c'est que nous avons écrit les scripts de restauration dans un travail SQL sur le serveur donné et que le pool de travaux contient le journal des transactions et mesure les modifications. lorsque nous effectuons une sauvegarde, nous générons un script de restauration (localement et à distance) et chaque fois que nous avons un changement dans RTO/RPO/SLA, nous mettons à jour le serveur. Si nous avons besoin de récupérer (serveur sur place ou remplaçable à chaud/de récupération), nous exécutons le script de récupération qui obtient les sauvegardes appropriées complètes, différentielles et transactionnelles pour un point dans le temps ou une récupération simple.
Nous avons de nombreuses bases de données pour toute autre approche, nous devons également avoir une exposition financière élevée si nous faisons des choses "manuellement". DBA 1 et DBA 2 peuvent également faire les choses différemment. Comment pouvez-vous implémenter systématiquement quelque chose sur "tous" les serveurs lorsque vous obtenez une mise à jour de sécurité ou pire .. nouvelle idée dans la gestion ...
J'ai ... il y a longtemps écrit un concept qui résout ce problème, il contient également des scripts qui fonctionneront probablement encore lors du changement de chemin, mais il suppose que les sauvegardes sont protégées par mot de passe, vous devrez peut-être supprimer cela car les versions ultérieures de SQL Server ont supprimé ce support.
Les scripts intégrés sous forme de fichiers .SQL à la fin du document.