Discussion :

[Syl20.s]

Bonjour,

Suite a une attaque de virus, il a fallu reinstaller le serveur et donc SQL-SERVER.
j'ai un fichier MDF (du 29/03) et un fichier LDF (du 24/04). Ils ne sont pas de la même date. Est-ce normal ?
J'ai réussi à intégrer le Fichiers MDF au serveur SQL avec un fichier LDF de la même date. J'ai donc récupéré la base de données au 29/03.

Comment faire pour "rejouer" le contenu de mon LDF afin de retrouver ma base tel qu'elle était le 24/4 ?

Merci par avance
Syl20

[elsuket]

Bonjour,

Si vous n'avez pas de sauvegarde du fichier du journal des transactions, je ne pense pas que cela soit possible.
Les sauvegardes de base de données ne peuvent pas être prises au niveau fichier, car l'OS n'a aucun moyen d'être informé de l'intégrité transactionnelle d'une base de données.

Toutes les sauvegardes de base de données (complète, différentielle, du journal des transactions, d'un groupe de fichiers, ...) peuvent et doivent être réalisées à chaud, sans arrêter l'instance SQL Server.

@++

[hmira]

Bonjour,

Vous pouvez et c'est HYPER IMPORTANT, sauvegarder, à partir du dernier fichier .ldf daté du 24/04, la queue du journal des transactions ("Tail-Log Backup")
Comme le serveur a été endommagé puis réinstallé, il faut pour cela, procéder à ce que certains appellent un "hack-attach". Ci-dessous la procédure à suivre :
1 - Créez sur le Serveur nouvellement réinstallé, une base de donnée "bidon" portant le même nom que la base initiale (celle endommagée)
2 - Mettez la dite base hors ligne (OFFLINE)
3 - Re-simulez un nouveau un désastre !, et ce, en supprimant au niveau de l'OS les 2 fichiers .mdf et .ldf de la base "bidon" nouvellement créée et portant le même nom que l'ancienne.
4 - Recopiez au niveau de l'OS, au même emplacement, l'ancien fichier .ldf ( celui 24/04) en remplacement du fichier .ldf supprimé. Ne recopiez pas, ne faites rien pour le fichier .mdf désormais absent puisque supprimé à l'étape 3 ci-dessus.
5 - Remettez la base en ligne (ONLINE). l'opération échoue est c'est normal. La base "bidon" sera néanmoins à l'état "Recovery Pending"
6 - Sauvegardez la queue du journal de transaction (Tail-Log Backup) en mode NO_TRUNCATE. Le mode NO_TRUNCATE est nécessaire sinon il devient impossible d'effectuer un "Tail-Log Backup" puisque le fichier .mdf est manquant.
7 - Maintenant, vous serez désormais en mesure d'effectuer une restauration de la base, en mode NORECOVERY en suivant et en respectant la chaine de sauvegarde (du dernier backup complet , jusqu'au "Tail Log Backup" constitué à l'étape 6 ci-dessus.
8 - Mettez enfin la base en mode RECOVRY.


A+

[SQLpro]

ça peut marcher à conditions qu'il n'y ait pas de "trou" ! c'est à dire qu'il n'y ait eu aucune sauvegarde intermédiaire.

A +

[hmira]

Bonjour SQLPro,

Oui tout à fait, c'est ce qu'on appelle communément la chaîne de sauvegarde (Backup Chain).
Donc Oui effectivement, il ne faut pas qu'il est de trou, dans le sens où il ne faut pas qu'il y ait de sauvegarde manquante dans la chaîne de sauvegarde (ie, aucune rupture dans les séquences LSN).

En revanche, il peut y avoir plusieurs sauvegardes intermédiaires, qu'il s'agisse de sauvegardes différentielles (Differential Backup) ou de sauvegardes de journaux de transaction (Log Backup), entre la sauvegarde complète (Full Backup) (celle qui amorce la chaîne de sauvegarde) et la la queue du journal (Tail Log backup).

Bien entendu, il ne faut pas que la chaîne de sauvegarde soit brisée par une quelconque autre manipulation.

A+

[SQLpro]

Saut sauvegarde FULL en mode "COPY_ONLY"

A +

[hmira]

Bonjour Frédéric,

Oui, c'est tout à fait exact en ce qui concerne un "FULL BACKUP COPY_ONLY".

On peut exclure également les "BACKUP LOG COPY_ONLY". En effet, ces deux types d'opérations n'altèrent en rien la chaîne de sauvegarde (Backup Chain).
Ceci dit, pour le second, et pour celles et ceux qui se poseraient la question de son utilité (?). L'intérêt réel d'effectuer un "BACKUP LOG COPY_ONLY" reste toutefois très limité. Cela peut être par exemple la synchronisation manuelle d'une copie de la base source (une base de destination) par application du journal de transaction généré avec un "BACKUP LOG COPY_ONLY" (depuis la base source), et ce, pour ne pas altérer ni s'interférer avec le plan et la chaîne de sauvegarde de la base source.

A+

[SQLpro]

ou pour analyse à la recherche par exemple d'une mauvaise manip genre DELETE involotaire....

A +

[hmira]

Oui. c'est effectivement un moyen pratique et surtout concret pour détecter ce genre de problèmes.
Il existe la commande DBCC PAGE et la fonction, non documentée, fn_dblog() qui est censée permettre la lecture et l'exploration à chaud du journal des transactions, mais, force est de constater, que les résultats de celle-ci, avec ses 129 colonnes ! sont illisibles, très difficilement déchiffrables. Il faut fournir beaucoup d'efforts pour déchiffrer et exploiter les résultats.

A+