DFSR winzige backup-wiederherstellung löst datenbankrebuild aus

[g1n 10]

hi leute,

 

ich hab gestern spaßeshalber mal das wiederherstellen einzelner dateien von einer dfsr-sicherung ausprobiert, mit erschreckendem ergebnis :( details:

 

das backup erfolgte von einem dfsr-verzeichnis mit ~200gb daten mit backup exec 11d auf lto2-tape. d.h. das sichern der dfsr-daten lässt sich ja nur über die volume-shadow-copy dienste bewerkstelligen. die sicherung war erfolgreich. alle daten sind vorhanden und katalogisiert.

 

um die sicherung zu testen, hab ich aufs entsprechende tape geklickt und "daten wiederherstellen" gewählt. ich hab vorerst die daten-wiederherstellung in einen anderen ordner umgeleitet, ohne erfolg. nach "erfolgreichem wiederherstellungsauftrags" war dass zielverzeichnis leer! IST DAS NORMAL?

 

danach hab ich es bei den standardeinstellungen gelassen, was dann auch die daten ins ursprungsverzeichnis wiederhergestellt hat. einige sekunden nach der erfolgreichen wiederherstellung wurde autom. vom DFSR-Dienst eine datenbank-wiederherstellung angestoßen. war natürlich klasse weil dann erstmal die i/o last entsprechend angestiegen ist.

 

das "witzigste" zum schluss. der server auf dem die initial-replikation stattgefunden hat war natürlich nicht primary-member. demzufolge wurde ein vergleich mit dem primarymember gemacht, auf dem die wiederhergestellten daten bereits gelöscht waren. demzufolge waren nach dem vergleich die wiederhergestellen wieder verschwunden :shock:

 

kann ich einzelne daten irgendwie wiederherstellen ohne dabei das obene genannte prozedere zu durchlaufen?

 

gruß g1n

–

ich scheine mit meinen anfragen wirklich kein glück zu haben. ich habe probleme die bei anderen scheinbar nie auftreten :(

–

Okay,

 

nach etlichen Versuchen kam ich zur Lösung:

 

Die Dienste "DFS-Replikation" und "Verteiltes Dateisystem (DFS)"

müssen vor Beginn des Restores gestoppt werden. Dann scheint

alles ohne Probleme zu funktionieren. *ironie an* Wie gut dass das gleich in jeder

Dokumentation zu DFSR offentsichtlich ist!*ironie aus*

 

Gruß g1n

[olc 18]

Hallo,

 

zu Deiner Grundproblematik spare ich mir jetzt meine Zeilen, da das Problem ja "gelöst" ist. ;)

 

Nur soviel dazu: Die Initialreplikation nach einem DB-Rebuild ist vollkommen korrekt und zumindest im Moment nicht änderbar. Daß die DB jedoch überhaupt beschädigt wurde, ist durchaus ein Problem. Da hat die Backup Applikation wohl einiges falsch gemacht...

 

Weiterhin muß die Backup Applikation dafür sorgen, daß die wiederhergestellten Daten authorativ sind. Auch hier ist nicht der DFS-R Dienst "Schuld", wenn es bei Dir nicht wie gewünscht geklappt hat.

 

Okay,

 

nach etlichen Versuchen kam ich zur Lösung:

 

Die Dienste "DFS-Replikation" und "Verteiltes Dateisystem (DFS)"

müssen vor Beginn des Restores gestoppt werden. Dann scheint

alles ohne Probleme zu funktionieren. *ironie an* Wie gut dass das gleich in jeder

Dokumentation zu DFSR offentsichtlich ist!*ironie aus*

 

Gruß g1n

 

Das hat rein gar nichts mit dem DFS-R Dienst zu tun, das ist Sache der Backup Applikation. Jede Wette, daß Du dazu in der Supportdatenbank des Backup Software Herstellers einen entsprechenden Eintrag findest. :)

 

Im Normalfall muß der Dienst nicht neu gestartet werden, das ist nur ein Workaround vieler Hersteller, die leider teilweise immer noch nicht in der Lage sind, korrekt mit DFS-R umzugehen.

 

Es ist im Normalfall auch davon abzuraten, den Dienst immer wieder neu zu starten. Je nach Volumen der replizierten Daten des jeweiligen Servers kann dies zu starken Verzögerungen der Replikation und allen daran angrenzenden Problemen innerhalb der DFS-R Struktur kommen.

 

Viele Grüße

olc

[g1n 10]

ich danke dir für diese aufschlussreichen worte, jetzt wird mir so einiges klar :)

ich werd gleich nochmal bei symantec in der KB schauen. evtl. hab ich ja doch etwas

übersehen.

 

zum neustart des dienstes:

ja, wenn der dienst häufig neugestartet wird ist das tatsächlich der fall, hier aber nicht. es war ja nur ein test ob sich tatsächlich auch daten aus dem backup reproduzieren lassen. der fall das es auch tatsächlich mal genutzt wird, wird wohl nur einmal im jahr auftreten (oder im desasterfall), da die meisten recovery-geschichten über die volumenschattenkopien laufen (beim thema "oh ich hab ausversehen was überschrieben").

 

da der server auf den die wiederherstellung erfolgen würde, eh passiv in der DFS-R-topologie agiert, würde es nicht aufallen wenn dort etwas verzögert würde. mit passiv meine ich, der server selbst repliziert nur daten zu anderen server wenn auf ihm daten geschrieben werden (d.h. im recoveryfall). da er nur ein failover-server ist bekommt er nur daten vom primary member überreicht. aktiv wird er erst wenn der primary ausfällt. dann übernimmt dieser server dessen rolle.

 

nochmal danke für die äußerst hilfreiche antwort! :)

 

gruß g1n

[olc 18]

Hi g1n,

 

schön, daß Dir die Zeilen ein wenig weiterhelfen konnten.

 

Wie oben angesprochen findest Du zu dem Thema bei diversen Backup Anbietern Einträge, so z.B.: symantec backup dfsr - Google-Suche

 

Oftmals bieten Backup Applikationen, die zumindest DFS-R "kennen", eine Option an, die Daten bei der Wiederherstellung autorativ zu markieren. Klick Dich einfach mal durch die Restore Dialoge bzw. Optionen.

 

Warum die Datenbank jedoch beschädigt wurde bleibt ein "Rätsel" - hier solltest Du in jedem Fall prüfen, inwieweit das mit dem Backup / Restore Versuch zusammenhängt. Das kann im Ernstfall zu Problemen führen - ein Backup ohne funktionierende Rücksicherung ist im Regelfall nicht erwünscht. ;)

 

Viele Grüße

olc