Tape VM Restore direkt auf Host
- Thread starter Thoxel
- Start date
Nein das ist momentan nicht möglich. Der proxmox-backup-client hat keine infos über tapes/drives/changer oder das on-tape format.
was allerdings möglich ist: selektives restore von einzelnen snapshots, und danach via pve ein 'live restore'
was allerdings möglich ist: selektives restore von einzelnen snapshots, und danach via pve ein 'live restore'
Kann man das auf die "Wunschliste" setzten, wäre super spannend für Enterprise User?
Soweit ich weiß, kann man das z.B. mit Commvault, sollte somit theoretisch technisch möglich sein und könnte wie geschrieben die RTO im Desaster Fall (Kompletter Restore von Tape auf Ceph) halbieren.
Soweit ich weiß, kann man das z.B. mit Commvault, sollte somit theoretisch technisch möglich sein und könnte wie geschrieben die RTO im Desaster Fall (Kompletter Restore von Tape auf Ceph) halbieren.
Wenn Tape Restore nötig ist, dann ist schon mal ganz viel schiefgelaufen. Dann ist die Zeit zum zurückspielen wohl das kleinste der Probleme.
=> mehrere PBS hosts (zb. 3) in verschiedene Brandabschnitten, Ländern, Kontinenten. Dank des effizienten remote sync und der integrierten Verschlüsselung auf Clientseite geht das ganz einfach und sicher.
Im Enterprise Umfeld benötigt soetwas niemand. Tape wird da maximal noch als Langzeit Archiv genutzt. Backups auf Tape bei vielen TB oder im PB Bereich ist wirtschaftlich.
In der Regel hat man im Enterprise Umfeld, schnelle DIsks für das erste Backup (DR), langsame Disks für Sekundärbackup mit längerer Aufbewahrung und Archiv eventuell mal auf Tape, obwohl viele in Richtung Object Store wie z.B. S3 gehen.
Das Tape Backup ist meines Wissens immer noch die beste Variante, um Air-Gap't (offline Backup) für die Ransomware oder Intruider Angriffsschutz on-Premise zu realisieren und dabei wirtschaftlich das BCM zu gewährleisten. Der reine Online Sync zwischen PBS ist in diesen Fällen nicht ausreichend (aber natürlich ein Must-have bei der Geo-Trennung), da die Daten gelöscht oder verschlüsselt werden können. Grundsätzlich beschäftigt sich das BCM mit allen Konstellationen, auch wenn diese in der Praxis eher selten sind, aber eintreten können. Hierbei wäre der Worst-Case die Wiederherstellung der Infrastruktur über das Tape im Tresor, was faktisch schneller geht (RTO), wenn diese nicht erst auf die Disks des PBS gespeichert werden müssen, sondern direkt auf die PVE/Ceph geschoben werden können.
Sensible Daten in die Cloud (online) zu schieben, ist weiterhin fraglich.
Aber natürlich bin ich offen, meinen Horizont zu erweitern.
Sensible Daten in die Cloud (online) zu schieben, ist weiterhin fraglich.
Aber natürlich bin ich offen, meinen Horizont zu erweitern.
Ich bin seit zwei Tagen und vermutlich noch nächste Woche bei nem Kunden am restoren nach Cyberangriff. Tapes kannst du vergessen, die wurden zuerst gewiped, da die durch die langsame Geschwindigkeit auch länger in der Library sind. Ein Disk to Disk ist bei korrekter Konfiguration genau so air gapped. 2 Wochen alte Tapes willst du ja nicht Restoren.
Spätestens mit Objektspeicher und z. B. dem S3 Protokoll hast du einen Medienbruch und Air Gap, besser als Tape.
Spätestens mit Objektspeicher und z. B. dem S3 Protokoll hast du einen Medienbruch und Air Gap, besser als Tape.
Mit einer Woche alten Tape bist'e zwar nicht super happy als Unternehmer, aber dein Busnisse/Kernprozess kann weitergehen.
Wie stellst du sicher, dass dein S3 Client nicht kompromittiert wird und dadurch deine Buckets/Backups verschlüsselt/gelöscht werden? Ein 2FA ist da ja nicht gerade praktikabel.
Wie sieht es mit ISB/DSB Compliance bei einem amerikanischen Anbieter wie AWS aus, Stichwort Patriot Act?
Wie stellst du sicher, dass dein S3 Client nicht kompromittiert wird und dadurch deine Buckets/Backups verschlüsselt/gelöscht werden? Ein 2FA ist da ja nicht gerade praktikabel.
Wie sieht es mit ISB/DSB Compliance bei einem amerikanischen Anbieter wie AWS aus, Stichwort Patriot Act?
Du hast ja alle Schlagworte der MS Basher . 
Wenn der S3 Client kompromittiert ist, kann der neue defekte Backups hochladen. Solange die Retention nicht abgelaufen ist, kann auch kein Admin löschen, solange man den Bucket richtig konfiguriert.
Da man in die Cloud eh nur verschlüsselte Backups ablegt ist das alles vollkommen egal. Bei einem vernünftigen Key braucht auch die Amerikanische Regierung ein paar Jahrtausende um den Schlüssel zu knacken.
Das ist nur ein Thema, wenn du z.B. unverschlüsselt Daten in dein OneDrive hochlädst.
Der Vorteil, wenn deine Hardware abgebrannt ist, kannst du highspeed direkt in die Cloud restoren. Sowas geht auch mit deutschen Anbietern.
Wenn der S3 Client kompromittiert ist, kann der neue defekte Backups hochladen. Solange die Retention nicht abgelaufen ist, kann auch kein Admin löschen, solange man den Bucket richtig konfiguriert.
Da man in die Cloud eh nur verschlüsselte Backups ablegt ist das alles vollkommen egal. Bei einem vernünftigen Key braucht auch die Amerikanische Regierung ein paar Jahrtausende um den Schlüssel zu knacken.
Das ist nur ein Thema, wenn du z.B. unverschlüsselt Daten in dein OneDrive hochlädst.
Der Vorteil, wenn deine Hardware abgebrannt ist, kannst du highspeed direkt in die Cloud restoren. Sowas geht auch mit deutschen Anbietern.
Ich bin im Bereich Informationssicherheit, BCM und Datenschutz unterwegs. Aus der Praxis heraus habe ich dazu auch bereits einige Erfahrungen.
Grundsätzlich ist mal anzumerken, dass das BSI in den Standort-Kriterien RZ in der Version 2.0 von einer Entfernung von 200 KM für "einander Georedundanz gebender RZ" spricht. In der Regel wird man sich hieran aber für alles orientieren, was "Georedundanz" heißt. Folglich wäre auch im Rahmen des 200-4 eine lokale Bandsicherung keine georeundante Sicherung.
Zum Thema "Patriot Act" oder Cloud-Nutzung ist mal zu unterscheiden, welche Anforderungen von wem kommen. Der DSB hat dabei in der Regel bedenken am Schutz der personenbezogenen Daten, der ISB hat das Interesse daran, dass keine sensiblen Informationen (z. B. nach dem GeschGehG) dort landen und der BCB realisiert einen GFP um für den Fall der Fälle gewappnet zu sein.
Was aber keiner von diesen Parteien sagen wird, du darfst keine Cloud verwenden. Sowohl der ISB als auch der DSB werden dir sagen, dass diese Verschlüsselt übertragen werden müssen und dort keine Keys liegen dürfen. Womöglich bekommst du vom ISB bzw. dem Kryptobeauftragtem weitere Anweisungen welche Ciphers etc. zu verwenden sind.
Also, damit eine Bandsicherung im Sinne des BCM auch für den Desaster Fall geeignet wäre, müsste dieses mind. 200 KM vom produktiven Rechenzentrum aufbewahrt werden. Ein Tresor vor Ort stellt folglich damit auch kein Desaster Backup dar und kann sehr wohl auch auf Platten erfolgen. Wie ja z. B. @Falk R. auch bereits angemerkt hat. Sehrwohl ist dabei natürlich sicherzustellen, dass das Backup nicht kompromittiert werden kann. Im Desaster Fall soll aber der Geschäftsbetrieb auch schnellmöglichst wiederhergestellt sein, dazu hat man in der Regel eben genau die angesprochene Kombination aus einem aktiven System mit Festplatten, welches z. B. die letzten 14 - 30 Tage vorhält und dann eben für Langzeitarchivierung die Bänder.
Häufig haben Unternehmen aber größere Bandwechsler oder Tape Librarys im Einsatz, wo die Bänder teilweise sehr lange vor Ort verweilen, bevor diese entnommen und sicher aufbewahrt werden. Meist machen die Unternehmen dann auch den Fehler, dass sie Bänder gerne mehrfach verwenden wollen und daher keine WORM-Bänder kaufen. Diese Gesamtkombination macht das Thema Tape und Sicherheit also direkt wieder zunichte.
Gemäß BSI sind aber jegliche Datensicherungen auch fortwährend auf Ihre Integrität hin zu prüfen, es müssen auch regelmäßige Restore Tests erfolgen. Dann werden in der Regel Bänder für mind. 10 Jahre aufbewahrt, in manchen Bereichen (z. B. Gesundheit) sind es teils auch 30 Jahre. Nun muss man also sicherstellen, dass man innerhalb der 30 Jahre auch weiterhin der Lage ist diese Daten zu lesen, da LTO in der Regel aber nur 2 - 3 Versionen abwärtskompatible ist, bedeutet dies, dass man sich Laufwerke und Systeme mit geeigneten Schnittstellen (z. B. SCSI) und Softwareprodukte (Stichwort Symantec Backup Exec ^^) und Lizenzen auf Lager hält. Oder aber man migriert diese Daten alle paar Jahre auf neuere Bänder.
Inebsondere im Sinne der Wiederherstellungstests, der Lageranforderungen, Portierbarkeit etc. wird man nun also feststellen, dass Bänder ggf. teurer sind als große Speichersysteme mit Tiering am laufen zu haben.
Ich will aber auch nun gar nicht weiter ausholen, weil das Thema hier ja nicht war "Wie erstellen wir ein Backupkonzept, wer ist zu beteiligen, was ist zu Berücksichtigen und welche Risiken gibt es dabei" sondern "Tape wird im Enterprise Umfeld häufig verwendet".
Also zum Thema selbst, ja wird es, aber es ist eher für Langzeitarchivierung gedacht. Unternehmen und Behörden die ich kenne, die Sichern erst mal alles auf Platten bevor diese Daten irgendwann auf Bänder geschrieben und dann tatsächlich Georedundant aufbewahrt werden. Die Plattensysteme sollten dabei auch räumlich getrennt stehen und im bestenfall hohlt sich das eine mit Zeitverzug die Daten beim anderen ab. Datensicherungen werden generell auch eher auf Hypervisor Ebene als Server / VM ebene gemacht, eine entsprechende Netztrennung sowie sinnvolle Berechtigungen gehören hier ebenfalls dazu. Die Berechtigungen auf dem PBS kann man bereits heute so konfigurieren, dass ich zwar Backups erstellen und wiederherstellen kann, ich aber über z. B. den PVE keine löschen darf. Wenn man dann den PBS entsprechend härtet und z. B. nicht ins AD hängt oder mit MFA versieht und dann noch ein zweiter Server sich hintendran die Daten krallt - dann hat Ransomware auch nur eine geringe Chance.
Grundsätzlich ist mal anzumerken, dass das BSI in den Standort-Kriterien RZ in der Version 2.0 von einer Entfernung von 200 KM für "einander Georedundanz gebender RZ" spricht. In der Regel wird man sich hieran aber für alles orientieren, was "Georedundanz" heißt. Folglich wäre auch im Rahmen des 200-4 eine lokale Bandsicherung keine georeundante Sicherung.
Zum Thema "Patriot Act" oder Cloud-Nutzung ist mal zu unterscheiden, welche Anforderungen von wem kommen. Der DSB hat dabei in der Regel bedenken am Schutz der personenbezogenen Daten, der ISB hat das Interesse daran, dass keine sensiblen Informationen (z. B. nach dem GeschGehG) dort landen und der BCB realisiert einen GFP um für den Fall der Fälle gewappnet zu sein.
Was aber keiner von diesen Parteien sagen wird, du darfst keine Cloud verwenden. Sowohl der ISB als auch der DSB werden dir sagen, dass diese Verschlüsselt übertragen werden müssen und dort keine Keys liegen dürfen. Womöglich bekommst du vom ISB bzw. dem Kryptobeauftragtem weitere Anweisungen welche Ciphers etc. zu verwenden sind.
Also, damit eine Bandsicherung im Sinne des BCM auch für den Desaster Fall geeignet wäre, müsste dieses mind. 200 KM vom produktiven Rechenzentrum aufbewahrt werden. Ein Tresor vor Ort stellt folglich damit auch kein Desaster Backup dar und kann sehr wohl auch auf Platten erfolgen. Wie ja z. B. @Falk R. auch bereits angemerkt hat. Sehrwohl ist dabei natürlich sicherzustellen, dass das Backup nicht kompromittiert werden kann. Im Desaster Fall soll aber der Geschäftsbetrieb auch schnellmöglichst wiederhergestellt sein, dazu hat man in der Regel eben genau die angesprochene Kombination aus einem aktiven System mit Festplatten, welches z. B. die letzten 14 - 30 Tage vorhält und dann eben für Langzeitarchivierung die Bänder.
Häufig haben Unternehmen aber größere Bandwechsler oder Tape Librarys im Einsatz, wo die Bänder teilweise sehr lange vor Ort verweilen, bevor diese entnommen und sicher aufbewahrt werden. Meist machen die Unternehmen dann auch den Fehler, dass sie Bänder gerne mehrfach verwenden wollen und daher keine WORM-Bänder kaufen. Diese Gesamtkombination macht das Thema Tape und Sicherheit also direkt wieder zunichte.
Gemäß BSI sind aber jegliche Datensicherungen auch fortwährend auf Ihre Integrität hin zu prüfen, es müssen auch regelmäßige Restore Tests erfolgen. Dann werden in der Regel Bänder für mind. 10 Jahre aufbewahrt, in manchen Bereichen (z. B. Gesundheit) sind es teils auch 30 Jahre. Nun muss man also sicherstellen, dass man innerhalb der 30 Jahre auch weiterhin der Lage ist diese Daten zu lesen, da LTO in der Regel aber nur 2 - 3 Versionen abwärtskompatible ist, bedeutet dies, dass man sich Laufwerke und Systeme mit geeigneten Schnittstellen (z. B. SCSI) und Softwareprodukte (Stichwort Symantec Backup Exec ^^) und Lizenzen auf Lager hält. Oder aber man migriert diese Daten alle paar Jahre auf neuere Bänder.
Inebsondere im Sinne der Wiederherstellungstests, der Lageranforderungen, Portierbarkeit etc. wird man nun also feststellen, dass Bänder ggf. teurer sind als große Speichersysteme mit Tiering am laufen zu haben.
Ich will aber auch nun gar nicht weiter ausholen, weil das Thema hier ja nicht war "Wie erstellen wir ein Backupkonzept, wer ist zu beteiligen, was ist zu Berücksichtigen und welche Risiken gibt es dabei" sondern "Tape wird im Enterprise Umfeld häufig verwendet".
Also zum Thema selbst, ja wird es, aber es ist eher für Langzeitarchivierung gedacht. Unternehmen und Behörden die ich kenne, die Sichern erst mal alles auf Platten bevor diese Daten irgendwann auf Bänder geschrieben und dann tatsächlich Georedundant aufbewahrt werden. Die Plattensysteme sollten dabei auch räumlich getrennt stehen und im bestenfall hohlt sich das eine mit Zeitverzug die Daten beim anderen ab. Datensicherungen werden generell auch eher auf Hypervisor Ebene als Server / VM ebene gemacht, eine entsprechende Netztrennung sowie sinnvolle Berechtigungen gehören hier ebenfalls dazu. Die Berechtigungen auf dem PBS kann man bereits heute so konfigurieren, dass ich zwar Backups erstellen und wiederherstellen kann, ich aber über z. B. den PVE keine löschen darf. Wenn man dann den PBS entsprechend härtet und z. B. nicht ins AD hängt oder mit MFA versieht und dann noch ein zweiter Server sich hintendran die Daten krallt - dann hat Ransomware auch nur eine geringe Chance.
TL;DR
Ich kann mich persönlich und aus meiner Erfahrung heraus daher nur anschließen, dass Tapes nicht das erste Backupmedium sind und der Punkt daher auch aus meiner Sicht nicht so relevant ist. Viel wichtiger empfinde ich, dass das Live-Restore verbessert wird, so dass ggf. auch kein Datenverlust ensteht, sollte der Restore abbrechen (nicht, dass ich das in der Praxis schon so hatte!).
Btw. gibt es im IT-Grundschutz-Kompendium auch Umsetzungshinweise zu Bausteinen und Maßnahmen um es erst gar nicht zu einem Ransomware Befall kommen zu lassen - das scheint mir auch die elegantere Lösung zu sein (better safe than sorry)
Ev. auch hier interessant: Wir haben ein Kapitel "Ransomware Protection & Recovery" in den docs.
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery