sql-server restore

[engel.aloisius 10]

guten morgen zusammen (obwohl er angesichts meines problemes kein guter zu werden scheint :rolleyes: )

 

ich habe hier einen gecrashten sql2000/sp4 server. der ist im betrieb gestorben, die daten- und sicherungsfiles files konnten aber vom raidset restored werden.

nun wurde der neue server aufgesetzt und die daten sollen wieder zurück - allerdings funktioniert das nicht so, wie es soll - nämlich gar nicht.

 

ich habe die restore-procedures für mdf- und ldf-files versucht - abbruch. ich habe die bak-files der internen sicherung versucht - abbruch. seltsamer weise bekomme ich immer diesen MTF-fehler:

 

Die Datei auf Medium 'c:\xxxxxxxxx.mdf' ist kein gültiger MTF-Sicherungssatz (Microsoft Tape Format). RESTORE DATABASe wird fehlerbedingt beendet.

 

kann mir wer helfen, was ich mit dem soll bzw. wie ich das lösen kann??

[deubi 10]

Mir ist da nun eins nicht klar:

 

Du schreibst einerseits von BAK-FIles, die Du restoren willst, andererseits von MTF.

Ja was denn nun?

Die BAK-Files kommen ja sicher nicht vom Tape; die Bak-Files sind aber nur die Backups der DB-Files; wie siehts mit den TRN's (Backup der TLog's) aus?

 

Übrigens: ein Desaster-Recovery-Szenario ist etwas, das man eben zumindest sporadisch mal durchziehen MUSS :rolleyes:

[deubi 10]

P.S: wenn die Originalen FIles des "gestorbenen Servers" noch verfügbar sind, und Du die Logins am SQL-Server sowie die Security händisch einrichten kannst, kannst Du die MDB- und LDF-Files auf den neuen Server rüberkopieren und dort attachen, mit minimalstem Zeitaufwand.

Auch DAS gehört in ein DesasterRecovery-Szenario...

[engel.aloisius 10]

P.S: wenn die Originalen FIles des "gestorbenen Servers" noch verfügbar sind, und Du die Logins am SQL-Server sowie die Security händisch einrichten kannst, kannst Du die MDB- und LDF-Files auf den neuen Server rüberkopieren und dort attachen, mit minimalstem Zeitaufwand.

 

hallo deubi, danke für die rasche hilfe erstmals ...

 

@dateien. ich hab sowohl die ldf und mdf files aus dem datenoriginalverzeichnis retten können. zudem sind die bak-files der eingebauten sicherung über tage hinweg vorhanden. interessanter weise tritt auch bei "datenbanken / wiederherstellen" mit dem BAK-file ein fehler auf, dass "die medienfamilie vom Medium "path/file.bak" ungültig" ist und der "server die medienfamilie nicht verarbeiten kann" ... habe versucht beim wiederherstellen das BAK-file über die option "von medium" einzulesen - ist das etwa falsch?

 

@einrichten: also die zugangscodes des alten servers sind bekannt, was meinst du mit security?? kannst du mir da einen tipp geben?

 

@szenario: ich weiß, der kunde hats aber nicht gemacht und jetzt können wir es *ausbaden* ...

[deubi 10]

ach so, keine Eigeninstallation. --> Arbeitszeit --> verrechenbar. Kein Problem

 

Mit der Security meine ich die ganzen Logons, Passwörter etc innerhalb SQL mit den Settings der StandardDB's der Logins usw. Diese Daten sind im EntrepriseManager unter "Security" zu finden.

 

Wenn Du die mdb- und ldf-Dateien hast, und die Security sonst rekonstruieren kannst, brauchst Du die Backups nicht.

 

Ich habe die ganzen Tapegeschichten nicht mehr im Kopf; ich sichere SQL NIE auf Tape direkt, sondern habe maintenancePlans, die Files generieren (Bak & TRN), die werden wiederum mittels Tapebackup (Veritas) auf einer Jukebox "getaped".

 

Ich meine mich aber zu erinnern, dass die Kataloge sich in einer der SystemDB's befinden; da Du die ja nicht wiederhergestellt hast, kriegst Du diese Fehlermeldung. Aber die Tapegeschichten waren noch nie meine Stärken, da kann ich leider nicht weiterhelfen :rolleyes: (die OnlineReferenz vom SQL-Server ist allerdings sehr stark!)

 

Hast Du mal versucht, die alten User-Datenbanken mittels "attach" anzuhängen?

[engel.aloisius 10]

ach so, keine Eigeninstallation. --> Arbeitszeit --> verrechenbar. Kein Problem

 

naja, pauschalierter kunde, also in gewisser weise doch einproblem :shock:

 

soweit ich weiß, war der modus gemischt, die anmeldung über die alte, nun natürlich nicht mehr vorhandene domäne möglich (auf admin-ebene)

 

@sicherung: Alle files, die ich versucht habe zurückzusichern stammen aus dem datenfileverzeichnis des sql-servers (also dir mdf und ldf-files), die bak-files aus der eingebauten sicherung, die in ein verzeichnis gesichert hat - drum wundert mich das umso mehr :suspect:

 

es ist gerade noch ein veritas tape aufgetaucht - allerdings weiß ich nicht, wie ich damit am besten umgehen soll ... soll ich den gesamten sql-stamm zurücksichern? wär wahrscheinlich klug, weil du ja erwähnt hast, dass da gewisse einstellungen mit dabei sein müssen, die in der master-db gespeichert sind.

aber wenn ich die zurücklese, werden wahrscheinlich jetzt schon angelegte dbs verloren gehen, oder?

[deubi 10]

Also, falls Du mit SQL nicht so sattelfest bist - so mein Eindruck, entschuldige, wenn ich falsch liege- und nicht direkt auf jemanden zurückgreifen kannst, der Dich da tatkräftig unterstützen kann, würde ich Dir DRINGENDST empfehlen, das Ganze in einer Testinstallation zu machen; d.h. dort die Daten zu restoren und auszuprobieren, ob und wie Du alles rekonstruieren kannst, und ERST DANN, wenn das klappt, das dann auch beim Kunden machst.

Pauschalkunden? Wenn Euer Verkauf sowas offeriert, müsst Ihr eigentlich zumindest einen SQL-Spezi haben. Wie sieht's damit aus? :suspect:

 

Entnehme ich das Deinem Posting vorhin richtig: der Server war nicht bloss SQL-Server, sondern auch gleich noch DC? :shock:

Oder habe ich falsch verstanden, was Du meinst? Bei der gemischten Authentifizierung (nicht Modus) haben die lokalen Admins des Servers auch sa-Rechte in SQL, das ist nicht abhängig von der Zugehörigkeit zu einer Domäne.

[engel.aloisius 10]

du liegt bei vielem richtig ...

 

... ich bin nicht allzu sattelfest, wenns um troubleshooting von dem ding geht. fang grad erst an, weil uns unser sql-mann verlassen hat.

... der sql-server war auf einer SBS2000-installation, da gehts leider nicht anders. als DC und SQL in maschineller personalnunion

... wär ja ideal, wenn es in der testinstallation klappen würde, dann ließe sich von dort ja die DB korrekt sichern und (hoffetnlich) auch korrekt am neuen server anhängen - oder hab ich da jetzt einen denkfehler.

 

@offtopic: gibts eine möglichkeit, ein ganzes tape auf eine platte zu kopieren und von dort dann die sicherung zurückzufahren? juckt mich gar nicht, das bandlaifwerk aus der kiste auszubauen ...

[deubi 10]

... wär ja ideal, wenn es in der testinstallation klappen würde, dann ließe sich von dort ja die DB korrekt sichern und (hoffetnlich) auch korrekt am neuen server anhängen - oder hab ich da jetzt einen denkfehler.

 

@offtopic: gibts eine möglichkeit, ein ganzes tape auf eine platte zu kopieren und von dort dann die sicherung zurückzufahren? juckt mich gar nicht, das bandlaifwerk aus der kiste auszubauen ...

 

 

Ich würde erstmal die ja laut Deiner Aussage noch vorhandenen DB-Files mal in einer SQL-Testumgebung zu attachen versuchen. Wenn DAS klappt, dann hast Du bereits eine grosse Hürde überwunden; dann kannst Du Dir m.E. die Geschichte mit dem Band ersparen, soweit es SQL betrifft. Sofern Du eben die Security in SQL hinbiegen kannst.