GuentherH 61 Geschrieben 31. Januar 2013 Melden Teilen Geschrieben 31. Januar 2013 Was passiert wenn ich die vorhandene Backupdateien auf dem Datenträger immer lösche bevor eine neue Sicherung erfolgt? Das geht nur sehr aufwändig und ist auch nicht notwendig. Windows Backup bereinigt selbst den Platz und löscht ältere Daten. LG Günther Zitieren Link zu diesem Kommentar
lionheart 12 Geschrieben 31. Januar 2013 Melden Teilen Geschrieben 31. Januar 2013 Aufwendig ist das eigentlich nicht. Habe genau aus diesem Grund bisher immer mit einem WBADMIN Skript gearbeitet, welches per Aufgabeplanung ausgeführt wird. In diesem Skript wird das Zielvolume vor dem Backup bereinigt. Das ist also nicht erforderlich? Sobald der Speicherplatz auf dem Medium für die neue Sicherung nicht mehr ausreicht, werden ältere Generationen gelöscht? Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 31. Januar 2013 Melden Teilen Geschrieben 31. Januar 2013 Habe genau aus diesem Grund bisher immer mit einem WBADMIN Skript gearbeitet, welches per Aufgabeplanung ausgeführt wird. In diesem Skript wird das Zielvolume vor dem Backup bereinigt. Naja, dann hast du ein Backup. Und wenn du vorher das alte Backup löscht, dann das neue fehlschlägt, dann hast du überhaupt kein Backup mehr. Unterscheide einfach einmal zwischen Filebasierendem Backup und Block-Level Backup. Das sind zwei Paar Schuhe, oder auch Vergangenheit und Gegenwart ;) LG Günther Zitieren Link zu diesem Kommentar
lionheart 12 Geschrieben 31. Januar 2013 Melden Teilen Geschrieben 31. Januar 2013 Naja, dann hast du ein Backup. Und wenn du vorher das alte Backup löscht, dann das neue fehlschlägt, dann hast du überhaupt kein Backup mehr. Unterscheide einfach einmal zwischen Filebasierendem Backup und Block-Level Backup. Das sind zwei Paar Schuhe, oder auch Vergangenheit und Gegenwart ;) LG Günther Ja, aber ich habe noch das Backup auf dem Datenträger von gestern! :) Aber du hast im Prinzip schon recht. Wenn das Block-Level Backup sich direkt um den Speicherplatz kümmert, dann soll es mir recht sein. War mir bisher nur so noch nicht bewusst. :suspect: Danke! :jau: Zitieren Link zu diesem Kommentar
zapp1000 10 Geschrieben 1. Februar 2013 Autor Melden Teilen Geschrieben 1. Februar 2013 Ich kenne das Prinzip von Linux (rsync, rsnapshot, Hardlinks) - Alle Fullbackups zeigen auf die selben Blöcke... Mit Windows Server Backup kann man anscheinend keine gemappten Laufwerke sichern, das wäre aber wichtig! Mir schwebt folgendes vor: Ich lege auf dem Quell Server einen User an, und gebe ihm nur Lese-Rechte auf das zu sicherde freigegebene Verzeichnis. Am Backupserver reichte ich einen Job ein der mit den Nur-Lese-Rechten die Daten über UNC abholt. Wenn den zweiten Server jemand hackt, dann kann er nur die Sicherungen vernichten, nicht aber die Quelldaten - da er nur leserecht hat. Oder aber der Quell Server wird gehackt, dann bleibt die Sicherung heil. Aber wie gesagt, über UNCs scheint Windows Server Backup nicht sichern zu können. Hat jemand dazu eine Idee? Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 2. Februar 2013 Melden Teilen Geschrieben 2. Februar 2013 (bearbeitet) Sicherungen von Remotespeicher wird von wbadmin nicht unterstützt: http://social.technet.microsoft.com/Forums/en-US/windowsbackup/thread/190df893-1b35-4736-a6a2-410172cf409c/ Was Du aber machen kannst, ist Robocopy dafür zu benutzen. Sprich: Erst mit Robocopy eine Sicherung der Remotefreigaben auf Dateiebene lokal ablegen, und nach Fertigstellung dann mit WBAdmin lokal blocklevel-basiert. Oder Du sicherst auf dem 2. Server auch per WBAdmin auf dem 1. Server per UNC-Pfad, und danach halt alles nochmals per WBAdmin. Wobei ich Dir dafür eher eine Dritanbieter-Lösung empfehlen würde. bearbeitet 2. Februar 2013 von iDiddi Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 2. Februar 2013 Melden Teilen Geschrieben 2. Februar 2013 Wenn den zweiten Server jemand hackt, dann kann er nur die Sicherungen vernichten, nicht aber die Quelldaten - da er nur leserecht hat. Oder aber der Quell Server wird gehackt, dann bleibt die Sicherung heil. Und du glaubst, wenn ein Server gehackt wird, dass nicht im Nu auch der 2. gehackt wird. ;) Warum machst du dir eigentliche solche Sorgen, dass dein Server gehackt wird? Ich würde eher an deiner Stelle einmal ein anderes Szenario durchtesten wie z.B. beim DC ist das Mortherboard defekt. Kannst du jetzt mit deinen Sicherungen innerhalb vernünftiger Zeit wieder das AD zum Laufen bringen? LG Günther Zitieren Link zu diesem Kommentar
zahni 560 Geschrieben 2. Februar 2013 Melden Teilen Geschrieben 2. Februar 2013 Auch mein Tipp: Denkt mehr über das Restore nach und testet alle notwendigen Szenarien. Festplatten sind für mich höchstens ein Zwischenschritt aus Performance-Gründen. Und nicht vergessen, dass man plötzlich mal von der wichtigen Anwendung ein Restore von Uralt braucht. Zitieren Link zu diesem Kommentar
zapp1000 10 Geschrieben 2. Februar 2013 Autor Melden Teilen Geschrieben 2. Februar 2013 (bearbeitet) Und du glaubst, wenn ein Server gehackt wird, dass nicht im Nu auch der 2. gehackt wird. Wir verwende kein AD. Und das Admn kennwort wird von mir ausschliesslich über einen tsclient von einer Linux Live CD eingegeben - Keylogger haben hier keine Chance. Updates werden Wöchentlich oder 14tägig eingespielt. Die Server werden ausschliesslich als Fileserver verwendet. Wenn wirklich einer der Server gehackt werden würde, denke ich schon, dass nicht automatisch der zweite fällig wäre... und mit diesem Konzept denke ich, dass das schon halbwächs sicher wäre: Ich lege auf dem Quell Server einen User an, und gebe ihm nur Lese-Rechte auf das zu sicherde freigegebene Verzeichnis. Am Backupserver richte ich einen Job ein der mit den Nur-Lese-Rechten die Daten über UNC abholt. Wenn den zweiten Server jemand hackt, dann kann er nur die Sicherungen vernichten, nicht aber die Quelldaten - da er nur leserecht hat. Oder aber der Quell Server wird gehackt, dann bleibt die Sicherung heil. bearbeitet 2. Februar 2013 von zapp1000 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.