Discussion :

[Franck_P]

Bonjour,

J'ai un serveur dont le système est HS. (Win server 2012 R2 / SQL Server 2012 SP1 / 1 Instance )
Je vais remonter la sauvegarde de cette nuit et j'aimerai savoir comment être sûr de mon état restauré sur le serveur SQL et les bonnes pratiques.

1- Éléments que je possède
------------------------------
* Sauvegarde complète de la base master, model, msdb (tous les soirs à 23h)
* Sauvegarde complète de la base Applicative (tous les soirs après avoir fait une sauvegarde des LOGS (Type Transaction Logs)


2- A la remontée de mes sauvegardes (Partition système et Partition datas) je vais retrouver l'ensemble de mon serveur y compris les datafiles dans l’état au moment de la sauvegarde du système de fichiers sur bande
--------------------------------------------------
* Quelles sont les actions et bonnes pratiques que vous conseillez de faire dans ce genre de cas ?
* Le datafiles étant dans un etat X peut être non consistent, peut on partir de ceux ci sans remontage des backups et en faisant un check ?
* Ordre de restauration des bases (master, model, msdb, appli) ?
* Vérifications ?

Merci pour votre aide précieuse
Cordialement

[olivtone]

pour restaurer Master il faut :

- Arrêter le service SQL server
- Ajouter l'option -m dans la ligne de lancement de commande du service SQL Server (demarrage en mode mono utilisateur)
il faudra enlever l'option -m apres la restauration

Il faut restaurer cette BDD en premier , car master recense le nom de toutes les BDD, des utilisateurs etc...
j'en parle dans cette vidéo

Apres tu peux restaurer model, qui te sert de modele a chaque creation de nouvelles BDD, et msdb si tu en as besoin (si jamais tu avais des jobs de maintenance, des proxy, les mails configurés sur le serveur SQL etc...)

Pour verifier l'etat des tes backups il faut faire un RESTORE FILELISTONLY :

RESTORE VERIFYONLY se charge de vérifier :

- que le jeu de sauvegarde est complet et que tous les volumes sont lisibles ;
- certains champs d'en-tête des pages de la base de données, tels que l'ID de la page (comme si l'écriture des données allait avoir lieu) ;
- la somme de contrôle (si elle figure sur le support) ;
- s'il y a un espace suffisant sur les périphériques de destination.

[Franck_P]

Merci pour ta réponse détaillée.

Je me trouve dans une situation comparable je pense a un arrêt brutal de la machine et donc avec une perte des données présentes en RAM non écrites sur les disques.
Si je redémarre le serveur physique et que le serveur SQL ne rale pas, est-ce que la restauration des bases Systemes et Appli est incontournable ôu bien on peut lancer une vérification de cohérences ?
Comment être sûr que tout va bien ?

[olivtone]

Commence par :

- Restaurer les BDD de production( cela va inscrire le nom des BDD dans la Base Master)
- Creer les utilisateurs sur les moteurs SQL qui auront besoin a tes futurs BDD
- Creer des jobs de maintenance (ton plan de nuit )concernant les BACKUP, les UPDATE STATS, le CHECKDB (qui va verifier l'integralité de ta BDD )

Concernant la RAM :

- Il y a une partie dédiée pour le plan cache (qui va récupérer les plans d’exécutions des PS et aussi des requêtes ADHOC)
- une partie pour le buffer pool qui va recenser tes données

Donc quand tu vas réinstaller ton application et qu'elle va tourner, le plan cache et le buffer pool vont se repeupler petit a petit, mais il y aura certaines lenteurs au debut.

[rudib]

Si je redémarre le serveur physique et que le serveur SQL ne rale pas, est-ce que la restauration des bases Systemes et Appli est incontournable ôu bien on peut lancer une vérification de cohérences ?
Comment être sûr que tout va bien ?

Donc tes fichiers sur le disque sont toujours là ?

Tu peux redémarrer le serveur physique pour voir ce qui se passe. Au démarrage, SQL Server va rejouer une partie du journal de transactions et réappliquer les dernières transactions. Tes fichiers de données ne devraient pas avoir souffert. si toutes les bases sont correctement remontées, inutile d'effectuer des restaurations.

Ensuite, tu effectues un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKDB

dans chaque base, pour vérifier que tout va bien.

[Franck_P]

Merci.
J'aurai accès au serveur demain matin.
Je pensai effectivement lancer le serveur SQL et voir si j'arrive a me connecter dessus. Puis faire un check des bases Systemes + Base de mon application pour savoir si tout ce passe bien.

Je posterai mes conclusions après la verif.

[SQLpro]

* Quelles sont les actions et bonnes pratiques que vous conseillez de faire dans ce genre de cas ?

Récupérer les fichiers de votre base de production et les intaller sur un serveur de secours par attachement. Vois si cela marche.
Si cela ne marche pas, créer une base de même nom, arrêter le serveur de secours, supprimer les fichiers et les remplacer par les fichiers récupérés. Redémarrer le serveur qui vous indiquera dans les journaux d'événements la nature du problème.
Tentez une sauvegarde de la queue du journal de transaction (option NO TRUNCATE).
Si cela marche vous pourrez récupérer 100 % de vos données en ajoutant à votre restauration FULL ce dernier journal.

A +