Publié le : 26/06/2025

Récit d’une restauration SQL Server pas si tranquille

récit d'une restauration sous sql server

– Comment un backup « innocent » a obligé à passer de 2019 à 2022, puis à corriger un login orphelin –

Situation de départ

Instance SQL Server 2019 (15.0.2000).
Fichier de sauvegarde : xxx_250624.bak.
Objectif : restaurer la base mydb.

Dès la première tentative, la commande :

RESTORE DATABASE mydb
FROM DISK = 'C:\DB\xxx_250624.bak';

retourne :

Msg 3169 : Database was backed up on a server running version 16.00.4155…
Msg 3013 : RESTORE DATABASE is terminating abnormally.

2. Diagnostic pas-à-pas

Étape	Outil / Script	Indice trouvé
2.1 Vérifier la version du backup	`RESTORE HEADERONLY FROM DISK = …`	Numéro de version 16 → SQL 2022
2.2 Confirmer la version cible	`SELECT @@VERSION;`	15.0.xxx → SQL 2019
2.3 Rechercher une compatibilité descendante	Docs Microsoft	Les backups n-1 → n oui, n → n-1 non

Conclusion : impossible de restaurer un backup SQL 2022 vers SQL 2019.

3. Solution retenue : mise à niveau in-place vers SQL Server 2022

Sauvegarde complète des bases système et utilisateurs (toujours).
Téléchargement de l’ISO SQL 2022 + dernière CU.
Setup.exe → Upgrade from previous version.
Redémarrage, validation : @@VERSION → 16.0.xxxx.

Temps d’arrêt total observé : ~25 min.

4. Restauration proprement dite

4.1 Identifier les noms logiques

RESTORE FILELISTONLY
FROM DISK = 'C:\DB\xxx_250624.bak';

LogicalName	PhysicalName (dans le backup)
mydbData	C:\DATABASE\USERDB\mydbData.mdf
mydbLog	C:\DATABASE\LOG\mydbLog.ldf

4.2 Commander la restauration

-- Libérer la base existante si nécessaire
IF DB_ID('mydb') IS NOT NULL
    ALTER DATABASE mydb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

RESTORE DATABASE mydb
  FROM DISK = 'C:\DB\xxx_250624.bak'
  WITH FILE = 1,
       MOVE 'mydbData' TO 'C:\DB\mydbdata.mdf',
       MOVE 'mydbLog'  TO 'C:\DB\mydblog.ldf',
       REPLACE,
       STATS = 10;
GO

ALTER DATABASE mydb SET MULTI_USER;

4.3 Contrôles post-restauration

DBCC CHECKDB('mydb') WITH NO_INFOMSGS;

5. Dernier obstacle : le login démarre sur une base introuvable

Après restauration :

Cannot open default database requested by login 'myuser'.

5.1 Reconnecter le login à la base

USE master;
ALTER LOGIN myuser WITH DEFAULT_DATABASE = [mydb];
GO
ALTER USER myuser WITH LOGIN = myuser;  -- remapping si besoin

(Créer le user si absent : CREATE USER myuser FOR LOGIN myuser; puis rôles.)

5.2 Vérification

EXECUTE AS LOGIN = 'myuser';
SELECT SYSTEM_USER AS login, DB_NAME() AS current_db;
REVERT;

Résultat attendu : current_db = mydb.

6. Bilan & bonnes pratiques pour la restauration sql server

Leçon	Pourquoi c’est important
Toujours connaître la version source d’un backup	`RESTORE HEADERONLY` évite des heures perdues.
Planifier une stratégie d’upgrade	L’in-place est rapide ; le side-by-side limite le risque.
Vérifier/Remapper les logins après restauration	Empêche les erreurs 18456 et 916 à la connexion.
Scripts de contrôle (DBCC CHECKDB, sp_change_users_login)	Valident l’intégrité et la sécurité du nouvel environnement.

En résumé : un simple backup peut cacher une différence de version fatale. Identifier l’incompatibilité, upgrader proprement, puis soigner les détails (paths, logins) garantit une restauration sans surprise.

Les mots clés rattachés à cet article : Base de données - SQL Server