Dimarts, gener 20, 2026

El dia a dia d'un administrador de sistemes

BASES DE DADES

Restaurar backups de SQL Server pas a pas

Rafael Quintero

Restaurar una base de dades a SQL Server hauria de ser un procés rutinari, i de vegades ho és. Però quan les coses surten malament —quan hi ha pressió, quan els arxius no encaixen amb la instància, quan el backup no es va fer bé o quan hi ha més d’un entorn implicat— és fàcil perdre temps o prendre dreceres que generen problemes després.

Abans de restaurar: el que cal saber del backup

La primera pregunta real és: quin tipus de backup tens?

SQL Server admet tres tipus principals:

  • FULL: còpia completa de la base de dades.
  • DIFFERENTIAL: diferència respecte a l’ últim FULL.
  • LOG: backup de transaccions des de l’ últim FULL o DIFF o LOG.

Molts errors venen de no tenir clar això. Restaurar un LOG sense saber de quin FULL ve és un clàssic. També és comú que et passin un .bak sense dir-te si és FULL o DIFF, o que et donin diversos .trn i no quedi clar quin és l’ordre o si en falta algun.

El primer que hem de fer sempre és inspeccionar l’arxiu amb RESTORE HEADERONLY. Això dóna la informació que necessites:

RESTORE HEADERONLY FROM DISK = 'D:\backups\produccion_FULL.bak';

Busca les columnes BackupType, FirstLSN, LastLSN, CheckpointLSN, DatabaseBackupLSN, BackupFinishDate.

  • BackupType = 1 → FULL
  • BackupType = 5 → DIFF
  • BackupType = 2 → LOG

Assegura’t que les seqüències LSN tinguin continuïtat si has de restaurar diversos LOG.

També podem fer servir:

RESTORE FILELISTONLY FROM DISK = ‘D:\backups\produccio_FULL.bak’;

Això ens diu els noms lògics dels arxius i rutes originals. Molt útil per a planificar si has de moure’ls amb MOVE.

Restaurar un FULL: el mínim

En restauracions simples (mateixa instància, mateix nom, sense usuaris connectats), amb una cosa així n’hi ha prou:

USE master;
GO
 
RESTORE DATABASE produccio
FROM DISK = 'D:\backups\produccio_FULL.bak'
WITH REPLACE;

WITH REPLACE és obligatori si existeix una base amb aquest nom. Si no el poses, SQL Server no sobreescriu, fins i tot si l’arxiu està corrupte. El que no fa WITH REPLACE és eliminar arxius antics que no estiguin al backup, la qual cosa pot deixar escombraries si has canviat l’estructura de la base.

Restaurar amb MOVE: quan canvia l’ entorn

Si estàs restaurant en un altre servidor o la ruta de dades/log no és la mateixa, necessites MOVE:

RESTORE DATABASE produccio
FROM DISK = 'D:\backups\produccio_FULL.bak'
WITH 
  MOVE 'produccio_data' TO 'E:\sql_data\produccio.mdf',
  MOVE 'produccio_log' TO 'E:\sql_logs\produccio.ldf',
  REPLACE;

L’error típic aquí és escriure malament els noms lògics (produccio_data, produccio_log en aquest exemple). No són els noms d’arxiu; són els LogicalName que vam veure amb RESTORE FILELISTONLY.

També val la pena verificar que el path de destinació existeix i té permisos. SQL Server no crea rutes, només arxius. Si la carpeta no existeix o SQL Server no té permisos, l’error que retorna és poc clar (“Operating system error 3” o “Access denied”).

Restaurar un FULL + DIFF

Si tens un diferencial a més del full, l’ordre importa.

  • Restaures el FULL amb NORECOVERY.
  • Després apliques el DIFF amb RECOVERY.
-- Pas 1
RESTORE DATABASE produccio
FROM DISK = 'D:\backups\produccio_FULL.bak'
WITH 
  MOVE 'produccio_data' TO 'E:\sql_data\produccio.mdf',
  MOVE 'produccio_log' TO 'E:\sql_logs\produccio.ldf',
  NORECOVERY,
  REPLACE;
 
-- Pas 2
RESTORE DATABASE produccio
FROM DISK = 'D:\backups\produccio_DIFF.bak'
WITH RECOVERY;

Sense NORECOVERY, no pots aplicar més backups. El bloqueja i força el RECOVERY, tancant la cadena.

Una altra fallada habitual: intentar aplicar un diferencial que no correspon a aquest FULL. SQL Server no et deixa, però l’error pot confondre. Cal verificar que el DatabaseBackupLSN del diferencial coincideixi amb el CheckpointLSN del FULL.

Restaurar múltiples LOG (.trn)

Aquí hi ha dues formes de complicar-se la vida: no saber si en falta un, o barrejar l’ordre.

Has d’aplicar tots els logs un a un amb NORECOVERY, excepte l’últim, que va amb RECOVERY.

Exemple:

RESTORE LOG produccio FROM DISK = 'D:\backups\log1.trn' WITH NORECOVERY;
RESTORE LOG produccio FROM DISK = 'D:\backups\log2.trn' WITH NORECOVERY;
RESTORE LOG produccio FROM DISK = 'D:\backups\log3.trn' WITH RECOVERY;

O, si restaures fins a un punt en el temps:

RESTORE LOG produccio 
FROM DISK = 'D:\backups\log3.trn'
WITH STOPAT = '2025-07-10 15:30:00', RECOVERY;

STOPAT només es pot fer servir en l’últim LOG. Si intentes fer-lo servir abans, falla.

I si falta un .trn intermedi? No pots continuar. SQL Server detecta el buit als LSN i retorna un error. Si et passen una sèrie incompleta, no perdis temps provant: revisa tots els LSN amb RESTORE HEADERONLY i assegura’t que la seqüència és contínua.

Restaurar sense sobreescriure arxius antics que no són al backup

Això passa quan una base ha crescut, s’hi han afegit arxius, i després es restaura des d’un backup anterior. SQL Server no esborra els arxius extra. I pots acabar amb una base restaurada que té arxius que ja no haurien d’existir.

Solució: esborra manualment la base abans de restaurar. O elimina els arxius abans si estàs canviant rutes. WITH REPLACE només reemplaça els arxius esmentats al backup.

Restaurar amb nom diferent

Quan necessites tenir una base restaurada en paral·lel a l’original, canvies el nom lògic i els paths. Exemple típic: muntar una còpia de producció en staging.

RESTORE DATABASE produccio_staging
FROM DISK = 'D:\backups\produccio_FULL.bak'
WITH 
  MOVE 'produccio_data' TO 'E:\sql_data\produccio_staging.mdf',
  MOVE 'produccio_log' TO 'E:\sql_logs\produccio_staging.ldf',
  REPLACE;

Si no fas això, i fas servir el mateix nom lògic que una altra base muntada, SQL Server retorna error.

Restaurar una base sense connexions obertes

Quan has de sobrescriure una base existent i està en ús, el més segur és desconnectar a tothom:

ALTER DATABASE produccio SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

Després restaures, i després la retornes a multiusuari:

ALTER DATABASE produccio SET MULTI_USER;

Si no fas això, és freqüent que alguna app o usuari es reconnecti entre mitges i bloquegi el procés. De vegades, ni el Management Studio la deixa anar.

Verificar la restauració sense arrencar la base (RESTORE VERIFYONLY)

Això no comprova que les dades estiguin bé, però sí que l’arxiu de backup és vàlid i coherent. És ràpid i pot estalviar temps abans d’una restauració que ha de trigar molt:

RESTORE VERIFYONLY FROM DISK = 'D:\backups\produccio_FULL.bak';

No restaura res. Només valida estructura.

Restaurar amb scripts: plantilla per a restauracions controlades

Molts fem servir scripts amb variables per a restaurar backups de forma repetible. Si ho fas a mà cada vegada, acabaràs cometent errors.

Una plantilla típica:

DECLARE @BackupFile NVARCHAR(255) = N'D:\backups\produccio_FULL.bak';
DECLARE @DataFile NVARCHAR(255) = N'E:\sql_data\produccio_copy.mdf';
DECLARE @LogFile NVARCHAR(255) = N'E:\sql_logs\produccio_copy.ldf';
 
RESTORE DATABASE produccio_copy
FROM DISK = @BackupFile
WITH 
  MOVE 'produccio_data' TO @DataFile,
  MOVE 'produccio_log' TO @LogFile,
  REPLACE;

Permet estandarditzar noms, rutes i evita sorpreses.

Restaurar en una altra instància (o versió diferent)

Migrar una base des de SQL Server 2016 a 2019 és directe. A la inversa, no. SQL Server no permet restaurar backups fets en versions més recents sobre instàncies més antigues.

Si necessites muntar una base en una versió anterior, no pots fer servir RESTORE. Has d’exportar les dades (DACPAC, SSIS, o scripts d’INSERT) o fer servir eines de tercers. No hi ha drecera oficial.

Quan el backup no és de base de dades, sinó de FILEGROUP o PARTIAL

Això no és l’habitual, però apareix en bases de dades grans on s’ha segmentat per filegroups. Restaurar només un filegroup requereix saber què està en aquest grup i si és de només lectura.

En aquests casos, necessites assegurar-te que la resta de la base pot arrencar en mode parcial. Per això, els backups s’han d’ haver fet amb PARTIAL i la resta ha de seguir aquesta lògica. Ho esmento perquè més d’una vegada m’han preguntat per què un restore no es pot completar, i resulta que falta el PRIMARY o no es va fer backup del filegroup correcte.

Això és més comú en entorns que gestionen taules particionades o arxivat històric.

Restaurar programadament: no confiïs només en el GUI

SQL Server Management Studio permet restaurar des de l’assistent gràfic, i funciona bé en entorns simples. Però no és reproduïble. El que algú fa clic a clic no es pot repetir amb fiabilitat en un altre entorn o sota pressió.

Sempre que provis una restauració, treu l’script i guarda’l. Ho pots fer des de l’assistent abans d’executar-lo (botó “Script” a dalt a l’esquerra). Això et dona una base sòlida per automatitzar-lo, versionar-lo o corregir-ho si alguna cosa canvia.

Errors comuns

Restaurar sobre la base equivocada

De vegades, sobretot en entorns amb moltes bases semblants, algú executa un RESTORE amb WITH REPLACE sobre la base equivocada. Per això sempre val la pena confirmar:

SELECT name, database_id FROM sys.databases;

I després verificar:

SELECT DB_NAME() AS current_database;

Just abans de llançar el RESTORE.

Restaurar al servidor equivocat

És una variant de l’error anterior, però més greu. Hi ha vegades en què es llença un RESTORE en un entorn productiu creient que és desenvolupament. Fes servir noms explícits, i en la mesura del possible, assegura’t de tenir scripts que validin l’entorn abans d’executar accions destructives.

Una pràctica útil és configurar el prompt de SSMS o fer servir colors de fons diferents en cada servidor per a distingir entorns.

Restaurar sense verificar que es va completar correctament

He vist restauracions “fetes” que van deixar la base en mode RESTORING perquè faltava el WITH RECOVERY. SQL Server no retorna error, simplement queda esperant el següent pas.

Sempre revisa l’estat al final:

SELECT name, state_desc FROM sys.databases WHERE name = 'produccio';

No esborrar o renovar arxius antics abans de restaurar

Si restaures una base però canvies la ubicació dels arxius, SQL Server no esborra els antics. És molt fàcil acabar amb arxius redundants ocupant espai o fins i tot causant conflictes si algú intenta restaurar de nou sense adonar-se que els arxius segueixen aquí.

Sempre revisa manualment els arxius antics si estàs canviant rutes. O automatitza la seva neteja amb scripts controlats.

Restauracions automatitzades: proves i rutina

En molts entorns, sobretot en aquells amb alta sensibilitat a les dades, es restauren backups automàticament a diari en entorns de staging o testing. Això no és només per a tenir un entorn actualitzat, també serveix com a prova regular que el backup és vàlid.

No n’hi ha prou amb verificar que el job de backup va acabar sense errors. Restaurar a diari una còpia és la millor manera de saber que el procés complet funciona.

Això es pot automatitzar amb PowerShell, T-SQL i tasques de l’ Agent SQL Server. És una inversió que es paga sola.

Restaurar bases amb TDE (Transparent Data Encryption)

Si la teva base estava xifrada amb TDE, no podràs restaurar-la en una altra instància sense importar també la clau de xifrat i el certificat.

Error típic:

“Cannot find server certificate with thumbprint ‘XXXX’”

Solució:

  • Exportar el certificat i la clau privada des del servidor original.
  • Importar-lo en el servidor de destinació.
  • Només llavors, restaurar la base.

Passos típics:

--Al servidor origen
BACKUP CERTIFICATE MyTDECert 
TO FILE = 'D:\certs\MyTDECert.cer' 
WITH PRIVATE KEY (
    FILE = 'D:\certs\MyTDECert.pvk',
    ENCRYPTION BY PASSWORD = 'clauSegura123'
);
--Al servidor destinació
CREATE CERTIFICATE MyTDECert
FROM FILE = 'D:\certs\MyTDECert.cer'
WITH PRIVATE KEY (
    FILE = 'D:\certs\MyTDECert.pvk',
    DECRYPTION BY PASSWORD = 'clauSegura123'
);

Això s’hauria de fer amb extrema cura, en entorns controlats, i mai oblidis protegir aquestes claus com si fossin el backup mateix. Sense elles, el backup xifrat és irrecuperable.

Checklist per a restauracions que vols que funcionin a la primera

Abans de restaurar:

  • Saps si l’arxiu és FULL, DIFF o LOG?
  • Has verifica’t la validesa amb RESTORE VERIFYONLY?
  • Coneixes el nom lògic dels arxius (RESTORE FILELISTONLY)?
  • Hi ha arxius anteriors en disc que podrien causar conflicte?
  • El nom de la base coincideix amb una altra existent? Necessites WITH REPLACE?
  • Has de restaurar a una altra ruta? La carpeta existeix i té permisos?
  • Estàs segur de que estàs a la instància correcta?
  • La base està lliure de connexions? Has tancat sessions actives?

Durant la restauració:

  • L’ordre dels backups és correcte?
  • Has fet servir NORECOVERY en tots menys l’últim?
  • Confirmeu que la base està en estat ONLINE en acabar?

Després de restaurar:

  • Has provat que les dades esperades estan accessibles?
  • S’ha netejat qualsevol arxiu redundant?
  • Hi ha jobs, triggers, users, o rols que depenen de la configuració local?

Conclusió

Restaurar un backup no hauria de ser una operació tensa. Però ho és quan no estàs segur del que estàs restaurant, o quan l’entorn té subtileses que no es veuen a simple vista. Amb els anys, el que més ha marcat la diferència no són els comandaments que un recorda, sinó els hàbits: inspeccionar els backups abans de fer-los servir, documentar l’entorn, tenir scripts reproduïbles, i desconfiar dels .bak que arriben sense context.

Aquest procediment és el tipus de tasca que més fàcil s’automatitza malament. Per això convé tenir bones plantilles, provar-les amb regularitat, i tractar-les com a part del sistema, no com una excepció que s’executa quan tot falla.

You May Also Like

Automatització pràctica de backups diaris de MySQL amb S3

Rafael Quintero

Configurar l’accés remot segur a MySQL

Rafael Quintero

Instal·lació de MS SQL Server 2019

Rafael Quintero

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *