Waarom je nooit tussendoor een Full Backup draait in SQL Full Recovery Mode en waarom handmatige log backups ook riskant zijn

Wanneer je SQL Server in Full Recovery Mode gebruikt, draait alles om één fundament:

de transaction log chain. Die keten bepaalt of je database volledig en betrouwbaar te herstellen is.

Toch zie je het in de praktijk vaak gebeuren:

Je transaction log is enorm gegroeid.

Je wilt ’m verkleinen.

En voordat je backupsoftware weer begint, start je in SQL Server Management Studio even snel een Full Backup.

Want “dat kan geen kwaad”… toch?

Helaas wel.

Wat er gebeurt als je tussendoor een Full Backup draait

Een Full Backup verkleint je log niet.

Het doet helemaal niets voor je loggrootte.

Maar het veroorzaakt wel:

• Een nieuwe basis voor differential of incremental backups

• Je backupsoftware raakt uit sync

• De volgende differential/incremental sluit niet meer aan

Resultaat: je backupketen is beschadigd of ongeldig

De chain voor log backups blijft technisch gezien bestaan, maar je volledige herstelstrategie is niet langer betrouwbaar. En dat allemaal terwijl je log nog steeds even groot is.

👉 Conclusie: een Full Backup draaien om je log te verkleinen is zinloos én gevaarlijk.

Hoe zit het dan met een handmatige transaction log backup?

Een normale transaction log backup breekt de chain niet.

Het hoort juist bij de chain.

Maar…

je wilt dit eigenlijk nooit handmatig doen in SSMS.

Waarom niet?

✔ 1. Je backupsoftware beheert de LSN-keten

Als jij handmatig een log backup draait, “jat” je de volgende stap die je backupsoftware verwacht te doen.

Gevolgen:

• De software kan fouten geven

• De volgende incremental/differential kan ongeldig zijn

• In het ergste geval moet je software een volledige nieuwe baseline/full doen

✔ 2. Je logretentie komt buiten beheer

Backupsoftware bewaakt retentie, monitoring en herstelbaarheid.

Handmatige log backups vallen daarbuiten.

Je introduceert risico, zonder voordeel.

✔ 3. Herstel wordt complexer

Bij een disaster recovery-scenario wil je exact weten welke chain geldig is.

Losse handmatige log backups maken dat onduidelijker en vergroten de kans op herstelproblemen.

Wat moet je dan wél doen als je log te groot is?

✔ 1. Laat je backupsoftware een log backup uitvoeren

Dit zorgt voor log-truncation en behoudt de chain onder controle van één systeem.

✔ 2. Achterhaal waarom het log groeide

Een groeiend log is een symptoom, geen oorzaak.

Typische redenen:

• Grote of langdurige transacties

• Index maintenance

• Een job die hangt

• Te weinig log backups

• Een verkeerd ingestelde recovery mode

✔ 3. Alleen shrinken na truncation, en alleen als uitzondering

Shrinken is geen structurele oplossing.

Gebruik het alleen als tijdelijke maatregel, niet als routine.

Samengevat

Draai nooit een losse Full Backup in SSMS wanneer je SQL in Full Recovery Mode draait.

→ Je verkleint je log niet en je saboteert je backupketen.

Doe log backups in principe nooit handmatig.

→ Laat je backupsoftware de volledige chain beheren.

Wil je logruimte vrijmaken?

→ Laat je software een log backup uitvoeren, fix de oorzaak van de groei en shrink alleen wanneer noodzakelijk.