kostenlose System-Datensicherung Windows Server
Hallo Zusammen,
ich habe nach einer Möglichkeit gesucht Windows Server - Betriebsysteme komplett automatisiert zu sichern. Die angebotenen Backuplösungen von div. Herstellern kosten eine Stange Geld und die Sicherung erfolgt auch im laufenden Betrieb. Es wird zwar geworben das dies kein Problem sei, doch mir ist es lieber und sicherer wenn die Systemsicherung der gesamten Festplatte offline vonstatten geht. Ich habe mir folgende Lösung mit Hilfe von Knoppix zusammengestrickt und möchte Euch diese präsentieren.
Auf der Systemfestplatte sind 3 Partitionen eingerichtet.
1. Systempartition Server 2003 (bootfähig)
2. Datenpartition für Server
3. Systempartition Knoppix 5.1 (bootfähig)
Auf der 2. Festplatte (Backup) befindet sich eine NTFS-Partition.
Der Server startet nachts automatisch ein Script welches die Knoppix-Partition aktiv setzt und den Rechner neu startet. Knoppix wird gestartet und ein Script im Autostart-Ordner erstellt ein Image von der Systemfestplatte auf die 2. Festplatte. Der Name der Imagedatei ist Datumsbezogen. Ältere Imagedateien bleiben also erhalten.
Die Systemfestplatte wird Sektor für Sektor eingelesen, die Daten werden komprimiert und dann in eine Datei gespeichert. Es ist also völlig egal was auf der Systemplatte für ein Dateisystem installiert ist. Alle Betriebsysteme werden unterstützt, von Windows 3.11 bis Server 2008. Nach Erstellung der Imagedatei wird die Serverpartition wieder aktiviert und der Rechner neu gestartet. Das Serverbetriebssystem wird gebootet und läuft wieder. Der gesamte Vorgang läuft komplett automatisiert ab.
Booten Sie von der CD und in der Eingabeaufforderung geben Sie zunächst su ein und dann den Befehl knoppix-installer . Mit diesem Assistent wird Knoppix auf Festplatte installiert. Hier werden auch Anweisungen gegeben wie Sie eine Partition für Knoppix auch nachträglich noch erstellen können. Ca. 5GB reichen aus. Wenn alles fertig ist, sollte Ihr Rechner Knoppix von Festplatte starten können. Ich bin kein Unix-Experte und bei mir werden beim booten irgendwelche Fehler angezeigt, was aber nicht schlimm ist. Wichtig ist nur das man auf die Festplatten zugreifen kann.
Datei diskpart.befehle :
Datei active_knoppix.bat :
Einen geplanten Task hinzufügen und diesen zeitlich wie gewünscht einrichten.
Als Programm welches gestartet werden soll die Datei active_knoppix.bat eintragen.
#!/bin/sh
mount /dev/mapper/via_cbfcfjgebf1
sudo dd if=/dev/sda | gzip > /media/ via_cbfcfjgebf1/’date +%Y%b%d’
sudo sfdisk –A1 /dev/sda
sudo shutdown –r +0
Mit mount in der zweiten Zeile wird die zweite Festplatte wo die Imagedatei als Datei gesichert werden soll geöffnet. In der dritten Zeile erfolgt die Sicherung. Quelle = /dev/sda , bei mir die erste Festplatte (SATA) und gesichert wird nach /media/via_cbfcfjgebf1 , das ist bei mir die Adresse wohin er meine Zielplatte zuvor gemounted hat. Der Name der Imagedatei erfolgt Datumsabhängig. Zuvor gesicherte Imagedateien werden also nicht überschrieben. Achtung, die ’ – Zeichen mit [Alt Gr] + # im Texteditor schreiben ! Mit sfdisk wird hier die erste Partition von der Festplatte /dev/sda aktiviert, bei mir die Systempartition von Server2003. Damit er beim Neustart wieder Windows Server 2003 bootet. Mit shutdown wird dann auch der Neustart durchgeführt.
Die Adressen für die Festplatten müssen im Script auf Euer System angepasst werden. Zum testen die beiden letzten Befehle sfdisk und shutdown raus nehmen und Script ausführen. Zuvor noch in den Eigenschaften der Datei die Datei als Ausführbar kennzeichnen.
Wenn die Sicherung funktioniert, die Datei in den Ordner /home/knoppix/.kde/Autostart kopieren. Dann wird das Script automatisch beim booten von Knoppix ausgeführt. Damit man den Ordner sieht, im Knoppix-Explorer ein Häkchen setzen bei Ansicht – „Versteckte Dateien anzeigen“.
Für die Rücksicherung folgenden Script verwenden:
mount /dev/mapper/via_cbfcfjgebf1
sudo gzip –dc /media/via_cbfcfjgebf1/imagedatei | dd of=/dev/sda
Auch hier die Pfade für die Festplatten für Euer System abändern. Den Rücksicherungsscript notieren oder auf die 2. Festplatte sichern. Denn im Falle eines Defektes muss Knoppix von CD gebootet werden.
Falls Fragen sind, versuche ich zu helfen...
Viel Glück
Axel
ich habe nach einer Möglichkeit gesucht Windows Server - Betriebsysteme komplett automatisiert zu sichern. Die angebotenen Backuplösungen von div. Herstellern kosten eine Stange Geld und die Sicherung erfolgt auch im laufenden Betrieb. Es wird zwar geworben das dies kein Problem sei, doch mir ist es lieber und sicherer wenn die Systemsicherung der gesamten Festplatte offline vonstatten geht. Ich habe mir folgende Lösung mit Hilfe von Knoppix zusammengestrickt und möchte Euch diese präsentieren.
Vorwort:
Im Server befinden sich 2 Festplatten.Auf der Systemfestplatte sind 3 Partitionen eingerichtet.
1. Systempartition Server 2003 (bootfähig)
2. Datenpartition für Server
3. Systempartition Knoppix 5.1 (bootfähig)
Auf der 2. Festplatte (Backup) befindet sich eine NTFS-Partition.
Der Server startet nachts automatisch ein Script welches die Knoppix-Partition aktiv setzt und den Rechner neu startet. Knoppix wird gestartet und ein Script im Autostart-Ordner erstellt ein Image von der Systemfestplatte auf die 2. Festplatte. Der Name der Imagedatei ist Datumsbezogen. Ältere Imagedateien bleiben also erhalten.
Die Systemfestplatte wird Sektor für Sektor eingelesen, die Daten werden komprimiert und dann in eine Datei gespeichert. Es ist also völlig egal was auf der Systemplatte für ein Dateisystem installiert ist. Alle Betriebsysteme werden unterstützt, von Windows 3.11 bis Server 2008. Nach Erstellung der Imagedatei wird die Serverpartition wieder aktiviert und der Rechner neu gestartet. Das Serverbetriebssystem wird gebootet und läuft wieder. Der gesamte Vorgang läuft komplett automatisiert ab.
Vor- und Nachteile:
Vorteile:- kostenlose Backuplösung ganzer Festplatten
- Sicherung erfolgt unabhängig vom Betriebssystem/Dateisystem
- Imagedateien sind zwar komprimiert, jedoch trotzdem noch recht groß weil auch die “leeren“ Sektoren mit gesichert werden.
- Die Sicherung von Raid-Platten ist mit Mehraufwand verbunden und wird hier erstmal nicht unterstützt bzw. ist nicht empfehlenswert.
- Eine Rücksicherung im Falle eines Festplatten-Defekts muss auf eine baugleiche Festplatte erfolgen.
Installation:
Laden Sie aus dem Internet die aktuelle Knoppix-Version herunter und brennen diese auf CD.Booten Sie von der CD und in der Eingabeaufforderung geben Sie zunächst su ein und dann den Befehl knoppix-installer . Mit diesem Assistent wird Knoppix auf Festplatte installiert. Hier werden auch Anweisungen gegeben wie Sie eine Partition für Knoppix auch nachträglich noch erstellen können. Ca. 5GB reichen aus. Wenn alles fertig ist, sollte Ihr Rechner Knoppix von Festplatte starten können. Ich bin kein Unix-Experte und bei mir werden beim booten irgendwelche Fehler angezeigt, was aber nicht schlimm ist. Wichtig ist nur das man auf die Festplatten zugreifen kann.
Einrichtung Windows:
In einem Ordner zwei Text-Dateien erstellen. Die Kommentare hinter den Befehlen dienen nur der Erklärung und brauchen nicht abgetippt werden. Befehle gegebenenfalls anpassen falls Pfad und Partition eine andere ist.Datei diskpart.befehle :
select disk=0 | Erste Festplatte auswählen. |
select partition=3 | 3. Partition auswählen. |
active | Ausgewählte Partition aktiv setzen. |
Datei active_knoppix.bat :
diskpart /s c:\diskpart.befehle | Die Anweisungen in der obigen Datei ausführen. |
shutdown /r | Rechner runter fahren und neu starten. |
Einen geplanten Task hinzufügen und diesen zeitlich wie gewünscht einrichten.
Als Programm welches gestartet werden soll die Datei active_knoppix.bat eintragen.
Einrichtung Knoppix:
Auf dem Desktop eine Datei mit dem Texteditor erstellen mit folgendem Inhalt:#!/bin/sh
mount /dev/mapper/via_cbfcfjgebf1
sudo dd if=/dev/sda | gzip > /media/ via_cbfcfjgebf1/’date +%Y%b%d’
sudo sfdisk –A1 /dev/sda
sudo shutdown –r +0
Erklärung:
An der ersten Zeile erkennt Knoppix das es sich hier um eine Scriptdatei handelt.Mit mount in der zweiten Zeile wird die zweite Festplatte wo die Imagedatei als Datei gesichert werden soll geöffnet. In der dritten Zeile erfolgt die Sicherung. Quelle = /dev/sda , bei mir die erste Festplatte (SATA) und gesichert wird nach /media/via_cbfcfjgebf1 , das ist bei mir die Adresse wohin er meine Zielplatte zuvor gemounted hat. Der Name der Imagedatei erfolgt Datumsabhängig. Zuvor gesicherte Imagedateien werden also nicht überschrieben. Achtung, die ’ – Zeichen mit [Alt Gr] + # im Texteditor schreiben ! Mit sfdisk wird hier die erste Partition von der Festplatte /dev/sda aktiviert, bei mir die Systempartition von Server2003. Damit er beim Neustart wieder Windows Server 2003 bootet. Mit shutdown wird dann auch der Neustart durchgeführt.
Die Adressen für die Festplatten müssen im Script auf Euer System angepasst werden. Zum testen die beiden letzten Befehle sfdisk und shutdown raus nehmen und Script ausführen. Zuvor noch in den Eigenschaften der Datei die Datei als Ausführbar kennzeichnen.
Wenn die Sicherung funktioniert, die Datei in den Ordner /home/knoppix/.kde/Autostart kopieren. Dann wird das Script automatisch beim booten von Knoppix ausgeführt. Damit man den Ordner sieht, im Knoppix-Explorer ein Häkchen setzen bei Ansicht – „Versteckte Dateien anzeigen“.
Für die Rücksicherung folgenden Script verwenden:
mount /dev/mapper/via_cbfcfjgebf1
sudo gzip –dc /media/via_cbfcfjgebf1/imagedatei | dd of=/dev/sda
Auch hier die Pfade für die Festplatten für Euer System abändern. Den Rücksicherungsscript notieren oder auf die 2. Festplatte sichern. Denn im Falle eines Defektes muss Knoppix von CD gebootet werden.
Falls Fragen sind, versuche ich zu helfen...
Viel Glück
Axel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 69562
Url: https://administrator.de/contentid/69562
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
14 Kommentare
Neuester Kommentar
Danke für die schöne Umsetzung mit der Aktivierung der Boot-Partitionen, zwei Anmerkungen:
Bei RAID-Systemen ist ein getrenntes Auslesen generell heikel, ich würde diese Lösung nicht universell empfehlen, sondern erst gründlich ohne Nutzdaten mit dem betreffenden RAID-Controller testen. Beim Backup sollte man bei RAID 1 mit einer Platte auskommen - und einen Superblock einfach beim Restore verwerfen können.
Zum Backup von einem unterstützten RAID oder Einzelplatten könnte man auch nur die genutzten Blöcke kopieren lassen, z.B. mit partimage, was aber für NTFS als experimentell bezeichnet wird. Dann würde man beim Rückkopieren auch wieder das RAID als eine Platte ansprechen.
Ich würde aber generell weniger das Wiederherstellen auf genau dieser Hardwareplattform im Auge haben (via on board ?!), sondern denken, daß das entpackte Backup auf neuer Hardware wieder nutzbar ist und einfach als Datenpartition - auch z.B. von einer externen Platte - zum Restaurieren beiträgt.
Bei RAID-Systemen ist ein getrenntes Auslesen generell heikel, ich würde diese Lösung nicht universell empfehlen, sondern erst gründlich ohne Nutzdaten mit dem betreffenden RAID-Controller testen. Beim Backup sollte man bei RAID 1 mit einer Platte auskommen - und einen Superblock einfach beim Restore verwerfen können.
Zum Backup von einem unterstützten RAID oder Einzelplatten könnte man auch nur die genutzten Blöcke kopieren lassen, z.B. mit partimage, was aber für NTFS als experimentell bezeichnet wird. Dann würde man beim Rückkopieren auch wieder das RAID als eine Platte ansprechen.
Ich würde aber generell weniger das Wiederherstellen auf genau dieser Hardwareplattform im Auge haben (via on board ?!), sondern denken, daß das entpackte Backup auf neuer Hardware wieder nutzbar ist und einfach als Datenpartition - auch z.B. von einer externen Platte - zum Restaurieren beiträgt.
Ich finde diesen Ansatz ja ganz praktisch, sehe allerdings auch ein paar Probleme.
Was ist, wenn jemand nachts (wie unsereins) an der Maschine arbeitet und mit in der Arbeit von dem Script an die frische Luft gesetzt wird?
Mit dieser Lösung geht im schlimmsten Fall (knapp) ein ganzer Tag Arbeit flöten. Unangenehm, wenn das gerade der produktivste Tag des Monats war..
Wenn doch ohnehin schon eine zweite Platte für Sicherungszwecke gebraucht wird, warum dann nicht gleich die ganze Serverplatte spiegeln? Raid 0 wird ohnehin der s/w unterstützt und viele Server bringen die Funktion auch per Hardware mit. (Das bringt neben der Funktionalität noch zusätzlicher Sicherheit, Geschwindigkeit und Komfort). Die zweite Platte ist immer up to date und es gibt keine Totzeiten für die Sicherung.
Oder sollte ich etwas falsch verstanden haben?? Ich bin selbst gerade dabei, mir ein simples aber sicheres Konzept zu überlegen..
Gruß, Kapinski
Was ist, wenn jemand nachts (wie unsereins) an der Maschine arbeitet und mit in der Arbeit von dem Script an die frische Luft gesetzt wird?
Mit dieser Lösung geht im schlimmsten Fall (knapp) ein ganzer Tag Arbeit flöten. Unangenehm, wenn das gerade der produktivste Tag des Monats war..
Wenn doch ohnehin schon eine zweite Platte für Sicherungszwecke gebraucht wird, warum dann nicht gleich die ganze Serverplatte spiegeln? Raid 0 wird ohnehin der s/w unterstützt und viele Server bringen die Funktion auch per Hardware mit. (Das bringt neben der Funktionalität noch zusätzlicher Sicherheit, Geschwindigkeit und Komfort). Die zweite Platte ist immer up to date und es gibt keine Totzeiten für die Sicherung.
Oder sollte ich etwas falsch verstanden haben?? Ich bin selbst gerade dabei, mir ein simples aber sicheres Konzept zu überlegen..
Gruß, Kapinski
Sie meinten RAID 1 - nicht 0 - denke ich, Hardware-RAID ist leider auch nicht - gerade bei Mainboards - die vertrauenswürdigste Variante, ist das Board kaputt, kann man mit neuem Board dümmstenfalls auf keine Platte zugreifen, eine Sicherung in Leerzeit hat den Vorteil, daß die Benutzer-Fehler des laufenden Tages schnell aus dem Backup zurück geholt werden können, "ich habe meinen Brief in den Papierkorb gelegt, da ist er jetzt nicht mehr"...
Betreff: kostenlose System-Datensicherung Windows Server
Interessanter Ansatz - Aber nur weil dies unter Umständen läuft, würde ich es trotzdem nicht verwenden.
Ich würde sogar davon abraten!
Insbesondere die Geschichte mit dem RAID würde mich sehr nervös machen.
Sorry
Warum denn nicht?
Also ich möchte nun keine Diskussion vom Zaun brechen Koppix/linux versus MS
Oder ob es grundsätzlich sinnvoll ist einen Server dergestalt zu malträtieren.
Aus leidvoller Erfahrung bin ich dazu übergegangen auf Servern möglichst wenige Sonderwege
(und wenn nur in Notfall und als Interim-Lösung) einzusetzen.
Und dies egal wie genial oder pfiffig die auch sein mögen.
Server müssen SICHER laufen und Zusatzrisiken sind deshalb zu vermeiden.
Aber dies sind nur allgemeine auf mein Bauchempfinden beruhende Argumente.
Und jeder wie es im beliebt!
Und nun die fachbezogenen Gründe:
1. Kostengründe:
Du erzielst keine wirkliche Einsparung!
Denn alles Notwendige für deine Zielerreichung ist bereits kostenlos!
MS hat mit Server 2003 auch das beigefügte Tool ntbackup in Zusammenarbeit mit veritas einer Frischzellenkur unterzogen.
Es ist mittlerweile in der Lage
den Systemsatus zu sichern als inklusive AD GP-Scripte etc
und es kann Exchange-Datenbänke online sichern
und ganz wichtig:
NT-Backup kann die X-Transaktionslogs kürzen
Gleichfalls ist es so (in Verbindung mit der VSS-Technologie) möglich auch geöffnete Dateien zu sichern
Sprich die Systempartion im laufenden Betrieb.
Wie gesagt: Alles ist kostenlos und bereits im Server 2003 enthalten.
Ebenfalls kostenlos bei MS zu erhalten:
robocopy neuerdings sogar sowie einer MS-GUI als flexiblere Sicherungsalternative und als sehr mächtiges tool insbesondere für Datenfile.
By the way: Es gibt hierzu auch eine GUI die nicht von MS ist. Ist eine Geschmackssache.
Mit Robocopy ist es aber zum Beispiel möglich einen Datenbestand in kurzen Intervallen zu spiegeln.
Zusätzlich gibt es bei MS eine Vielzahl an zusätzlichen gesicherten Infos hierzu.
Und im Netz viele Anwendungsbeispiele
z.B. zur Sicherung von Exchange
http://blogs.technet.com/jhoward/archive/2005/06/29/406876.aspx
Also die Sicherung ist mit bewährten Methoden durch kostenlose Tools möglich
Folglich kein Grund für Sonderwege!
2. Die Sicherungsart ist bestenfalls suboptimal
Denn Ziel der Sicherung ist ja optimal für den Notfall vorbereitet zu sein.
Aber dein Ansatz setzt zwingend den Einsatz der X- Umlaufprotokollierung voraus.
(Sonst läuft in absehbarer Zeit deine Platte voll und X wird nicht mehr starten.)
Der Einsatz der Umlaufprotokollierung bringt aber verschiedene Nachteile für ein Recovery mit sich.
Im Allgemeinen wird von der Verwendung der Umlaufprotokolierung abgeraten
Daher ist der Ansatz nicht wirklich gut und da mit Nt-backup es besser geht ==> auch suboptimal
Warum das so ist und tieferes Know-how zum Thema X sei auf www.MSXFAQ.de verwiesen.
Exchange NOTFALL - Festplatte voll
http://msxfaq.de/notfall/diskfull.htm
Exchange Datenbank - ein Blick dahinter
http://msxfaq.de/admin/database.htm
Backup und Restore - Vollbackup, Differenz, Inkrementell, Copy
http://msxfaq.de/admin/backupverfahren.htm
Im Übrigen ist mittlerweile X voll integriert in das AD des Betriebssystems also
Ohne gute Sicherung zumindest des Systemstatus stehst du trotz eventuell toller X-Datensicherung im Regen. Nicht zwangsläufig -aber nach
Murphys Law sicher
Und deshalb noch:
3. Sicherung des Betriebssystem
Vom Prinzip her gibt es durchaus Vorteile von einem Image der Systempartition
Hauptsächlich beim Ausfall ist die schnelle Wiederherstellung eines lauffähigen Systems
ein Segen
Aber auch hier gibt es zumindest bei Servern einige Einschränkungen:
Denn trotzdem wird normalerweise zusätzlich die Sicherung des Systemstatus benötigt
Auch hier wieder: Das ist einfach ein Klick bei ntbackup
Also Imaging als Backup-Methode ist mit Vorsicht zu genießen
vgl hierzu zum Beispiel:
http://www.msxfaq.de/verschiedenes/imagebackup.htm
Ich denke das reicht erstmal als Feedback !
Nochmals Sorry,
eigentlich möchte ich deinen Beitrag gar nicht so runtermachen,
denn im Prinzip empfinde ich den wirklich als pfiffig.
Doch bezogen auf Ausfallsicherheit und Recovery habe ich gewisse paranoide Züge.
Und Mitarbeitern Datenverluste zu erklären, macht weder Freude noch schafft das Freunde.
Also trotzdem mach weiter!
Interessanter Ansatz - Aber nur weil dies unter Umständen läuft, würde ich es trotzdem nicht verwenden.
Ich würde sogar davon abraten!
Insbesondere die Geschichte mit dem RAID würde mich sehr nervös machen.
Sorry
Warum denn nicht?
Also ich möchte nun keine Diskussion vom Zaun brechen Koppix/linux versus MS
Oder ob es grundsätzlich sinnvoll ist einen Server dergestalt zu malträtieren.
Aus leidvoller Erfahrung bin ich dazu übergegangen auf Servern möglichst wenige Sonderwege
(und wenn nur in Notfall und als Interim-Lösung) einzusetzen.
Und dies egal wie genial oder pfiffig die auch sein mögen.
Server müssen SICHER laufen und Zusatzrisiken sind deshalb zu vermeiden.
Aber dies sind nur allgemeine auf mein Bauchempfinden beruhende Argumente.
Und jeder wie es im beliebt!
Und nun die fachbezogenen Gründe:
1. Kostengründe:
Du erzielst keine wirkliche Einsparung!
Denn alles Notwendige für deine Zielerreichung ist bereits kostenlos!
MS hat mit Server 2003 auch das beigefügte Tool ntbackup in Zusammenarbeit mit veritas einer Frischzellenkur unterzogen.
Es ist mittlerweile in der Lage
den Systemsatus zu sichern als inklusive AD GP-Scripte etc
und es kann Exchange-Datenbänke online sichern
und ganz wichtig:
NT-Backup kann die X-Transaktionslogs kürzen
Gleichfalls ist es so (in Verbindung mit der VSS-Technologie) möglich auch geöffnete Dateien zu sichern
Sprich die Systempartion im laufenden Betrieb.
Wie gesagt: Alles ist kostenlos und bereits im Server 2003 enthalten.
Ebenfalls kostenlos bei MS zu erhalten:
robocopy neuerdings sogar sowie einer MS-GUI als flexiblere Sicherungsalternative und als sehr mächtiges tool insbesondere für Datenfile.
By the way: Es gibt hierzu auch eine GUI die nicht von MS ist. Ist eine Geschmackssache.
Mit Robocopy ist es aber zum Beispiel möglich einen Datenbestand in kurzen Intervallen zu spiegeln.
Zusätzlich gibt es bei MS eine Vielzahl an zusätzlichen gesicherten Infos hierzu.
Und im Netz viele Anwendungsbeispiele
z.B. zur Sicherung von Exchange
http://blogs.technet.com/jhoward/archive/2005/06/29/406876.aspx
Also die Sicherung ist mit bewährten Methoden durch kostenlose Tools möglich
Folglich kein Grund für Sonderwege!
2. Die Sicherungsart ist bestenfalls suboptimal
Denn Ziel der Sicherung ist ja optimal für den Notfall vorbereitet zu sein.
Aber dein Ansatz setzt zwingend den Einsatz der X- Umlaufprotokollierung voraus.
(Sonst läuft in absehbarer Zeit deine Platte voll und X wird nicht mehr starten.)
Der Einsatz der Umlaufprotokollierung bringt aber verschiedene Nachteile für ein Recovery mit sich.
Im Allgemeinen wird von der Verwendung der Umlaufprotokolierung abgeraten
Daher ist der Ansatz nicht wirklich gut und da mit Nt-backup es besser geht ==> auch suboptimal
Warum das so ist und tieferes Know-how zum Thema X sei auf www.MSXFAQ.de verwiesen.
Exchange NOTFALL - Festplatte voll
http://msxfaq.de/notfall/diskfull.htm
Exchange Datenbank - ein Blick dahinter
http://msxfaq.de/admin/database.htm
Backup und Restore - Vollbackup, Differenz, Inkrementell, Copy
http://msxfaq.de/admin/backupverfahren.htm
Im Übrigen ist mittlerweile X voll integriert in das AD des Betriebssystems also
Ohne gute Sicherung zumindest des Systemstatus stehst du trotz eventuell toller X-Datensicherung im Regen. Nicht zwangsläufig -aber nach
Murphys Law sicher
Und deshalb noch:
3. Sicherung des Betriebssystem
Vom Prinzip her gibt es durchaus Vorteile von einem Image der Systempartition
Hauptsächlich beim Ausfall ist die schnelle Wiederherstellung eines lauffähigen Systems
ein Segen
Aber auch hier gibt es zumindest bei Servern einige Einschränkungen:
Denn trotzdem wird normalerweise zusätzlich die Sicherung des Systemstatus benötigt
Auch hier wieder: Das ist einfach ein Klick bei ntbackup
Also Imaging als Backup-Methode ist mit Vorsicht zu genießen
vgl hierzu zum Beispiel:
http://www.msxfaq.de/verschiedenes/imagebackup.htm
Ich denke das reicht erstmal als Feedback !
Nochmals Sorry,
eigentlich möchte ich deinen Beitrag gar nicht so runtermachen,
denn im Prinzip empfinde ich den wirklich als pfiffig.
Doch bezogen auf Ausfallsicherheit und Recovery habe ich gewisse paranoide Züge.
Und Mitarbeitern Datenverluste zu erklären, macht weder Freude noch schafft das Freunde.
Also trotzdem mach weiter!
Die Daten stellen je nach Anwendungsfall ein erhebliches Kapital dar; u. U. repräsentieren sie die Existenzgrundlage eines Betriebes. Man bedenke, dass unterschiedliche Schadensarten abzudecken sind; ich nenne hier mal ein paar typische Beispiele (die Ax teilweise schon erwähnt hat:
- Platte irreparabel defekt
- Schäden durch Viren, Fehlbedienung, etc. (s. o.)
- Blitzeinschlag --> kann u. U. alle angeschlossenen Platten zerstören
- Einbruchsdiebstahl --> Server mit Haupt- und Sicherungsdatenträger verloren
- Brand-/Wasserschaden
- etc..
Eine einzige Sicherung auf einem Datenträger, der sich fest im kritischen Server befindet, ist eine gefährliche Scheinsicherheit. Je nach Wert der Daten ist eine Sicherung auf externe Datenträger bzw. in externe Systeme notwendig. Sicherungsbänder kann man an einen sicheren Ort transportieren; Third-Party-Datencenter bieten Sicherungsdienste an (gegen Entgelt..); ein Sicherungs-Server an einem geschützten Ort kann u. U. einigen Schutz bieten; etc..
Neben der reinen Datensicherung ist das Thema Dasaster Recovery - ebenfalls abhängig vom jeweiligen Arbeitsumfeld - u. U. ebenso zu beachten. Das Einrichten einer komplexen Server-Umgebung mit allen Anwendungen, db, Security, etc. kann u. U. sehr viel Zeit in Anspruch nehmen.
Bei der Planung eines Sicherungskonzeptes muss man also neben den Hardware-Kosten vor allem den Wert absichern, der tatsächlich durch einen Datenverlust verursacht werden kann. Ich sehe daher keine vorkonfigurierbare Standardlösung, sondern nur ein entsprechend maßgeschneidertes Gesamtkonzept mit - falls nötig - mehreren parallelen Sicherungselementen.
Inwieweit das von Ax geschilderte Szenario in der Lage ist, seinen Sicherungsbedarf vollständig abzudecken, muss er selbst herausfinden. Der geschilderte Ansatz ist auf jeden Fall interessant, weil er auch die Möglichkeit bietet, die zu sichernden Daten über ein Netzwerk auf eine andere Maschine zu übertragen - falls einmal Bedarf dafür besteht.
Bei mir persönlich sind Datenausfälle (in den letzten 15 Jahren) bisher nur durch defekte Platten aufgetreten. Eine gespiegelte Systemplatte ist so billig, dass es sich nach m. E. in jedem Falle lohnt, diesen Mechanismus als erste Schutzbarriere einzuplanen. Der Hauptvorteil liegt in der enormen Reduktion der Ausfallzeit. Zusätzlich halte ich weitere Sicherungsmaßnahmen auf jeden Fall für sinnvoll.
Mein Tipp: _Auf jeden Fall_ lieber etwas mehr Geld und Zeit in ein vernünftiges Sicherungskonzept investieren. Das ist immer billiger, als der Datenverlust. Ganz zu schweigen von dem enormen Frust. Ich weiss, wovon ich rede ;o)
Danke an alle für den netten Gedankenaustausch sowie freundliche Grüße aus dem Münsterland,
Kapinski
, wird man wohl kaum um eine
- Platte irreparabel defekt
- Schäden durch Viren, Fehlbedienung, etc. (s. o.)
- Blitzeinschlag --> kann u. U. alle angeschlossenen Platten zerstören
- Einbruchsdiebstahl --> Server mit Haupt- und Sicherungsdatenträger verloren
- Brand-/Wasserschaden
- etc..
Eine einzige Sicherung auf einem Datenträger, der sich fest im kritischen Server befindet, ist eine gefährliche Scheinsicherheit. Je nach Wert der Daten ist eine Sicherung auf externe Datenträger bzw. in externe Systeme notwendig. Sicherungsbänder kann man an einen sicheren Ort transportieren; Third-Party-Datencenter bieten Sicherungsdienste an (gegen Entgelt..); ein Sicherungs-Server an einem geschützten Ort kann u. U. einigen Schutz bieten; etc..
Neben der reinen Datensicherung ist das Thema Dasaster Recovery - ebenfalls abhängig vom jeweiligen Arbeitsumfeld - u. U. ebenso zu beachten. Das Einrichten einer komplexen Server-Umgebung mit allen Anwendungen, db, Security, etc. kann u. U. sehr viel Zeit in Anspruch nehmen.
Bei der Planung eines Sicherungskonzeptes muss man also neben den Hardware-Kosten vor allem den Wert absichern, der tatsächlich durch einen Datenverlust verursacht werden kann. Ich sehe daher keine vorkonfigurierbare Standardlösung, sondern nur ein entsprechend maßgeschneidertes Gesamtkonzept mit - falls nötig - mehreren parallelen Sicherungselementen.
Inwieweit das von Ax geschilderte Szenario in der Lage ist, seinen Sicherungsbedarf vollständig abzudecken, muss er selbst herausfinden. Der geschilderte Ansatz ist auf jeden Fall interessant, weil er auch die Möglichkeit bietet, die zu sichernden Daten über ein Netzwerk auf eine andere Maschine zu übertragen - falls einmal Bedarf dafür besteht.
Bei mir persönlich sind Datenausfälle (in den letzten 15 Jahren) bisher nur durch defekte Platten aufgetreten. Eine gespiegelte Systemplatte ist so billig, dass es sich nach m. E. in jedem Falle lohnt, diesen Mechanismus als erste Schutzbarriere einzuplanen. Der Hauptvorteil liegt in der enormen Reduktion der Ausfallzeit. Zusätzlich halte ich weitere Sicherungsmaßnahmen auf jeden Fall für sinnvoll.
Mein Tipp: _Auf jeden Fall_ lieber etwas mehr Geld und Zeit in ein vernünftiges Sicherungskonzept investieren. Das ist immer billiger, als der Datenverlust. Ganz zu schweigen von dem enormen Frust. Ich weiss, wovon ich rede ;o)
Danke an alle für den netten Gedankenaustausch sowie freundliche Grüße aus dem Münsterland,
Kapinski
, wird man wohl kaum um eine
Hallo,
Kann den Aussagen zu ntbackup von pacobay nur beipflichten.
Ich sichere die gesamte Domäne mit ntbackup. Hatte dabei auch im "Schadensfall", sprich Wiederherstellung, bisher keine Probleme. Habe den Nachteil, das ntbackup keine Remote-Sicherung bietet mit folgendem Workaround gelöst:
Szenario:
2 DCs
3 Memberserver (davon 1 SAP Server, der Offline (Batch/Task Eigenbau) gesicher wird)
Alle Server haben entweder RAID 5 bzw. RAID 10
Sicherung
Sekundärer DC ist Hauptsicherungsrechner, da dieser auch der Fileserver und User-Home-Server ist. (Momentan wird auf externe Festplatten gesichert, einzig aus Platz- und Kostengründen)
Der DC 1 ist ein SBS mit Exchange. (Diesen Server musste ich bereits zweimal über diese "remoten" Sicherungsdateien wiederherstellen, was problemlos funktionierte)
Die restlichen Server sichern lokal in eine Freigabe auf einer separaten Partition.
Diese Freigaben werden bei der Hauptsicherung mitgesichert.
Die lokalen Sicherungen werden nacch erfolgter Zentralsicherung via Batch-Skript/Task automatisch gelöscht, damit der erfoderliche Speicherplatz sich im Rahmen hält.
Vorteil:
Lokale Sicherung kann benutzt werden, wenn die separate Partition noch funktionsfähig und die Daten in der Sicherung noch valide (nicht auch schon beschädigt) sind.
Liegt der Schaden länger zurück oder die separate Partition sollte auch defekt sein, nehme ich die Daten aus der Hauptsicherung.
Nachteil
Keine wirkliche Komprimierung der Sicherungsdaten.
Erhöhter Konfigurationsaufwand.
Kontrolle der Laufzeiten (Sicherstellung das Remote-Sicherungen auch komplett gesichert werden)
Kann den Aussagen zu ntbackup von pacobay nur beipflichten.
Ich sichere die gesamte Domäne mit ntbackup. Hatte dabei auch im "Schadensfall", sprich Wiederherstellung, bisher keine Probleme. Habe den Nachteil, das ntbackup keine Remote-Sicherung bietet mit folgendem Workaround gelöst:
Szenario:
2 DCs
3 Memberserver (davon 1 SAP Server, der Offline (Batch/Task Eigenbau) gesicher wird)
Alle Server haben entweder RAID 5 bzw. RAID 10
Sicherung
Sekundärer DC ist Hauptsicherungsrechner, da dieser auch der Fileserver und User-Home-Server ist. (Momentan wird auf externe Festplatten gesichert, einzig aus Platz- und Kostengründen)
Der DC 1 ist ein SBS mit Exchange. (Diesen Server musste ich bereits zweimal über diese "remoten" Sicherungsdateien wiederherstellen, was problemlos funktionierte)
Die restlichen Server sichern lokal in eine Freigabe auf einer separaten Partition.
Diese Freigaben werden bei der Hauptsicherung mitgesichert.
Die lokalen Sicherungen werden nacch erfolgter Zentralsicherung via Batch-Skript/Task automatisch gelöscht, damit der erfoderliche Speicherplatz sich im Rahmen hält.
Vorteil:
Lokale Sicherung kann benutzt werden, wenn die separate Partition noch funktionsfähig und die Daten in der Sicherung noch valide (nicht auch schon beschädigt) sind.
Liegt der Schaden länger zurück oder die separate Partition sollte auch defekt sein, nehme ich die Daten aus der Hauptsicherung.
Nachteil
Keine wirkliche Komprimierung der Sicherungsdaten.
Erhöhter Konfigurationsaufwand.
Kontrolle der Laufzeiten (Sicherstellung das Remote-Sicherungen auch komplett gesichert werden)
@tom12
Wie hast du es geschafft einen 2. DC in eine SBS-Domäne hinzubekommen
dachte bisher dies wäre gar nicht möglich?
Pls mail me
Habe ich nicht verstanden. Sorry Könntest Du mir das erklären ?
Danke
Szenario:
2 DCs
Der DC 1 ist ein SBS mit Exchange.
2 DCs
Der DC 1 ist ein SBS mit Exchange.
Wie hast du es geschafft einen 2. DC in eine SBS-Domäne hinzubekommen
dachte bisher dies wäre gar nicht möglich?
Pls mail me
Nachteil
Keine wirkliche Komprimierung der
Sicherungsdaten.
Könntest Du nicht die Sicherung der Sicherung komprimieren?Keine wirkliche Komprimierung der
Sicherungsdaten.
Kontrolle der Laufzeiten (Sicherstellung das
Remote-Sicherungen auch komplett gesichert
werden)
Remote-Sicherungen auch komplett gesichert
werden)
Habe ich nicht verstanden. Sorry Könntest Du mir das erklären ?
Danke
Hallo
2. DC
-> Der SBS muss lediglich der Primäre DC sein, andere "Könige" sind erlaubt.
=> Normale Vorgehensweise (Serveraufgabenseite - Neue Rolle - ...)
Sicherung komprimieren:
Das verstehe ich jetzt nicht ganz, den das gesamte bkf-File nocheinmal zu zippen, wäre
a) zeitaufwendig
b) nicht sonderlich erfolgsversprechend (glaube ca. 10% max Platzgewinn)
oder meinst Du das anders?
Kontrolle der Laufzeiten:
Hiermit meine ich, dass zum Zeitpunkt der Sicherung am zentralen Server, die lokale Sicherung (die ich dann per Freigbae sichere) sicher ausgeführt sein muss. Will ja schließlich die komplette lokale Sicherung einbinden.
Des Weiteren muss das Zeitfenster groß genug sein.
2. DC
-> Der SBS muss lediglich der Primäre DC sein, andere "Könige" sind erlaubt.
=> Normale Vorgehensweise (Serveraufgabenseite - Neue Rolle - ...)
Sicherung komprimieren:
Das verstehe ich jetzt nicht ganz, den das gesamte bkf-File nocheinmal zu zippen, wäre
a) zeitaufwendig
b) nicht sonderlich erfolgsversprechend (glaube ca. 10% max Platzgewinn)
oder meinst Du das anders?
Kontrolle der Laufzeiten:
Hiermit meine ich, dass zum Zeitpunkt der Sicherung am zentralen Server, die lokale Sicherung (die ich dann per Freigbae sichere) sicher ausgeführt sein muss. Will ja schließlich die komplette lokale Sicherung einbinden.
Des Weiteren muss das Zeitfenster groß genug sein.
Sicherung komprimieren:
Das verstehe ich jetzt nicht ganz, den das
gesamte bkf-File nocheinmal zu zippen,
wäre
a) zeitaufwendig
b) nicht sonderlich erfolgsversprechend
(glaube ca. 10% max Platzgewinn)
oder meinst Du das anders?
Das verstehe ich jetzt nicht ganz, den das
gesamte bkf-File nocheinmal zu zippen,
wäre
a) zeitaufwendig
b) nicht sonderlich erfolgsversprechend
(glaube ca. 10% max Platzgewinn)
oder meinst Du das anders?
meinte ich so
aber du hast wahrscheinlich recht das diese spontane idee es wohl nicht bringt
Kontrolle der Laufzeiten:
Hiermit meine ich, dass zum Zeitpunkt der
Sicherung am zentralen Server, die lokale
Sicherung (die ich dann per Freigbae sichere)
sicher ausgeführt sein muss. Will ja
schließlich die komplette lokale
Sicherung einbinden.
Hiermit meine ich, dass zum Zeitpunkt der
Sicherung am zentralen Server, die lokale
Sicherung (die ich dann per Freigbae sichere)
sicher ausgeführt sein muss. Will ja
schließlich die komplette lokale
Sicherung einbinden.
wie stellst du das sicher ??
Sorry für die vielen Nachfragen
aber ich erstelle zur zeit ein Datensicherungskonzept für eine ähnlich aufgebaute Konstellation
und dein ansatz interessiert mich daher
Ganz grob:
Die Laufzeiten müssen über Testläufe synchronisiert werden.
Du siehst i. d. R. im Event-Log den Start, den Verlauf und den (Nicht)Erfolg der Sicherung.
Jetzt muss ich sicherstellen, dass die Rechner, die per Freigabe gesichert werden, zum Zeitpunkt der Sicherung der Freigabe diese beendet haben.
Z.B:
Remote1 : braucht 4 Std für Voll 1 für Differenz
Remote 2 braucht 2.5 Std für Voll und .5 für Differenz
Zentraler Server frägt die Sicherungen der Remoterechner ab zu einem Zeitpunkt an dem der Remotrechner fertig gesichert hat (mit Puffer! - Datenbestände können sich ja auch ändern, alternativ die Sicherungen gegebenfalls an längere/kürzere Laufzeiten anpassen)
Bei mir erfolgt die Sicherung nach obigem Schema, was aber einige Testläufe zur Synchronisierung notwendig gemacht hat. Da bei uns aber relativ wenig Verkehr am WE im Netz ist, kann ich da auch das gesamte WE Sichern, d. h. die Pufferzeiten wären auch hier noch optimierbar.
Wenn die Aussagen des Logs (am zentralen Rechner) zu ungenau sind kannst du Remoten Rechner bzw. deren Logs zur Hand nehmen.
Z.B:
Remote1 : braucht 4 Std für Voll 1 für Differenz
Remote 2 braucht 2.5 Std für Voll und .5 für Differenz
Zentraler Server sollte erst dann mit der Sicherung beginen, wenn der Remote1 fertig ist. Start der Sicherungen der Remoterechner zum selben Zeitpunkt.
Sichere Variante
unterschiedliche Sicherungsjobs für die lokale und die Remoten Sicherungen.
Falls jemand eine Möglichkeit gefunden hat, wie man einem geplanten Task beibringt, dessen erfolgreiche Beendigung zu melden, wäre das natürlich ideal.
Denn dann könnte diese Meldung zum Start der zentralen Sicherung verwendet werden.
Die Laufzeiten müssen über Testläufe synchronisiert werden.
Du siehst i. d. R. im Event-Log den Start, den Verlauf und den (Nicht)Erfolg der Sicherung.
Jetzt muss ich sicherstellen, dass die Rechner, die per Freigabe gesichert werden, zum Zeitpunkt der Sicherung der Freigabe diese beendet haben.
Z.B:
Remote1 : braucht 4 Std für Voll 1 für Differenz
Remote 2 braucht 2.5 Std für Voll und .5 für Differenz
Zentraler Server frägt die Sicherungen der Remoterechner ab zu einem Zeitpunkt an dem der Remotrechner fertig gesichert hat (mit Puffer! - Datenbestände können sich ja auch ändern, alternativ die Sicherungen gegebenfalls an längere/kürzere Laufzeiten anpassen)
Bei mir erfolgt die Sicherung nach obigem Schema, was aber einige Testläufe zur Synchronisierung notwendig gemacht hat. Da bei uns aber relativ wenig Verkehr am WE im Netz ist, kann ich da auch das gesamte WE Sichern, d. h. die Pufferzeiten wären auch hier noch optimierbar.
Wenn die Aussagen des Logs (am zentralen Rechner) zu ungenau sind kannst du Remoten Rechner bzw. deren Logs zur Hand nehmen.
Z.B:
Remote1 : braucht 4 Std für Voll 1 für Differenz
Remote 2 braucht 2.5 Std für Voll und .5 für Differenz
Zentraler Server sollte erst dann mit der Sicherung beginen, wenn der Remote1 fertig ist. Start der Sicherungen der Remoterechner zum selben Zeitpunkt.
Sichere Variante
unterschiedliche Sicherungsjobs für die lokale und die Remoten Sicherungen.
Falls jemand eine Möglichkeit gefunden hat, wie man einem geplanten Task beibringt, dessen erfolgreiche Beendigung zu melden, wäre das natürlich ideal.
Denn dann könnte diese Meldung zum Start der zentralen Sicherung verwendet werden.
@tom12
Die Möglichkeit geht via auswertung des eventlogs
bin da dran hatte gehofft, dass du etwas in der richtung hast
hänge aber zur Zeit mit dem remote zugriff
wenn mein backupmodul fertig ist lass ich es dir zukommen
ciao und danke pacobay
Falls jemand eine Möglichkeit gefunden
hat, wie man einem geplanten Task beibringt,
dessen erfolgreiche Beendigung zu melden,
wäre das natürlich ideal.
Denn dann könnte diese Meldung zum
Start der zentralen Sicherung verwendet
werden.
hat, wie man einem geplanten Task beibringt,
dessen erfolgreiche Beendigung zu melden,
wäre das natürlich ideal.
Denn dann könnte diese Meldung zum
Start der zentralen Sicherung verwendet
werden.
Die Möglichkeit geht via auswertung des eventlogs
bin da dran hatte gehofft, dass du etwas in der richtung hast
hänge aber zur Zeit mit dem remote zugriff
wenn mein backupmodul fertig ist lass ich es dir zukommen
ciao und danke pacobay
@pacobay: kannst du mir das modul auch einmal zukommen lassen? Ich stelle gerade auf 2008 um, in dem zuge wird auch gleich acronis gegen die windows serversicherung (nachfolger von ntbackup) getauscht und getestet ob das ganze zuverlässig funktioniert. sieht momentan sehr gut aus, jedoch kann man ja immer optimieren ;)
Ich habe eben die Anleitung gepostet. Kann man sich unter
Backupscript Ortsbezogen - Sicherung von Windows Systemen
ansehen, wer Interresse hat.
Backupscript Ortsbezogen - Sicherung von Windows Systemen
ansehen, wer Interresse hat.