Veritas SQL-Datenbanken Sicherung

[xtragood 10]

Hi Leutz,

 

hat jemand von euch Veritas Backup Exec im Einsatz?

 

Ich hab nämlich am Wochenende brandheiss bemerkt, dass unsere Datenbanken aufgrund fehlendem SQL-Plugin, nicht mitgesichert wurden...

 

Ich hab dann erfahren, dass man Befehle definieren kann, um den SQL Server vor dem Job zu stoppen, und danach wieder zu starten.

 

Reicht es aus, wenn ich einfach den Befehl "net stop mssqlserver" und "net start mssqlserver" vor und nach dem Job ausführen lasse... oder muss ich die Befehle in ein Script schreiben, dass ich dann beim Job angebe?

 

 

Gruß, xtra.

[substyle 20]

Hallo !

 

Ich bevrzuge zwei Möglichkeiten:

 

SQL Agent für Veritas kaufen (ca. 700€ glaube ich)

das ist die sehr komfortable Lösung des ganzen.

 

SQL über den SQL eigenen Agenten sichern. Und diese Files

dann "normal" mit Veritas aufs Band sichern.

 

Ich hoffe du versuchst nicht die ldf bzw. mdf dateien so zu sichern .. :eek:

 

subby

[xtragood 10]

Das soll so gemacht werden. Was würde dagegen sprechen?

 

Und das ist laut meinen Informationen die "gängige" Lösung...

[substyle 20]

Zum einen werden die Dateien beim Sichern nicht auf

Konsistenz geprüft, viel schlimmer jedoch ist, das beim Sichern

der mdf/ldf's die Daten aus dem Transaktionsprotokol verloren

gehen.

 

Als "gängig" würde ich das nicht bezeichnen. Ich glaube auch nicht

das MS das so vorsieht. Habe auch nicht dergleichen gelesen.

 

subby

 

Nachtrag:

 

Denke gerade mal etwas weiter, wenn man SQL stoppt werden die

transaction logs ja reingeschrieben, aber ich habe schon so mache

probleme mit dem wiedereinbinden von "online" gesicherten

sql db's gehabt.

[xtragood 10]

Hi nochmal,

 

aber die Datenbanken sind nach dem Stoppen des Servers nicht mehr online, sondern offline.

 

Die Transaktions-Logs interessieren uns nicht weiter, stehen eh auf simple...

 

 

Wäre nett, wenn ich einfach nur wüsste, ob ich das über ein Script machen muss oder den Befehl allein beim Job reinschreiben kann?

 

 

Gruß, xtra.

 

 

PS: 700€ für'n Plugin ist uns in Relation zur Verwendung zu viel... ;)

[Velius 10]

@substile

 

Hast du schonmal versucht die DB's auf einen neuen SQL einzuspielen? Offenbar werden da ja noch Daten vom Master benötigt, und bei uns stellt sich das Zurückspielen der Master mit Veritas BE als recht tricky an.

Es gibt zwar eine Option "Wiederherstellen der Master-Datenbank automatisieren", aber so recht funktionieren will das nicht.

 

Nur so als Hinweis.

 

Gruss

Velius

 

 

P.S.: Das Backup funktioniert tadellos, aber eben, der Restore sollte auch....

[xtragood 10]

Offenbar werden da ja noch Daten vom Master benötigt, und bei uns stellt sich das Zurückspielen der Master mit Veritas BE als recht tricky an.

 

Deswegen die Frage, da ich am Wochenende ein Restore gemacht hab, feststellen musste, dass master und einige andere Datenbanken aufgrund "online" status der Datenbanken nicht mitgesichert wurden.

 

Und deswegen die einfachste Möglichkeit, das Stoppen des MSSQL-Servers...

 

Aber ne Lösung haste jetzt ja auch nicht gepostet, Velius? :p ;)

[Velius 10]

Also bei uns wird die Datenbank gesichert, obwohl online, und auch ohne AOFO.

Ist ja ähnlich wie bei Exchange, und da klappt's auch, dafür ist ja der Exchange/SQL Agent da.

 

 

P.S.: Sollte auch keine Lösung sein, sondern eine Anregung. ;)

[xtragood 10]

...den wir nicht gekauft haben und auch nicht wollen (SQL Agent).

 

 

PS: Exchange Agent haben wir schon...

[goscho 11]

Hallo Extragood,

ich hatte bei einem Kunden den BE SQL-Server-Agenten im Einsatz, jedoch ständig nicht nachvollziehbare Fehler. Nachdem dieser auch noch die MSDE von Datev auf seinen Server installiert hatte, wo die Sicherung nur im Offlinemodus klappt, hab ich die anderen SQL-Datenbanken auch so eingestellt. Und zwar ein Script zum Beenden und eines zum starten des SQL-Servers angelegt und dann die Scripte in BE eingebunden. Jetzt werden alle SQL-Datenbanken offline gesichert. Zusätzlich hab ich sicherheitshalber noch einen Task erstellt, das den SQL-Server morgens startet. Jetzt habe ich nur eine Sorge: Die vergessen das Band zu wechseln und BE wartet solange (Überschreibschutz), morgens wird das dann nachgeholt und beendet den SQL-Server, während alle darauf zugreifen. Auf den Fall warte ich jetzt.

 

Den Vorschlag von substyle finde ich da viel besser: SQL-Enterprisemanager > Datenbankwartungsplan > Wartung mit Sicherung/Konsistenzprüfung etc. und dann das gesicherte file BE wegsichern lassen.

 

Ansonsten würde ich mich auch freuen, wenn mir ein SQL - BE Profi erklären könnte, wie ich den SQL-Agent nutze, den Wiederherstellungspunkt auf simple stelle und dann keine Fehler mehr habe. Krieg das irgendwie nicht sauber hin, obwohl ich schon X-Varianten getestet habe. Vielleicht liegt es ja an BE 9.0 (konnte 9.1 noch nicht auf dem Server installieren) oder doch an mir?

Danke und Gruß Goscho

[Velius 10]

Also eigentlich wollte ich mit meinem Post auf den Restore aufmerksam machen und/oder hilfreichen Input provozieren. Richtet euer Augenmerk darauf, egal wie und womit ihr die SQL Datenbanken sichert (was bei uns gerade Thema ist, da das Backup funktioniert aber ben das Restore nicht).

[substyle 20]

Ich sags mal so.

 

Backup Master !

 

Enterprise Manager öffnen -> Backup Master !

 

SQL Befehl machen -> Backup Master !

 

Zum Mittagessen gehen .. ratet was ? .. genau ! -> Backup Master !

 

Master ist und bleibt kritisch. Man kann sie garnicht oft genug sichern.

Gut es gibt schon wege und Mittel, aber es hängt alles am Master.

 

Habe immo Vertias 9.1 und 10.0 im Einsatz. Restore geht/ging problemlos.

Die alte Methode über backup database xxx to disk = 'c:\igrendwas.bak' with ....

ist in meinen Augen gut und günstig. Jedenfalls solange man sich bemüht

einmal am Tag die Syslogs zu lesen und zu schauen ob die DB's auch

anständig gesichert wurden.

 

subby

[xtragood 10]

Jede Datenbank mit einem Backup-Auftrag auszustatten, erzeugt aber auch das doppelte an Festplattenplatz. Und wenn dieser knapp bemessen ist, sichert man lieber mit BE...

 

Zumindest ist das bei uns so...wichtige Datenbanken werden natürlich auch noch per SQL-Backup gesichert, aber eben nicht alle... ;)

[xtragood 10]

Hi nochmal,

 

wir werden jetzt unsere Datenbanken doch mit SQL-Backup sichern.

 

Hat jemand von euch eine Strategie, die man dafür verwenden könnte?

 

Hatte mir vielleicht vorgestellt unter der Woche differential backups zu machen, am Wochenende ein Full-Backup, dass dann mit auf's "normale" Backup gesichert wird.

 

Andere Ideen?

 

 

Gruß, xtra.

[substyle 20]

Ich mache es immer nach folgender Regel:

 

- Wie oft d.h wie schnell schaffst du ein "volles Backup", also alles

Grundregel. Wenn du ein full backup einmal täglich schaffst, warum

sollte man sich scheuen eins zu machen.

 

Differentiell ist die nächst kleinere "Stufe"

Teste auch hier mal wie oft du differentiell sichern kannst. Ich habe

meist nur "kleine" db's da kann ich locker jede Stunde differenz. auf HDD

sichern und dann minimal Zeitversetzt auf den Streamer.

 

Letzte Stufe sind denke ich die Transaktion Logs.

Hier sollte man einfach schauen wieviel am Server gearbeitet wird.

Und auch wieder so kurz wie möglich. 2minuten bis 15 Minuten können stimmen.

 

Was ich damit eigentlich sagen will. Es kommt beim Backup sehr sehr auf

deine /eure Anforderungen an SQL an, und wie Leistungsfähig der Server ist,

bzw. wie sicher eure Daten zeitnah abgespeichert werden müssen.

 

Ich bevorzuge bei hoher Last dann schon ehr bessere Hardware (verschieden Raidlevel)

0/1/5 um maximale Ausfallgarantie zu geben. (die meisten knnen sich eben keinen

Cluster o.ä. leisten)

 

Gruß

 

subby