Discussion :

[taibag]

Bonjour à tous,

Quelle est la stratégie de sauvegarde et restauration pour une large base de données qui dépasse les 10 téra octet?

Merci.

[mikedavem]

Faire un backup full tous les soirs. Il fallait bien la sortir pour ce 1er avril

Pour répondre plus sérieusement à cette question, quelques axes à regarder et qui pourront certainement t'aider (il n'y a pas de réponse triviale ici):

Nature des données? Est-ce que tu as beaucoup de données froides ou d'archive dans cette base ? Est-ce que celles-ci ne peuvent pas être supprimées en fonction d'une rétention? Quelle est la part des données vraiment actives la dedans?

Si données d'archive et que la taille ne peut pas être réduit en conséquence, alors le partitioning + différents filegroup peuvent être envisagés pour faire du backup de filegroup. Les filegroup en RO n'auraient pas besoin d'être sauvegardés par la suite et une restauration partielle pourrait être effectuée pour accélérer la mise en ligne de la base (les archives pouvant être restaurées à posteriori)

Si pas vraiment de design avec données d'archives, tu peux analyser le schéma en posant les tables dans différents FGs par exemple pour paralléliser les accès lors du backup FULL.

Après il faut aussi commencer à jouer avec les options de performance qui peuvent être nécessaires dans ce cas (compression, MAXTRANSFERSIZE, BUFFERCOUNT etc ...)

Dans tous les cas il faudra également penser utiliser une stratégie FULL + DIFF (et éventuellement LOG si en FULL recovery). Il y a de grandes chances que le volume de données modifié entre 2 backups restent minime par rapport au volume global.

D'autres pourront certainement ajouter 2 ou 3 autres points en fonction de leur expérience sur le sujet ..

++

[SQLpro]

Comme le dite Mikedavem, tout dépend des données. Mais :
1) faire des sauvegardes partielles, par fichiers ou groupe de fichiers à des fréquences différentes
2) faire des sauvegardes différentielles, par fichiers ou groupe de fichiers à des fréquences différentes
3) si la base n'est pas en TDE, activer la compression des sauvegardes
4) parallélisée la sauvegarde sur plusieurs fichiers de destination
5) jouer (en testant) sur les paramètres MAXTRANSFERSIZE, BUFFERCOUNT comme le dit Mikedavem
6) faire des sauvegarde très régulières du journal de transactions pour toutes les bases en mode de récupération non simple (par exemple toutes les 10 minutes)
7) la destination doit avoir des disques RAPIDE en écriture. Donc, pas de RAID 5, 6, 50, 60, DP… et si possible du SSD en Write Intensive
8) si la sauvegarde est distante, passer par une fibre optique ou une liaison 100 Gbs
9) éventuellement jouer sur la taille des paquets (attention certaines requêtes peuvent en pâtir).

A +

[taibag]

Bonjour et merci à vous,

Oui la base de données est une DWH qui contient des images dans files Stream, et elle sensée en lecture seule, mais on doit la protéger quand même cotre une action de mise à jour intentionné ou par erreur, la plateforme est virtuelle avec VMware.

[Michel.Priori]

elle [est] sensée [être] en lecture seule,
mais on doit la protéger quand même cotre une action de mise à jour intentionné ou par erreur,
la plateforme est virtuelle avec VMware.

La première action serait de déclarer effectivement la base en lecture seule !
ALTER DATABASE [La_Base_De_Données] SET READ_ONLY

De fait il y a déjà beaucoup moins de risque contre les écritures mal intentionnées

Pour les campagnes de mise à jour, on replace la base en read_write puis on la remet en read_only.

Ce qui va suivre n'est valable que si on MAITRISE les bascules lecture/écriture de la base :
Voir avec la politique de snapshot VMware.
Si la programmation concorde avec la bascule "écriture -> lecture", si c'est la seule base raison d'être de la VM, si les snapshot sont jugés fiables, alors il est envisageable de se reposer exclusivement sur eux.
Attention cependant aux données contenues dans MASTER (comptes de connexion, ...) et MSDB (job, alerte, ...)
Imaginons que la dernière image ait 5 jours ; est-il acceptable de revenir à cette dernière ?

[SQLpro]

ATTENTION : les snapshot de VM effectué notamment par l'outil VEAM, ne sont pas compatible avec la haute disponibilité via AllwaysOn, à cause d'un bug du processus de snapshot non résolu qui fait basculer les clusters du fait du "freeze" des bases…

A +

[dari68]

Comme le dite Mikedavem, tout dépend des données. Mais :
1) faire des sauvegardes partielles, par fichiers ou groupe de fichiers à des fréquences différentes
2) faire des sauvegardes différentielles, par fichiers ou groupe de fichiers à des fréquences différentes
3) si la base n'est pas en TDE, activer la compression des sauvegardes
4) parallélisée la sauvegarde sur plusieurs fichiers de destination
5) jouer (en testant) sur les paramètres MAXTRANSFERSIZE, BUFFERCOUNT comme le dit Mikedavem
6) faire des sauvegarde très régulières du journal de transactions pour toutes les bases en mode de récupération non simple (par exemple toutes les 10 minutes)
7) la destination doit avoir des disques RAPIDE en écriture. Donc, pas de RAID 5, 6, 50, 60, DP… et si possible du SSD en Write Intensive
8) si la sauvegarde est distante, passer par une fibre optique ou une liaison 100 Gbs
9) éventuellement jouer sur la taille des paquets (attention certaines requêtes peuvent en pâtir).

A +

Bonjour,


si la base n'est pas en TDE, activer la compression des sauvegardes <= La compression n'est pas compatible avec TDE ...?

Merci.

A+

[Michel.Priori]

En général SQLpro ne dit pas des bêtises.

Voir ici : https://www.google.com/search?client...DE+compression

[SQLpro]

En général SQLpro ne dit pas des bêtises.

Voir ici : https://www.google.com/search?client...DE+compression

Ou ben là c'est pas gagné !!!!

Il m'arrive quand même d'en faire…. La preuve tu en as corrigé une sur l'atomisation…..

A +