SQL 2005 Server - Datenbanken sichern
Hallo zusammen,
Wir haben einen MS SQL 2005 Server und haben festgestellt, dass wohl seit 3 Jahren nicht mehr gesichert wird. Wir haben Arcserve ein Sicherungssoftware im Einsatz. Die .MDF Datenbankdateien werden auf Band gesichert. Jedenfalls bekommen wir dazu keine Fehler im Jobprotokoll angezeigt. Den SQL Agent im Arcserver haben wir nicht lizensiert, sprich wir sichern nur per Datei die Datenbank ab.
1. Reicht unsere Dateisicherung der Datenbank aus?
2. Habe ich gehört, dass man einen vollständigen SQL Server, also nicht die Express Version, per Dateisicherung sichern kann?
3. Wie erkenne ich, ob ich eine Express oder einen vollständigen SQL Server habe?
Wäre über eine Antwort dankbar.
Wir haben einen MS SQL 2005 Server und haben festgestellt, dass wohl seit 3 Jahren nicht mehr gesichert wird. Wir haben Arcserve ein Sicherungssoftware im Einsatz. Die .MDF Datenbankdateien werden auf Band gesichert. Jedenfalls bekommen wir dazu keine Fehler im Jobprotokoll angezeigt. Den SQL Agent im Arcserver haben wir nicht lizensiert, sprich wir sichern nur per Datei die Datenbank ab.
1. Reicht unsere Dateisicherung der Datenbank aus?
2. Habe ich gehört, dass man einen vollständigen SQL Server, also nicht die Express Version, per Dateisicherung sichern kann?
3. Wie erkenne ich, ob ich eine Express oder einen vollständigen SQL Server habe?
Wäre über eine Antwort dankbar.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122854
Url: https://administrator.de/forum/sql-2005-server-datenbanken-sichern-122854.html
Ausgedruckt am: 25.12.2024 um 14:12 Uhr
8 Kommentare
Neuester Kommentar
Wow früh gemerkt
Also die Datenbankdateien so einfach wegsichern würde ich nicht. Wenn ihr die keinen SQL Agenten habt würde ich einen Wartungsplan einrichten. Eftl. auch mit Transaktionsprotokollen und Datenbankbereinigung Geht Recht schön über das Management Studion. Da kann man gleich auf Band sichern oder in Datei und dann mit Arcserv.
Im Management Studio kanns du dir auch Anzeigen lassen ob's ein Express ist oder nicht. Das sieht man unter Eigenschaften des obersten Punktes des Objekt-Explorers
Also die Datenbankdateien so einfach wegsichern würde ich nicht. Wenn ihr die keinen SQL Agenten habt würde ich einen Wartungsplan einrichten. Eftl. auch mit Transaktionsprotokollen und Datenbankbereinigung Geht Recht schön über das Management Studion. Da kann man gleich auf Band sichern oder in Datei und dann mit Arcserv.
Im Management Studio kanns du dir auch Anzeigen lassen ob's ein Express ist oder nicht. Das sieht man unter Eigenschaften des obersten Punktes des Objekt-Explorers
Moin cordial,
und um Frage 1 ("Reicht unsere Dateisicherung der Datenbank aus?") eindeutig zu beantworten.
Absolut NEIN. Eher sogar im Gegenteil, denn die vermeintlich gesicherte MDF-Datei enthält einen undefinierten Zustand, einen Zufalls-Snapshot, der genau das enthält, was die diversen Writer-Prozesse persistiert haben.
Das kann alles mögliche sein, auch alles mögliche zu genau diesem Kopierzeitpunkt Wahre.
Aber eben erstens nicht konsistent/"prozessübergreifend abgestimmt", sondern Threadbezogen.
Beispiel: Einer der User hat nun mal in seiner Session ein COMMIT abgesetzt.
87 andere User aber gerade noch nicht.
Wenn ihr einen derartigen Datenklumpen als Quelle für ein Restore nutzt, kann es sein, dass ein inkonsistenter Daten(schief)stand erzeugt wird.
Sieh es positiv - ihr habt 3 Jahre lang keine brauchbare Datensicherung gehabt.
Aber gottseidank hat auch niemals jemand eine dieser MDF-Dateien als Quelle für ein Zurücksichern genutzt.
Grüße
Biber
und um Frage 1 ("Reicht unsere Dateisicherung der Datenbank aus?") eindeutig zu beantworten.
Absolut NEIN. Eher sogar im Gegenteil, denn die vermeintlich gesicherte MDF-Datei enthält einen undefinierten Zustand, einen Zufalls-Snapshot, der genau das enthält, was die diversen Writer-Prozesse persistiert haben.
Das kann alles mögliche sein, auch alles mögliche zu genau diesem Kopierzeitpunkt Wahre.
Aber eben erstens nicht konsistent/"prozessübergreifend abgestimmt", sondern Threadbezogen.
Beispiel: Einer der User hat nun mal in seiner Session ein COMMIT abgesetzt.
87 andere User aber gerade noch nicht.
Wenn ihr einen derartigen Datenklumpen als Quelle für ein Restore nutzt, kann es sein, dass ein inkonsistenter Daten(schief)stand erzeugt wird.
Sieh es positiv - ihr habt 3 Jahre lang keine brauchbare Datensicherung gehabt.
Aber gottseidank hat auch niemals jemand eine dieser MDF-Dateien als Quelle für ein Zurücksichern genutzt.
Grüße
Biber