Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

  • GeleFles
  • Registratie: Augustus 2001
  • Niet online

GeleFles

What's in a bottle?

Topicstarter
Ik zit met het volgende.

Blijkbaar is een tijd geleden (2 maanden), een fout geslopen in een database.
Nu moet de database van backup gerestored worden, maar helaas gaan onze backups niet zo ver terug.

Nu blijkt dat de database een tijd lang op FULL restore mode heeft gestaan, en van de logfiles is nooit een backup gemaakt, deze zijn dan ook behoorlijk groot. (De database is een jaar oud, dus het valt mee gelukkig)

Ik vermoed dat het nu mogelijk zou zijn om aan de hand van de logfiles, de database te restoren naar een bepaalde datum.
Klopt mijn vermoeden, en welke stappen moet ik nemen? Kan ik de logfiles aan een lege database koppelen, en dan op 1 of andere manier een gedeelte terugdraaien?

  • CMD-Snake
  • Registratie: Oktober 2011
  • Laatst online: 13-11-2022
Je kan tot een bepaald point in time restoren, ook bij SQL Server 2005. Dit doe je met de "stopat" switch van het restore commando.

Je transaction logs worden wel bij de laatste transaction log back-up leeggegooid. Dus check de logs dat ze tot het begin van je database terug gaan. Dat ze heel groot zijn zegt weinig, zeker als je een database hebt met heel veel acitivteit.

Je kan van de transaction logs restoren en dan ook tot een bepaald point in time. (Let op, dit is slechts een voorbeeld.)
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup4.trn'
WITH STOPAT = N'6/28/2007 4:01:45 PM', RECOVERY


Hier staat het de procedure uitgebreider beschreven met code voorbeelden en uitleg:
http://www.techrepublic.c...sing-transaction-logs/132

Het klinkt alsof je niet veel SQL Server beheer kennis hebt, dus pas op met deze procedure. Een verkeerde restore actie kan de boel finaal slopen.

Overigens wordt er wel meestal vanuit gegaan dat je een volledige back-up hebt gemaakt voor de boel mis ging en dat je de transaction logs wilt gebruiken om vanaf die volledige back-up zo dicht mogelijk wilt komen bij het moment dat het misging om data verlies te beperken.

Oh ja, voor je dit gaat doen maak een volledige back-up. Mocht je restore de mist in gaan dan kan je de DB herstellen. Of als het kan doe de restore in een aparte instance van SQL Server. Dan blijft je oude DB beschikbaar en kan jij rustig restoren. Anders heb je enorme tijdsdruk om de DB weer aan je gebruikers beschikbaar te stellen.

  • CMD-Snake
  • Registratie: Oktober 2011
  • Laatst online: 13-11-2022
Nog ter aanvulling, de documentatie van MS over restoren van 2005 t/m 2012:
MSDN: Restore a Database Backup (SQL Server Management Studio)

Restoren met transaction logs:
MSDN: Restore a Transaction Log Backup (SQL Server)

Hier wordt ook beschreven hoe je het via GUI kan doen als je dat prettiger vindt.

[ Voor 36% gewijzigd door CMD-Snake op 28-09-2012 10:55 . Reden: extra linkje ]


  • GeleFles
  • Registratie: Augustus 2001
  • Niet online

GeleFles

What's in a bottle?

Topicstarter
Thnx! Ik ga eens kijken of ik hiermee uit de voeten kan, het is inderdaad nog de vraag of de logfile de data wel bevat...

Ik ben inderdaad niet helemaal thuis in SQL, ben 'gewoon' een netwerk/systeembeheerder, geen databasebeheerder ;)

  • CMD-Snake
  • Registratie: Oktober 2011
  • Laatst online: 13-11-2022
RonnieB82 schreef op vrijdag 28 september 2012 @ 12:08:
Thnx! Ik ga eens kijken of ik hiermee uit de voeten kan, het is inderdaad nog de vraag of de logfile de data wel bevat...

Ik ben inderdaad niet helemaal thuis in SQL, ben 'gewoon' een netwerk/systeembeheerder, geen databasebeheerder ;)
Ik ben ook systeembeheerder, maar doe er wel wat DBA taken bij. ;)

Wat is eigenlijk de fout die nu in je DB zit?

Let op dat als je gaat restoren vanaf de logs dat je dan dataverlies zal hebben. Als je naar een point in time van twee maanden geleden gaat dan heb je data verlies van die datum tot aan het heden. Je kan alles wat daarna komt niet restoren want dan herintroduceer je de fout vanuit je back-ups.

Controleer dus of dit dataverlies acceptabel is. Als de DB is voor bijvoorbeeld alle verkopen die je bedrijf doet dan lijkt het me niet fijn als twee maanden aan data weg is. (Om het maar even zacht te zeggen....)

  • chaoscontrol
  • Registratie: Juli 2005
  • Laatst online: 10:01
Ter aanvulling op de wijsheid van CMD-Snake wil ik je aanraden dit lokaal te doen!!

Voordat mijn SQL server kennis zo uitgebreid was, werd mij gedwongen een lokale instance te hebben draaien en altijd alleen daarop te werken tot het perfect was. :)

Dit moet natuurlijk wel kunnen, eventueel een testomgeving!

Inventaris - Koop mijn meuk!


  • CMD-Snake
  • Registratie: Oktober 2011
  • Laatst online: 13-11-2022
Verdiep je ook in het restore mechanisme van SQL Server. Je kan er heel veel mee. Naast de complete restore kan je er ook voor kiezen om alleen zaken als een tabel of zelfs enkele rows te herstellen vanuit een back-up. Zie bijvoorbeeld hier hoe je een table herstelt vanuit een back-up:
How to retrieve a specific table or rows from database backups or transaction log backups in SQL Server

Met wat creativiteit kan je heel ver komen en restores doen met nagenoeg geen dataverlies. Uiteraard ben je wel in deze afhankelijk van je back-up strategie en hoeveel back-ups je tot je beschikking hebt.

Vergeet overigens niet na je restore actie een integriteit check te doen op de database. (DBCC CHECKDB commando).
Pagina: 1