Nettoyage d'un backup différentiel

Version imprimable

Voir 40 message(s) de cette discussion en une page

25/04/2019, 21h54
Michel.Priori

Citation:

Envoyé par cestpasmoinonplus

nous avons besoin de minimiser au maximum le temps d'exécution de la sauvegarde.
[...] une full une fois par semaine, avec des diff toutes les heures

Pour le coup je ne comprends pas la relation de cause à effet :weird:

Déjà, je ne comprends pas l'imposition "de minimiser au maximum le temps de sauvegarde".
Pourquoi cela ???
Fenêtre de disponibilité des bandes de backup ?

Ensuite, en quoi une différentielle serait plus rapide que la sauvegardes des log ???
Sur quels tests ça été établi ?
26/04/2019, 13h43
hmira

Citation:

Envoyé par cestpasmoinonplus

C'est une très bonne idée pour nous, en tout cas, car nous avons besoin de minimiser au maximum le temps d'exécution de la sauvegarde.
Après, il suffit de choisir le bon moment d'exécuter une full. Dans notre cas, une fois par semaine, avec des diff toutes les heures, en ne gardant que les cinq dernières diff, ça devrait le faire.

Bonjour,

Un full par semaine et des diff toutes le heures me parait une très mauvaise idée, compte tenu du fait que chaque diff embarque tous les changements qui ont eu lieu depuis le dernier full ! Par conséquent, les derniers jours de la semaine (exemple jeudi et vendredi), vous allez sauvegarder presque la totalité de la base, et ce, toutes les heures !!!

Ces fréquences de sauvegarde ne me paraissent pas appropriées.

A+
26/04/2019, 14h42
SQLpro

Citation:

Envoyé par Michel.Priori

….la doc indique : https://docs.microsoft.com/fr-fr/sql...ql-server-2017
Ce qui n'est pas le cas !

As-tu un scénario de test qui met ça en œuvre ?

Le seul cas que j'ai rencontré pour lequel on a perdu les fichiers de données est consécutif à un SAN avec cache en écriture ayant une batterie défaillante et pour lequel quelqu'un à stupidement débranché les cartes HBA…

Mais même en cas de crash système j'ai jamais vu les fichiers de données foirés.

A +
29/04/2019, 10h55
cestpasmoinonplus

Citation:

Envoyé par hmira

Par conséquent, les derniers jours de la semaine (exemple jeudi et vendredi), vous allez sauvegarder presque la totalité de la base, et ce, toutes les heures !

Tout à fait. Du coup j'ai automatisé la suppression des premières diff. Je n'en garde que 48, plus la full.
Le temps de backup de la dernière diff de la semaine est acceptable pour nous.

Citation:

Envoyé par hmira

Ces fréquences de sauvegarde ne me paraissent pas appropriées.

Mais par rapport à quoi ou à qui ?!
29/04/2019, 11h00
cestpasmoinonplus

Citation:

Envoyé par Michel.Priori

Déjà, je ne comprends pas l'imposition "de minimiser au maximum le temps de sauvegarde".
Pourquoi cela ?

Pour minimiser les freeze sur les écritures. Nous écrivons chaque seconde dans plusieurs tables. Les backup font freezer les écritures.

Citation:

Envoyé par Michel.Priori

Ensuite, en quoi une différentielle serait plus rapide que la sauvegardes des log ???
Sur quels tests ça été établi ?

Alors là, aucune idée :?
29/04/2019, 13h24
StringBuilder

Citation:

Envoyé par cestpasmoinonplus

Pour minimiser les freeze sur les écritures. Nous écrivons chaque seconde dans plusieurs tables. Les backup font freezer les écritures.

Première fois que j'entends parler de ça.
Mes backups (FULL) tournent régulièrement en pleine journée (rotation horaire), et je n'ai jamais remarqué le moindre impact : les utilisateurs ne se plaignent d'aucun ralentissement les jours où le backup tourne en plein jour.
Quant aux backups LOG, c'est justement l'avantage : ils ne touchent pas aux fichiers de données, donc aucune chance que ça impacte quoi que ce soit niveau performances...
29/04/2019, 14h09
cestpasmoinonplus

Citation:

Envoyé par StringBuilder

Première fois que j'entends parler de ça.

Comme quoi... :mrgreen:

Citation:

Envoyé par StringBuilder

les utilisateurs ne se plaignent d'aucun ralentissement les jours où le backup tourne en plein jour.

Rien de surprenant, je ne vois pas pourquoi ça toucherait aux performances 8O.
29/04/2019, 14h21
Invité

Citation:

Envoyé par cestpasmoinonplus

Pour minimiser les freeze sur les écritures. Nous écrivons chaque seconde dans plusieurs tables. Les backup font freezer les écritures.

Alors là, il faudrait peut-être plus voir du côté infra et l’organisation des fichiers : ça ressemble à des disques par particulièrement rapides avec tous les fichiers de data / log / backup qui grattent dessus.
Ajoute deux trois applications gourmandes sur le même serveurs...

J'ai déjà vu des backups avoir un léger impact sur des machines de dev par particulièrement performantes avec des disques quasiment plein mais sur une prod digne de ce nom, non !
29/04/2019, 21h31
janlouk

Citation:

Envoyé par cestpasmoinonplus

Alors là, aucune idée :?

Tu ne fais aucun backup log ? Toutes tes DB sont en SIMPLE alors?
29/04/2019, 22h13
StringBuilder

Citation:

Envoyé par cestpasmoinonplus

Rien de surprenant, je ne vois pas pourquoi ça toucherait aux performances 8O.

Euh... C'est toi qui dit que les backups provoquent des freezes chez toi.
30/04/2019, 11h12
cestpasmoinonplus

Ben oui, ça ne joue pas sur les performances. Les utilisateurs n'y voient que du feu.
Le problème est que les SGBD privilégient les lectures aux écritures.
Du coup, plus il y a d'utilisateurs qui requètent la base, plus les écritures freezent.
30/04/2019, 11h14
cestpasmoinonplus

Citation:

Envoyé par janlouk

Tu ne fais aucun backup log ? Toutes tes DB sont en SIMPLE alors?

Euh... :oops:
Je fais des BACKUP DATABASE ...
et il me fait des fichier .bak
30/04/2019, 11h20
cestpasmoinonplus

Citation:

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Alors là, il faudrait peut-être plus voir du côté infra et l’organisation des fichiers : ça ressemble à des disques pas particulièrement rapides avec tous les fichiers de data / log / backup qui grattent dessus.
Ajoute deux trois applications gourmandes sur le même serveurs...

Oui ça ressemble à ça. Sauf que même avec du bon matériel, disques SSD et grosse ram, la base continue à vivre et fini par rencontrer le même problème un peu plus tard.
Mais bon... On a déjà limité les dégâts avec les backup différentielles qui ne font plus freezer les écritures de toute la semaine.
Bien déjà :P.
Bien content. Merci encore à tous.

Citation:

Envoyé par cestpasmoinonplus

Euh... :oops:
Je fais des BACKUP DATABASE ...
et il me fait des fichier .bak

Tu peux utiliser cette query, elle va t'afficher toutes les DB en recovery model FULL et sans backup log.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
--https://www.mssqltips.com/sqlservertip/1895/script-to-find-sql-server-databases-without-transaction-log-backups/
--Il affiche aussi des DB dont il y déjà eu des backup log mais avant le dernier FULL, donc cela prouve qu'il n'y en a pas eu régulièrement.
SELECT D.[name] AS [database_name_WITHOUT_log_backup], D.[recovery_model_desc]  
FROM sys.databases D LEFT JOIN  
( 
   SELECT BS.[database_name],  
   MAX(BS.[backup_finish_date]) AS [last_log_backup_date]  
   FROM msdb.dbo.backupset BS  
   WHERE BS.type = 'L'  
   GROUP BY BS.[database_name]  
   ) BS1  
ON D.[name] = BS1.[database_name] 
LEFT JOIN  
( 
   SELECT BS.[database_name],  
   MAX(BS.[backup_finish_date]) AS [last_data_backup_date]  
   FROM msdb.dbo.backupset BS  
   WHERE BS.type = 'D'  
   GROUP BY BS.[database_name]  
) BS2  
ON D.[name] = BS2.[database_name] 
WHERE 
((D.[recovery_model_desc] <> 'SIMPLE' 
AND BS1.[last_log_backup_date] IS NULL OR BS1.[last_log_backup_date] < BS2.[last_data_backup_date])
AND D.[name] NOT IN ('model')) AND D.[recovery_model_desc] NOT IN ('SIMPLE') AND D.state <> 6 -- DB OFFLINE
ORDER BY D.[name];

Pour info, une DB en FULL sans backup log, il va grandir indéfiniment.

Perso, ma stratégie chez mon client actuel, c'est un FULL tous les samedis, un DIFF tous les soirs et backup log toutes les 15 minutes.

30/04/2019, 16h48
Invité

Citation:

Envoyé par janlouk

Perso, ma stratégie chez mon client actuel, c'est un FULL tous les samedis, un DIFF tous les soirs et backup log toutes les 15 minutes.

Ben comme toujours, ça dépend ce que le client est prêt à perdre en cas de problème et de la taille des bd / backups, tout est affaire de compromis, il n'y a pas de recette miracle !
Mais il reste qu'il faut comprendre ce que l'on fait...
01/05/2019, 11h01
Michel.Priori

Pour revenir sur les problèmes de freeze lors des backup :

L'instruction backup database pose un verrou sur les fichiers eux mêmes : ils ne peuvent plus "grossir" pendant le temps de la sauvegarde (et inversement, mais c'est moins remarquable).

Du coup je suspecte que la définition des fichiers de données (si si, au pluriel ; il peut y avoir plusieurs fichiers et même des "groupes de fichiers") sans beaucoup de place disponible et une règle d'accroissement de ceux-ci trop juste.
La conséquence est que les fichiers "grossissent" souvent.

Les paramètres combinés font qu'on ressent des freeze.

On voit l'évènement d'accroissement dans les journaux SQL et dans les rapports de la base.
Est-ce bien le cas ?

A noter que BACKUP LOG ne pose pas de verrous sur les fichiers de données.
Une raison de plus pour regarder ça de plus près ;)
02/05/2019, 10h43
cestpasmoinonplus

Citation:

Envoyé par Michel.Priori

A noter que BACKUP LOG ne pose pas de verrous sur les fichiers de données.
Une raison de plus pour regarder ça de plus près ;)

C'est clair :). Merci Michel.
Mais c'est la restoration d'un tel backup qui me fait peur :?.
Qu'est ce que ce backup des log permet-il de sauvegarder réellement ? 8O

Je réfléchi tout haut. Je vais creuser ça dès que j'ai un moment...
02/05/2019, 19h33
StringBuilder

Le backup des logs permet de sauvegarder absolument tout.
Et le gros avantage du backup log, c'est que si tu sauvegardes toutes les heures, et que ton client te dis "purée... j'ai merdé un import de donnée qui a pourri la base... 5 minutes avant le backup, bouhouhou j'ai tout perdu !", tu peux lui dire en mode sauveur de l'humanité toute entière et du reste aussi "pas de problème... ta connerie... tu l'as faite à 17h54 et 32 secondes ? Tu veux que je te restore la base à 17h54 et 31 secondes, juste avant ta connerie ?"

Un diff ne permettra pas ça... Un full non plus. Le log, lui, il garde le détail de tout ce qui c'est passé, donc tu peux rejouer chaque transaction une à une.

Le seul défaut, c'est que si tu as énormément de transactions, ça peut mettre un peu plus de temps à restaurer qu'un simple backup full/diff.
06/05/2019, 09h00
SQLpro

Citation:

Envoyé par cestpasmoinonplus

Pour minimiser les freeze sur les écritures. Nous écrivons chaque seconde dans plusieurs tables. Les backup font freezer les écritures.

A mon avis c'est parce que vous pratiquez des SNASPHOT de VM et non des BACKUPs SQL Server qui n'ont aucun impact sérieux sur les performances !

A +
06/05/2019, 09h03
SQLpro

Citation:

Envoyé par Michel.Priori

Pour revenir sur les problèmes de freeze lors des backup :
L'instruction backup database pose un verrou sur les fichiers eux mêmes : ils ne peuvent plus "grossir" pendant le temps de la sauvegarde (et inversement, mais c'est moins remarquable).

Là tu met le doigt sur une chose important : TOUJOURS prédimensionner les volumes de stockage des données et journaux !

A +

Voir 40 message(s) de cette discussion en une page