Offsite-Backup im professionellen Bereich

[PhreakShow]

Hi zusammen.

Nehmen wir mal an man hat ein KMU mit 100 Leuten, und um die 20TB an Nutzdaten. Die IT sieht so aus:
In der Firma gibt es zwei HyperV-Maschinen (2x Xeon 4110, 128GB RAM, bissl storage), von denen eine produktiv läuft und die andere als failover gedacht ist, in unterschiedlichen Brandabschnitten aber dennoch im selben Gebäude. Dort rennen unterschiedliche VMs, angefangen vom Domain Controller über Exchange und allem was dazu gehört, zu GIT/SVN Systemen.

Das ist jetzt kein unübliches Szenario, solche Unternehmen dürfte es kiloweise geben. Wie machen die idealerweise ihr Backup? Trotz unterschiedlichen Brandabschnitten wäre es doch sehr fährlässig, nur lokal zu sichern. Die ominöse Cloud macht abhängig vom Internet, zudem ist in unseren Breiten die Internetanbindung Glückssache und gerade der upstream eher bescheiden. Für die Sicherheit der Daten müsste man auch wieder Sorge tragen.

Eine mögliche Strategie wäre, den Datenstand auf HP Microserver zu syncen. Die sind einfach mit Bitlocker oder DiskCryptor verschlüsselt und der Admin wechselt die einmal pro Tag oder Woche aus, so dass eines immer außerhalb der Gefahrenzone steht. dazu kann man dem Microserver noch 10GBE verpassen, damit der Sync nicht ewig dauert.

Wie könnte man das noch sinnvoll backuppen?

 

[Eye-Q]

Einen Server mit viel Plattenplatz anschaffen, die Erstsynchronisation der Datensicherung lokal durchführen, Rackspace in einem Rechenzentrum mieten, den Server dort hin karren und anschließend die Datensicherung inkrementell in das Rechenzentrum schieben. So behält man selbst die komplette Kontrolle über seine Daten. Mit geeigneten Produkten (die natürlich Geld kosten) kann man die zu übertragende Datenmenge auch nochmal reduzieren, teilweise ist das in die Datensicherungslösung integriert, teilweise gibt's entsprechende separate Produkte.

Wir als IT-Dienstleister bieten das auch als separate Dienstleistung an, so dass man sich selbst nicht um den Server/Plattenplatz im Rechenzentrum Sorgen machen braucht, sondern einfach nur dort (verschlüsselt) hin sichert und den Dienstleister den Rest machen lässt.

Mit mehreren Microservern kann man das natürlich auch durchführen, dann braucht man jedoch eine ausgeklügelte Strategie und eine sehr gute Dokumentation, wie was wann gemacht werden muss, wenn der Microserver getauscht wird.


Nur aus Neugier: was nutzt ihr aktuell für ein Produkt für die Datensicherung? Vielleicht gibt es ja dort schon die Möglichkeit, auch bei relativ schmaler Upload-Bandbreite die inkrementelle Sicherung in die große weite Welt zu schicken.

 

[PhreakShow]

Die Datensicherung ist ein Export der VM auf dem HyperV-Host auf ein Onsite-NAS. Dort laufen auch Backups von anderen Geräten zusammen, und alles was dort liegt wird gesammelt auf einen Gen8 Microserver geschoben. Dauert ewig wegen 1Gbit und kompletten vhdx mit allen Nutzdaten. Gefällt mir an sich, zur Not kann ich einfach die VM nehmen und auf einem Notebook booten wenn die Firma abgefackelt ist

Das was du beschreibst ist colocation? Das hatte ich mir auch überlegt, aber man ist wieder abhängig von einem funktionierenden Internetzugang.

Die ausgeklügelte Strategie ist, dass man halt einmal die Woche HP #1 mit in die Firma nimmt, HP #2 ins Auto lädt und damit heimfährt, und die Woche drauf umgekehrt. Worst case, es fehlen Daten einer Woche, wenn die Bude unter Wasser steht.
Vorteil: Man hat zwei Wochen Zeit bis das alte Backup überschrieben ist und hat ein bisschen mehr Zeit, bis man merken darf dass wichtige Dateien fehlen.

 

[konfetti]

Microserver? - also wenn dann ein anderes Medium - z.B. Band - so macht man das üblicherweise (Dann richtiges Großvater, Vater, Sohn), weil halt auch handlicher, als so ein Microserver - Bänder passen auch leichter in ein Schließfach in der Bank.

So kann man auch leichter der Aufbewahrung Rechnung tragen

Alternativ bekommt man als Firma durchaus auch synchrone Leitungen im Fiber-Bereich - da relativert sich das ganze dann.
Es ist jetzt fast 10 Jahre her, da haben wir damals eine Cloudlösung gepentestet - und dazu gehörte halt auch mal das ganze Szenario anzusehn - das waren dann 2 lokale Maschinen, die onpremise das Backup gemacht haben und wie Eye-Q schon schrieb, nur den Diff ins RZ in den verschlüsselten Container geschoben hat - auch da gabs die Option, für die Initiale Backuperstellung das ganze Lokal zu machen und den Container (z.B. auf USB-Disk) ins RZ zu geben.

Mit den Microservern halte ich das ganze doch für etwas aufwendiger...

 

[Eye-Q]

Die Datensicherung ist ein Export der VM auf dem HyperV-Host auf ein Onsite-NAS. Dort laufen auch Backups von anderen Geräten zusammen, und alles was dort liegt wird gesammelt auf einen Gen8 Microserver geschoben. Dauert ewig wegen 1Gbit und kompletten vhdx mit allen Nutzdaten.

Das macht ihr aber nicht manuell, sondern gescriptet, oder? Im ersteren Fall kann sich ein automatisiertes Backup über eine kostenpflichtige Software schon alleine dadurch lohnen, dass derjenige, der aktuell das Backup manuell erstellt, dann für andere Aufgaben zur Verfügung steht.

Gefällt mir an sich, zur Not kann ich einfach die VM nehmen und auf einem Notebook booten wenn die Firma abgefackelt ist

Das kann man mit anderen Lösungen auch, z.B. bei Veeam können VMs direkt von der Sicherungsstorage gestartet und anschließend im laufenden Betrieb auf die produktive Storage verschoben werden.

Das was du beschreibst ist colocation? Das hatte ich mir auch überlegt, aber man ist wieder abhängig von einem funktionierenden Internetzugang.

Ja, richtig, man kann sich natürlich auch einen vServer oder dedizierten Server mieten und dann das einrichten, was man will. Natürlich ist man von einem funktionierenden Internetzugang abhängig, aber die Wichtigkeit der Datensicherung und -wiederherstellung (daran hängen laut deiner Aussage um die 100 MA) sollte eine ordentliche Internetverbindung wert sein.

Die ausgeklügelte Strategie ist, dass man halt einmal die Woche HP #1 mit in die Firma nimmt, HP #2 ins Auto lädt und damit heimfährt, und die Woche drauf umgekehrt. Worst case, es fehlen Daten einer Woche, wenn die Bude unter Wasser steht.

Das lässt sich aber auch wieder sehr schwer automatisieren, es sei denn man konfiguriert beide Microserver identisch und schaut, dass die Konfigurationen auch weiterhin so identisch wie mögich bleiben. Ansonsten wird die Sicherung in einer Woche auf eine Weise, in der nächsten Woche aber auf eine andere Weise angefertigt. Auch hier ist wieder eine genaue Dokumentation unerlässlich, die ständig auf dem aktuellen Stand gehalten wird.

Vorteil: Man hat zwei Wochen Zeit bis das alte Backup überschrieben ist und hat ein bisschen mehr Zeit, bis man merken darf dass wichtige Dateien fehlen.

Bei Lösungen á la Veeam kann man einstellen, dass man mehrere wöchentliche, monatliche, vierteljährliche und jährliche Backups behalten will, dann kann auch noch deutlich mehr Zeit in's Land gehen, in der die Daten wiederhergestellt werden können. Das verhindert auch, dass Ransomware, die erst 4 Wochen nach dem Befall die Daten verschlüsselt, im Backup vorhanden ist, welches wiederhergestellt wird. Nein, das ist kein hypothetisches Szenario, so etwas gibt es.

 

[PhreakShow]

Ja das passiert automatisch. Man kommt im Laufe des Tages, stellt den mitgebrachten Microserver hin, und nach Feierabend startet der Kopiervorgang. Es wird gecheckt welcher Server grad da ist und der wird bespaßt. Wenn irgendein Fehler auftritt, Dateien nicht kopiert werden können oder irgendwas daneben geht, gibts eine Mail mit log. Funktioniert problemlos seit Jahren, auch mit regelmäßgen restore-tests.
Ich brauch keine Zusatztools, ein paar Zeilen powershell oder perl und es läuft. Da stell ich mir die Geschichte mit colocation aufwändiger vor, denn zu allem kommt ja noch dass man einen sicheren Kanal zum Server aufbauen muss, per VPN und das automatisch.

Problematisch beim Microserver ist die Dauer bei der Menge an Daten, und die schlechte Erweiterbarkeit. Mit einem Gen10 kann man Raidcontroller und 10GBE gleichzeitig stecken, aber es bleibt das Problem der Erweiterbarkeit.

 

[konfetti]

Vorteil bei Backup-Software ist ja, das diese konsistenete Stände zusammen bekommen, und ggf. dank Dedup und Compression den Bedarf des Backups deutlich verringern - Sind Deine 20TB Nutzdaten (!) denn schon auf Duplikate geprüft? - und 20TB (kommt natürlich auf das Umfeld und den Betrieb an) find ich schon extrem viel... - das hatten wir nicht mal bei meinem vorherigen AG der im produzierenden Gewerbe mit ~1000 MA tätig war... (Dank Deduprate von rund 67% rund 8TB)

 

[PhreakShow]

Nein da ist nix deduped oder komprimiert. Bisher war das auch absichtlich so, zwei Fehlerquellen weniger wenns 1:1 exakt der selbe Datenstand ist.

 

[passat3233]

Im professionellen Bereich ist die Bandsicherung durchaus üblich.
Aktuell größtes Medium ist LTO 8.
Da passen auf 1 Band 12 TB unkomprimiert und ca. 30 TB komprimiert.
Bei großen Datenbeständen nimmt man dafür Autoloader, die die Bänder automatisch wechseln und z.T. können die sogar auf mehrere Bänder gleichzeitig sichern.
Es gibt Bandlibrarys für große Rechenzentren, da stecken über 800 Bänder im Wechsler!
Die Dinger sind auch sehr schnell bzgl. der max. Datenrate.
LTO 8 schafft ca. 360-900 MB/s und wird damit z.B. durch normale HDDs und auch GBit Ethernet deutlich ausgebremst und selbst langsamere SATA SSDs sind Geschwindigkeitsbremsen.

Da ein Band ein Offlinemedium ist, ist es die Sicherung darauf vor Ausfällen durch Überspannung, Gerätedefekten etc. geschützt.

Bei jedem Unternehmen stellt sich übrigens die Frage nach der revisionssicheren Datensicherung.
D.H. die Daten so zu sichern, das die nicht mehr verändert oder überschrieben werden können.
Das ist gesetzliche Vorschrift für alle steuerrelevanten Daten (Rechnungen, Lohnabrechnungen, Buchhaltung, etc.).
Eine Sicherung auf Festplatte, NAS, Cloud, o.Ä. erfüllt nicht die gesetzlichen Vorschriften bzgl. einer revisionssicheren Datensicherung.
Bei Bändern gibt es sog. WORM-Bänder. Die lassen sich nur ein einziges Mal beschreiben (WORM = Write Once, Read Many).
Die Bänder lassen sich auch verschlüsseln, so das bei einem Diebstahl der Bänder niemand diese auslesen kann.
Bei sehr kleinen Datenmengen kann man für eine revisionssicheren Datensicherung auch CD-R, DVD-R, BD-R nehmen.
Für die revisionssichere Datensicherung ist übrigens noch anzumerken, das dafür die gesetzliche Aufbewahrungsfrist von 10 Jahren gilt.
Und damit die Daten noch ausgelesen werden können, muß man auch die entsprechende Hard- und Software, um die Daten auslesen zu können, entsprechend lange zur Verfügung haben (ebenfalls gesetzliche Vorschrift).

Bei mir in der Firma sichern wir täglich auf LTO-Bänder und die Wochensicherung wird außer Haus aufbewahrt.
Und wenn das Steuerjahr abgeschlossen ist, erfolgt eine Komplettsicherung auf WORM-Bänder.

 

[konfetti]

Schön erklärt passat

genau so machen wir das auch, naja, fast - wir haben keine WORM-Bänder, aber kleben bei dem Band, das als Jahressicherung gilt den Schreibschutz fest. - außerdem werden die Medien in der Software sowieso gesperrt - es gibt ja einige ganz brauchbare Barcode-tools, mit denen man das auch selber machen kann.

 

[PhreakShow]

Wie macht ihr das dann im Fehlerfall? Eine arme Seele gurkt zum Bankschließfach, holt die Bänder raus, ihr holt die Daten von dort und startet die VM direkt vom Band?

 

[konfetti]

Definiere Fehlerfall!

nein, wir haben ein 2-Stufiges Backup: Backup-2-Disk - und dann Disk-2-Tape -> nur das Band vom WE, welches als Wochensicherung deklariert ist, kommt außer Haus - das vom ersten Sa. im Monat wird nur alle 12 Monate überschrieben - außer das vom Januar, da es ja quasi den Bestand des kompletten Vorjahres beinhaltet -> 10Jahre (oder nie wieder überschreiben)

Im Falle einer gelöschte Datei, gibts die entweder in den Vorgängerversionen, oder wenn es die für das entsprechende System nicht gibt (Weil kein Fileserver) dann halt aus dem Backup-2-Disk - ist in der Regel jede beliebige Datei in weniger als 1h wieder da.
bei den VMs kommts auf die größe drauf an, aber neulich für nen Restore, weil die VM doch nochmal benötigt wurde, haben die 75GB rund 40 Minuten gebraucht, bis die VM gebootet und wieder in der Domäne war. - per Definition von "wennst mal Zeit hast" doch ganz schnell

Für den Desasterfall (RZ fällt aus) hätten wir jetzt ein 2tes Storage in nem anderen Gebäude als Fall-Back geplant, kost halt auch immer Geld, das u.U. nicht da ist - muss man dann argumentieren - wir dürfen das jetzt mal für 2020 ins Budget planen, mit dem Vermerk von Ausfallminimierung/Verfügbarkeitsverbesserung - damit das nicht gleich als erstes gestrichen wird "weil sich das die IT halt wünscht"...

Bisher gings ja auch so...
Kost halt immer mehr als nur "Storage und den Hobel" - grade die Lizenzen gehn da ganz schnell ins Geld.

 

[passat3233]

Professionelle Backupsoftware bietet eine sog. Disaster Recovery.
Die legt einen Notfalldatenträger an, von dem aus z.B. der Hypervisor installiert werden kann und auch die Backupsoft schon enthält.
Wenn man damit den Hypervisor wiederhergestellt hat, holt man die VMs und die Daten vom Band.
Bei kleineren Datenbeständen hat man selbst bei einem Totalausfall der Hardware das System in ein paar Stunden wieder am Laufen, sofern Ersatzhardware zur Verfügung steht.
Die genaue Dauer ist natürlich abhängig von der Größe des Datenbestandes, wie schnell die Daten komplett wiederhergestellt werden können.
Bei mir in der Firma haben wir die ganze Hardware rund um den Serverbereich doppelt.
Platten natürlich im RAID, Server mit diverser redundanter Hardware (z.B. redundante Netzteile, Netzwerkkarten etc.).
Fällt eine Komponente im Server aus, gibts ne automatische Warnung an die IT.
Und es gibt natürlich einen Wartungsvertrag mit 4 Stunden Reaktionszeit seitens des Hardwarelieferanten.
D.H. in max. 4 Stunden ist von denen ein Techniker mit den passenden Ersatzteilen im Haus und das 24/7.
Kostet natürlich, aber an so etwas darf man bei geschäftskritischen Sachen nicht sparen.

Wenn ein Unternehmen an so etwas spart ist das so, als wenn man die Uhr anhält um Zeit zu sparen.

 

[gea]

Prinzipiell sehe ich folgende Probleme

- Bänder: langsam, nicht revisionssicher, keine Redundanz, teuer (Laufwerk)
- HP Microserver mit Plattenbackup. gleiche Probleme aber schneller

Prinzipiell halte ich die Plattenoption für besser geeignet, es braucht aber keine x Microserver sondern lediglich externe Hot-Plug Platten, entweder einzelne Platteneinschübe oder eSata/externe SAS Platten-Gehäuse. Bei externen Platten kann man auch mit Mirrors arbeiten um die Datensicherheit zu erhöhen.

Wenn man das mit ZFS und Snaps kombiniert hat man auch Revisionssicherheit. ZFS Snaps sind grundsätzlich nur readonly. Zudem ist inkrementelles ZFS Backup unschlagbar schnell (selbst bei Petabyte Server unter voller Last) und nimmt auch offene Dateien mit. Prüfsummen auf Daten und Metadaten garantieren die Unversehrtheit der Daten.

Da man keine spezielle Software oder Laufwerke benötigt, ist sowas auch viele Jahre später problemlos lesbar. Wenn man die Platten turnusmäßig wiederbenutzt (mit Erhalten der alten Snaps) und dabei einen Scrub laufen läßt, ist man auch sicher dass die Daten auch nach Jahren wirklich lesbar und valide sind. Wenn man immer Plattenpaare oder ZFS copies=2 bei einer Platte nutzt, werden Fehler automatisch repariert.

Da die Platten einfach gemounted werden können, ist zudem im Disasterfall ein direkter Zugriff per iSCSI/NFS/SMB möglich. Per Clone kann man aus einen readonly Snaps ein beschreibbares Dateisystem erzeugen und sofort damit arbeiten. Der readonly Snap bleibt erhalten.

Für normales Backup hat man einen festen Backupserver idealerweise in einem anderen Brandabschnitt. Damit repliziert man beliebig minütlich bis monatsweise Dateisysteme mit Erhalt der Vorversion. Ich habe sogar zwei damit bei Ausfall eines Systems die Backups weiterlaufen. Da kann man zusätzlich die externen Hot-Plug Platten anschließen und entnehmen.

Die ZFS Snaps hat man auch auf dem eigentlichen ZFS Filer und kann da für Alltagsprobleme auf Snaps zurückgehen, entweder per "vorherige Version", Rollback oder Clone. Selbst 10000 Snaps mit Versionierung alle 15 Minuten bis jährlich sind für ZFS kein Problem. Externes Backup ist mit ZFS kein Alltagsbackup sondern reines Disasterbackup mit Versionierung oder Langzeit-Archivierung.

 

[passat3233]

Natürlich sind Bänder revisionssicher.
Man muß dazu nur WORM-Bänder benutzen.
Und LTO-Bänder sind nicht langsam.
Wie schon geschrieben bringt die Geschwindigkeit von LTO 8 selbst SATA SSDs ins Schwitzen.
Bei Bändern ist zwar das Laufwerk teuer, das Band dagegen aber sehr billig.
So ein LTO 7-Band mit nativ 6 TB kostet nur 60,- €. Die billigste Festplatte mit dieser Kapazität kostet fast 3 mal so viel.
Wenn man das auf 20 Bänder LTO 7 hochrechnet, ist das Band inkl. Laufwerk ungefähr genauso teuer wie 20 Festplatte á 6 TB.
Und wenn man ein LTO 8 Laufwerk nimmt, kann man LTO 7 Bänder auf LTO 8M umkonfigurieren. Dann gehen da anstatt 6 TB nativ 9 TB nativ drauf.

 

[gea]

Ein Beispiel:
man möchte 20 TB sichern und dann stündlich eine Versionierung/Backup.

Das erstmalige Übertragen des Datenbestandes erfolgt in der sequentiellen Performance des Mediums, egal ob Plattenarray oder Band. Wenn man dann aber die Änderungen speichern möchte (stündlich), so dauert die incrementelle Replikation zum Sichern der Änderungen bei ZFS < 1 min auch mit offenen Dateien, auch bei einem Hochlastserver. Der Platzbedarf der Änderungen entspricht nur den geänderten Datenblöcken und ist nicht filebasiert. Auf eine Platte oder ZFS Backup Pool gehen also viele Versionen.

Noch geringer ist die Zeit der Wiederherstellung oder der Zeit für den Zugriff z.B. die Sicherung von letzter Woche mittags 15:00. Bei Platten muss man nichts wieder einspielen. Der Zugriff auf diese readonly Version/Snap geht direkt, ohne Zeitverzug da man nichts zurückspielen muss. Selbst ein direktes Hochfahren einer VM aus dem Backuparray ist möglich.

Natürlich gibt es Anwendungen wo Bänder mehr Sinn machen insbesondere wenn man nur die Kosten der Bänder betrachtet und große Datenmengen sehr oft extern sichern/archivieren möchte. Bei einem Backupserver an dem man ein oder zwei Hot-Plug Platten Arrays für externes Backup anschließt dürften die Kosten ähnlich sein.

 

[VirtuGuy]

Das erstmalige Übertragen des Datenbestandes erfolgt in der sequentiellen Performance des Mediums, egal ob Plattenarray oder Band. Wenn man dann aber die Änderungen speichern möchte (stündlich), so dauert die incrementelle Replikation zum Sichern der Änderungen bei ZFS < 1 min auch mit offenen Dateien, auch bei einem Hochlastserver. Der Platzbedarf der Änderungen entspricht nur den geänderten Datenblöcken und ist nicht filebasiert. Auf eine Platte oder ZFS Backup Pool gehen also viele Versionen.

Das macht heute eigentlich jedes moderene Storage/Filesystem. Man muss aber beachten, ein simpler Snapshot ist nur bedingt als Backup geeignet. Man hat im Fall der Fälle kein konsistentes Backup, sondern nur ein konsistentes Filesystem. Von daher haben praktisch alle großen Hersteller entsprechente Schnittstellen/Agents für gängige Backup Software (Veeam,...).

 

[gea]

Der Ansatz mit ZFS ist meist anders.

Die VMs liegen hier üblicherweise auf einem ZFS Storage der ein NFS Share zur Verfügung stellt. Ein ZFS Snapshot auf diesem NFS ist in der Tat nicht konsistent und entspricht dem Status nach einem Systemausfall. Für ZFS kein Problem, für das VM Gast-Dateisystem teils schon. Der einfachste Weg, das zu lösen ist es, vor dem ZFS Snap einen ESXi Snap zu erstellen damit dieser im ZFS Snap enthalten ist und den ESXi Snap nach dem ZFS Snap zu löschen. Damit kann man auf konsistente ZFS Snaps zurückgehen und das Dateisystem auf ein Backupsystem replizieren.

Sowas machen die Backup-programme auch - es entfällt aber der komplette Datentransfer eines Backups. Versionierungen sind direkt auf dem NFS und ZFS Replikation ist das schnellste (inkrementelle) Backupverfahren auf ein externes Backupsystem.

Unabhängig davon kann man auch herkömmliche Backups auf einen ZFS Filer laufen lassen und dort versionieren. Es ging ja eher um die Frage Bandbackup vs Diskbackup mit ZFS Snaps und ZFS Replikation.

 

[konfetti]

Naja, aber für den beschriebenen Fall kann man ja dann auch gleich auf die VDP von VMware zurückgreifen und spart sich das händische geskripte - abgesehn davon, das die Anforderung an ein Backup bei Tape ja durchaus auch der Medienbruch ist - Cryptotrojaner & Co. mal mitbetrachtet - da sind zumindest alle Daten die auf dem Band vor dem Vorfall waren noch vorhanden und eben abgeschlossen - ein solcher Desasterfall sollte aber generell getrennt betrachtet werden und auch mit in die Business Continuity einfließen.

Wir haben bei uns klassicherweise 4 mögliche Szenarien mit Handlungsanweisungen definiert, die dann entsprechend der Dokumentation auch Regelmäßig geprüft werden - das Beste Backup bringt ja nichts, wenn man die Rücksicherung nicht auch mal probiert.

Szenario 1: Einzelne Dateien sind verloren gegangen/vor längerem versehentlich gelöscht worden und müssen Wiederhergestellt werden - Zeitpunkt relativ frei wählbar.
Szenario 2: Ein Server ist nicht mehr verfügbar - Nichtkorrigierbarer Fehler nach Update / Inkonsistente Disk / Plattencrash bei HW... - Zeitpunkt so kurz wie möglich - im Rahmen des Backup vermutlich letzte Nacht
Szenario 3: Ein Virtualisierungshost ist ausgefallen - überprüfen der Übernahme in HA - ggf. nacharbeiten / Dienste starten / Platten richtig geladen...
Szenario 4: Ausfall eines kompletten Serverraumes inkl. Netzwerkanbindunge etc...

Für diese Szenarien sind Wiederherstellungszeiten in einer QSU soweit möglich getestet und dann definiert worden - es bringt ja nichts 2h Wiederanlauf auf dem Papier zu haben, wenn man dann trotzdem min. 5h braucht...
Für diese Tests hebe ich eben eine gewisse Menge an AltServern auf - klappt ganz gut.

 

[passat3233]

Es müssen nicht einmal Cryptotrojaner & Co. sein.
Es reicht schon z.B. ein Blitzeinschlag und die komplette Hardware inkl. aller Online-Backup-Storages sind im Eimer.
Deshalb sollte man immer auch regelmäßig ein Offline-Backup machen, sei es per Band oder z.B. per Festplatte o.Ä., die nur während des Backupvorgangs angestöpselt ist.

Und regelmäßige Checks, ob denn das Backup auch sauber durchgelaufen ist, verstehen sich von selbst.
Ich kenne da einen Fall, der einer Firma fast die Existenz gekostet hat:
Da wurden regelmäßig Backups gemacht, niemand hat sich aber berufen gefühlt, auch mal zu prüfen, ob die Backups auch fehlerfrei durchlaufen.
Der Server hatte zwar ein RAID 5, aber auch da hat niemand mal regelmäßig die Logs angeschaut, ob das noch störungsfrei läuft.
Und eines Tages ist dann das RAID 5 ausgestiegen.
Man hat dann festgestellt, das eine der Platten schon über 1 Jahr tot war und das RAID nur noch mit 2 Platten im Notbetrieb lief. Als dann auch noch eine 2. Platte ausfiel, wars das.
Man meinte, OK, machen wir neue Platten rein und spielen das letzte Backup zurück.
Dann hat man erschreckt festgestellt, das das Backup schon seit einigen Monaten gar nicht mehr fehlerfrei durchgelaufen war.
Das letzte brauchbare Backup war also mehrere Monate alt.
Resultat: Die Firma war viele Wochen nahezu handlungsunfähig und ist nur knapp an der Pleite vorbeigekommen.

Zu Snapshots etwas:
Mach das mal mit einem DC und wundere dich beim Wiederherstellen des DCs aus den Snapshot.
Wenn du viel Glück hast, gehts gut. In den meisten Fällen gehts aber nicht gut.

 

[besterino]

Fakt ist wohl, Backup ist Profi-Sache.

Ein mir bekanntest Startup muss sich da auch gerade Gedanken zu machen. Vorteil: grüne Wiese (keine on-prem Legacy, noch überschaubare Datenmenge usw.)... Nachteil: keine Kohle, keine Ressourcen (=Leute, die sich mit sowas auskennen), voll-digitales Geschäftsmodell...

Da verweise ich auch nur auf Dienstleister/Leute, die das hauptberuflich machen.

 

[Nemac]

Es müssen nicht einmal Cryptotrojaner & Co. sein.

Und regelmäßige Checks, ob denn das Backup auch sauber durchgelaufen ist, verstehen sich von selbst.

Schrodinger Backups: The condition of any backup is unknown until a restore is attempted..

SCNR