SQL database backuppen vanuit database zelf

[Verwijderd]

Ik draai een VM op VMWare, echter heeft deze een corrupte delta file.
Net een laatste gedeelte van een SQL database staat in deze file.
De database is ca. 300GB groot.

De VM clonen gaat niet, want dan loopt hij vast en geeft de melding over
REDO LOGS en een corrupte delta disk. De disken aan een andere server
attachen heeft ook geen nut. Daarnaast heb ik geprobeerd om een SQL
backup te maken, helaas valt de server aan het eind er dan ook uit.
Ook heb ik de SQL server gestopt en de MDF file zelf naar een andere locatie
gekopieerd, helaas ook dan bij de laaste ca. 5 GB komt hij weer bij die corrupte
file en valt alles eruit.

Het vreemd is wel dat de database nog perfect in SQL draait, hij is de te starten
en er kan continu in gewerkt worden. VMWare adviseerde een clone
te maken met VMConverter vanuit de VM, helaas ook dan klapt hij eruit.

Is er een optie dan ik de database vanuit SQL zelf kan backuppen want daar draait hij
dus wel. Ik kan momenteel alleen geen backups meer maken en de server is niet 100% meer.

Iemand een tip?

[Oyster]

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

If MySQL that is?

[ Voor 12% gewijzigd door Oyster op 14-07-2013 16:41 ]

[Verwijderd]

Sorry, het is een MSSQL database. Dat had ik niet juist vermeld.
Ik draai SQL 2008 R2.

[Tarabass]

Je zou kunnen backuppen met smss tools. Die heeft handige opties om handmatig insert-statements etc. te genereren. Maar let wel, dit moet je dan dus allemaal handmatig doen. De addon is sowieso het proberen waard

[CMD-Snake]

Als de corruptie van de database zelf is zou je nog het DBCC CHECKDB commando kunnen draaien en kijken of die het op kan lossen.

Als je dit commando draait zonder repair flag dan geeft het suggesties slechts. Altijd handig om eerst te kijken wat het commando kan vinden. Met de repair toevoeging gaat het commando proberen om het probleem op te lossen. Let wel dat je mogelijk dataverlies zal hebben.

Overigens als je op Google zoekt komt er nog een berg aan tooltjes uit die corrupte MDF files kunnen repareren voor je. Sommigen claimen ook zonder dataverlies te kunnen werken. Ik heb geen ervaring met die tooltjes verder.

[demokert]

Ik zou eerst eens een DBCC CHECKDB doen op de database in kwestie. Kijk even wat eruit komt en neem een vervolg actie;
MSDN: DBCC CHECKDB (Transact-SQL)

Normaal gesproken zou je de MDF en LDF mogen kopieren / knippen mits SQL Server service niet aanstaat.

Zie je überhaupt foutmeldingen als je kopieert of in de eventlog ?

Andere opties;
Ik neem aan dat je al een nieuwe VM klaar hebt staan om de zaak naartoe te migreren, je zou een copy database actie kunnen uitvoeren zodat je hem kopieert naar de nieuwe locatie. Een andere optie is mirroring.

Haal je laatste FULL backup terug en de daarop volgende Transactionlogs. En restore deze tot aan de gewenste tijd.

Succes!

[Verwijderd]

Maar heeft een DBCC CHECKDB nut? De file zelf staat namelijk over meerdere delta files van VMWare verdeeld waarvan er een corrupt blijkt te zijn. (ofwel de disk waarop de db staat)
Uiteraard heb ik al geprobeerd de file naar een nieuwe server te kopieren, echter klapt de VM er dan uit bij 294 GB ofwel de laatste 6GB mis ik dan. Attachen van de database lukt dan ook niet, omdat de file niet compleet is.

Echter draait de database dus wel op de server met het corrupte delta file.
Ik kan alleen geen backup maken, of de file kopieren, want dan stopt de VM met de een redo log melding. http://kb.vmware.com/self...playKC&externalId=1006585

Mirroring is geen optie, al vraag ik me af of dit wel zou werken.
Dit omdat het een 2008 R2 web edition server is.
De laatste Full backup terug halen ook niet, omdat we dan veel te veel data missen.

[CMD-Snake]

Verwijderd schreef op zondag 14 juli 2013 @ 20:53:
Maar heeft een DBCC CHECKDB nut? De file zelf staat namelijk over meerdere delta files van VMWare verdeeld waarvan er een corrupt blijkt te zijn. (ofwel de disk waarop de db staat)
Uiteraard heb ik al geprobeerd de file naar een nieuwe server te kopieren, echter klapt de VM er dan uit bij 294 GB ofwel de laatste 6GB mis ik dan. Attachen van de database lukt dan ook niet, omdat de file niet compleet is.

Echter draait de database dus wel op de server met het corrupte delta file.
Ik kan alleen geen backup maken, of de file kopieren, want dan stopt de VM met de een redo log melding. http://kb.vmware.com/self...playKC&externalId=1006585

Mirroring is geen optie, al vraag ik me af of dit wel zou werken.
Dit omdat het een 2008 R2 web edition server is.
De laatste Full backup terug halen ook niet, omdat we dan veel te veel data missen.

Je kan het DBCC DBCHECK commando altijd proberen, je bent al op een punt dat het weinig uitmaakt.

Wat gebeurt er als je een table o.i.d. wil oproepen in het corrupted deel? Je DB draait nog, maar misschien puur omdat die niet vaak in die corrupte file hoeft te zijn.

Mirroring ligt aan je SQL Server versie, niet je OS versie. De Standard, Enterprise en Datacenter versies kunnen een mirror maken.

[Verwijderd]

Je bedoeld dat ik de DBCC DBCHECK doe op de huidige database welke in de omgeving
draait met de corrupte deltafile? Ik heb nog wel een backup, is er dan ergens een handige manier
om deze snel bij te werken met de gewijzigde data in de database die op de corrupte disk staat?

Je hebt inderdaad gelijk dat de OS versie niet uit maakt, we draaien SQL Server 2008 R2 Web Edition
Mijn excuus.

[GlowMouse]

Als de db echt belangrijk is, moet je nu stoppen met prutsen en iemand met MSSQL expertise inhuren. In beginsel heb je alleen de tabeldata zelf nodig, niet de indices. Die laatste 5 GB is dus wellicht niet eens nodig. Als de data zelf onbereikbaar is, kan de data misschien juist uit een index of logfile gehaald worden.

[Verwijderd]

Glowmouse, bedankt voor je reactie, we hebben MSSQL expertise in huis deze mensen gaan dit uiteraard ook doen. Maar ik vroeg mij even af of dit mogelijk is. Ik heb wel jou reactie met ze gedeeld.

[Turdie]

[code=sql]USE AdventureWorks2008R2;
GO
BACKUP DATABASE AdventureWorks2008R2
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2008R2.Bak'
WITH FORMAT,
MEDIANAME = 'Z_SQLServerBackups',
NAME = 'Full Backup of AdventureWorks2008R2';
GO
[/code=sql]

Had je zelf toch ook wel kunnen vinden:
How to: Create a Full Database Backup (Transact-SQL)

[ Voor 62% gewijzigd door Turdie op 15-07-2013 16:10 ]

[leuk_he]

GlowMouse schreef op maandag 15 juli 2013 @ 13:08:
Als de db echt belangrijk is, moet je nu stoppen met prutsen

Mee eens, maar een expert gaat of ook prutsen, of gaat je keihard naar de backup verwijzen(waar wellicht stiekum ook iets mee aan de hand is?)

Dus met aloude SQL tools create table scripts (etc etc) en insert statement scripts genereren. Doe dit laatste echt tabel voor tabel, zodat als er fouten langs komen je weet waar het fout zit.

Ik neem aan dat je zelf handig genoeg bent om die tools te vinden.

[Verwijderd]

Shadowman, ik weet hoe je Full Database Backups kunt maken, echter gaat dit momenteel niet meer omdat een gedeelte van de database zich op een corrupte delta file bevind. (dit is een stukje van de disk, snapshot stuk, in VMWare)

Het zal waarschijnlijk zo moeten gaan als 'leuk_he' al zegt, met scripts en statements alles tabel voor tabel gaan overzetten.En op die manier de backup database bijwerken met de nieuwe data.

[GlowMouse]

leuk_he schreef op maandag 15 juli 2013 @ 16:12:
[...]


Mee eens, maar een expert gaat of ook prutsen, of gaat je keihard naar de backup verwijzen

Ik weet dat er voor MySQL mensen zijn die alle ins-en-outs van de storage engine kennen, en daardoor gericht data terug kunnen halen. Dat valt niet meer onder prutsen. Duur is het wel

[demokert]

Je zegt dat je backups hebt, maar oude? dat begrijp ik niet helemaal... Ik ben zelf MSSQL DBA en 1 van de primaire taken van een DBA of een Systeembeheer vind ik persoonlijk dat er altijd (dagelijks) backups worden gemaakt van je systemen. Daarnaast maken wij minimaal elk uur een transactielog waardoor wij als het nodig mocht zijn een point in time restore kunnen uitvoeren.
Wordt jullie VM locatie gemirrord uitgevoerd? Dan zou je eens kunnen kijken of de VM op de gemirrorde omgeving nog wel in orde is of niet.

En ik zou zeker ook een poging doen om backups terug te halen + zeker een DBCC CHECKDB uitvoeren met dan maar dataloss als het überhaupt nog mogelijk is.

Mocht je nou geen up2date backup hebben, dan is bij deze ook direct bewezen dan een disaster recovery bij jullie heel moeilijk gaat worden.

[ Voor 9% gewijzigd door demokert op 15-07-2013 19:32 ]

[Verwijderd]

Demokert, er wordt dagelijks een backup gemaakt. Meerdere keren per dag zelfs. Echter wordt er wel continu data weg geschreven. En sinds de corrupte data file er is, kan er geen backup meer gemaakt worden en de database is nog wel live. Ofwel er ontstaat een steeds groter verschil tussen de live database en de backup. We hebben wel een HA oplossing, maar de VM zelf wordt niet gemirrord.
En als ik kijk naar de belasting van de disks. (nu al 15K met cachcade) dan denk ik dat dit ook niet mogelijk is.

Echter nu blijkt dat onze MSSQL mensen dit ook te boven gaat.
Mocht iemand hier iemand kennen bij deze ik ben met spoed op zoek naar een SQL expert
voor deze klus. Uiteraard tegen vergoeding.

[Question Mark]

Verwijderd schreef op dinsdag 16 juli 2013 @ 09:48:
En sinds de corrupte data file er is, kan er geen backup meer gemaakt worden en de database is nog wel live. Ofwel er ontstaat een steeds groter verschil tussen de live database en de backup.

Zolang je database model op full recovery staat is dat toch gewoon met je transaction logs recht te trekken?

[Verwijderd]

Dat staat hij wel. Hoe zou dat dan werken? En ik begreep wel dat de logs af en toe geleegd worden.

[demokert]

Met full recovery is het inderdaad zoals ik ook al eerder heb vermeld mogelijk om een point in time restore to doen.
De logs worden geleegd als een transaction log gemaakt wordt.

Dus dit zou zijn Full restoren met NORECOVERY en daarna je Tlogs met RECOVERY.
Zie voorbeeld;
MSDN: Performing a Complete Database Restore (Simple Recovery Model)

[ Voor 11% gewijzigd door demokert op 16-07-2013 20:55 ]

[Turdie]

demokert schreef op dinsdag 16 juli 2013 @ 20:50:
Met full recovery is het inderdaad zoals ik ook al eerder heb vermeld mogelijk om een point in time restore to doen.
De logs worden geleegd als een transaction log gemaakt wordt.

Dus dit zou zijn Full restoren met NORECOVERY en daarna je Tlogs met RECOVERY.
Zie voorbeeld;
MSDN: Performing a Complete Database Restore (Simple Recovery Model)

De logs worden ook geleegd als je een full database backup doet of een log backup doet of als je je logs shrinkt. Met simple recovery model kun je geen transaction log restore doen omdat dan automatisch je transactie log geleegd wordt om de transactie log klein te houden. Omdat die vaak kan vollopen als je transactie log op een bepaalde size heb gezet tijdens de inrichting van je SQL instance, vooral als er veel transacties op de database worden uitgevoerd!
Recovery Models (SQL Server)

Het kan alleen met een full recovery model zoals jij ook aangeeft.
Restore a SQL Server Database to a Point in Time (Full Recovery Model)

Heb je trouwens een VM backup van je virtuele disken? Misschien kun je dan alleen die corrupte virtuele disk terugzetten en hoef je niet aan gang met SQL backups en restores?

[ Voor 117% gewijzigd door Turdie op 16-07-2013 22:19 ]

[Verwijderd]

Hij draait inderdaad met een Full Recovery model.
Maar ik zou dan een oude database backup kunnen pakken, en deze kunnen recoveren
met de log file van de nieuwere corrupte database?

Ik heb geen backup van de virtuele disken.
Echter is het een delta file die corrupt is.
We werken met Veeam, deze maakt snapshots om te kunnen backuppen
ofwel dan krijg je de disk + deltafile. We hebben replica's en backups.
Maar daaruit kan ik niet de delta file halen helaas.
Overigens geeft VMWare ook aan dat een corrupte datafile niet te fixen is...

[Turdie]

Verwijderd schreef op dinsdag 16 juli 2013 @ 22:33:
Hij draait inderdaad met een Full Recovery model.
Maar ik zou dan een oude database backup kunnen pakken, en deze kunnen recoveren
met de log file van de nieuwere corrupte database?

Ik heb geen backup van de virtuele disken.
Echter is het een delta file die corrupt is.
We werken met Veeam, deze maakt snapshots om te kunnen backuppen
ofwel dan krijg je de disk + deltafile. We hebben replica's en backups.
Maar daaruit kan ik niet de delta file halen helaas.
Overigens geeft VMWare ook aan dat een corrupte datafile niet te fixen is...

Ja,als die logfiles niet corrupt zijn. Wat me handig lijkt in dit geval om de restore eerst te doen in een test omgeving en kijken of je database helemaal goed gerestored worden en het dan op dezelfde manier waar de delta file corrupt is.

Je zou toch ook een nieuwe VM kunnen aanmaken en daarheen je VM backup restoren en dan de corrupte VM archiveren (nadat je alles getest hebt uiterraard).

[ Voor 20% gewijzigd door Turdie op 16-07-2013 22:39 ]

[Verwijderd]

Uiteraard. Er is al een nieuwe VM aangemaakt, echter daaraan is de disk attached met de corrupte deltafile met de daarop de database. Deze is op geen mogelijkheid meer daar vanaf te backuppen of te kopieren, omdat de server/vm dan uitvalt als je bij het corrupte deel van de disk komt.
Ik ga proberen de backup terug te zetten, en deze bij te werken aan de hand van de log file.
Kan ik ergens zien welke data de logfile bevat?

[Turdie]

Verwijderd schreef op woensdag 17 juli 2013 @ 00:06:
Uiteraard. Er is al een nieuwe VM aangemaakt, echter daaraan is de disk attached met de corrupte deltafile met de daarop de database. Deze is op geen mogelijkheid meer daar vanaf te backuppen of te kopieren, omdat de server/vm dan uitvalt als je bij het corrupte deel van de disk komt.
Ik ga proberen de backup terug te zetten, en deze bij te werken aan de hand van de log file.
Kan ik ergens zien welke data de logfile bevat?

Maar dus de VM backup heeft ook de corrupte VM datafile? Je kunt volgens mij niet welke data de log bevat, daar staan in principe alleen de SQL tranacties in die op de database zijn uitgevoerd, en door die restoren worden die transacties opnieuw op de database uitgevoerd.

[ Voor 11% gewijzigd door Turdie op 17-07-2013 00:14 ]

[Verwijderd]

De vm wordt gebackupt met Veeam, en eveneens gerepliceerd.
Echter doordat er zoveel transacties in de database plaats vinden, is deze als snel te oud.
VMWare dacht het te kunnen fixen, en we grepen toen nog niet naar de backup/replica.
(welke elk 30 minuten gemaakt wordt)
Echter begeven moment vertelde VMWare dat het niet meer te redden was.
De backup loopt nu dus erg achter bij de brakke database.

[Turdie]

Verwijderd schreef op woensdag 17 juli 2013 @ 00:15:
De vm wordt gebackupt met Veeam, en eveneens gerepliceerd.
Echter doordat er zoveel transacties in de database plaats vinden, is deze als snel te oud.
VMWare dacht het te kunnen fixen, en we grepen toen nog niet naar de backup/replica.
(welke elk 30 minuten gemaakt wordt)
Echter begeven moment vertelde VMWare dat het niet meer te redden was.
De backup loopt nu dus erg achter bij de brakke database.

Ok, er is wel een tool voor (om data in de SQL logfile te bekijken) ApexSQL Log, waarmee je de data kan zien in de logfile trouwens. Toad kan hetzelfde. Ook tooling van Red Gate zou het moeten kunnen.

[Meekoh]

Ik denk je de meeste kans op succes hebt wanneer je de hele DB script.
Dus Create table scripts voor de tabellen, INSERT scripts voor de data etc.
Ik weet dat Red gate daar erg goede tools voor heeft, welke ik in het verleden ook nog weleens heb gebruikt.

[demokert]

Meekoh schreef op woensdag 17 juli 2013 @ 11:31:
Ik denk je de meeste kans op succes hebt wanneer je de hele DB script.
Dus Create table scripts voor de tabellen, INSERT scripts voor de data etc.
Ik weet dat Red gate daar erg goede tools voor heeft, welke ik in het verleden ook nog weleens heb gebruikt.

Als je dat gaat doen op een database in deze kwestie (360GB) krijg je een gigantisch script(s) wat er wellicht voor zorgt dat je client crasht door memory problemen.

Het is een longshot maar ben bang dat dat niet echt gaat werken.

[Question Mark]

Wat is het probleem nu eigenlijk?

uitgangspunten die je momenteel hebt:

• Je database staat in full recovery model
• Je hebt een backup van je database (welliswaar oud, maar dat maakt niet uit)
• Je hebt de transaction logs sinds de laatste full backup nog
• Je hebt inmiddels een extra server draaien met SQL erop

Dan is het met de link die Shadowman12 al gaf toch relatief eenvoudig om de database te restoren?
(MSDN: Restore a SQL Server Database to a Point in Time (Full Recovery Model))

Dat had je toch alang kunnen testen?

[demokert]

/mierenneuken
Dat gaf ik al eerder aan

[Question Mark]

Weet ik (en meerdere overigens), daarom verbaast het me eigenlijk enisgzins ook dat TS dit nog niet uitgevoerd/getest heeft... Zeker op de testserver die TS al heeft, kan dit zonder risico getest worden.

[demokert]

Ik heb het gevoel dat er geen DBA bij betrokken is. Want dit is allemaal vrij standaard werk.