39
Backupstrategie
Nabend Zusammen,
wir bekommen es ja leider alle immer wieder mal mit, dass es auch große Firmen gibt, die von irgendwelchen Verschlüsselungstrojanern verseucht werden.
Aktuell sicher ich die VMs mit Veeam auf ein NAS.
Nun hab ich gesagt, dass man die Sachen zumindest jeden Tag auf wechselnde externe Festplatten kopiert - sprich Handarbeit ist angesagt.
Wie handhabt ihr das um ein Backup vor einer Verschlüsselung zu sichern?
Grüße
wir bekommen es ja leider alle immer wieder mal mit, dass es auch große Firmen gibt, die von irgendwelchen Verschlüsselungstrojanern verseucht werden.
Aktuell sicher ich die VMs mit Veeam auf ein NAS.
Nun hab ich gesagt, dass man die Sachen zumindest jeden Tag auf wechselnde externe Festplatten kopiert - sprich Handarbeit ist angesagt.
Wie handhabt ihr das um ein Backup vor einer Verschlüsselung zu sichern?
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667628
Url: https://administrator.de/contentid/667628
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
39 Kommentare
Neuester Kommentar
Moin,
Eigentlich recht simpel:
VEEAM liegt in einem eigenen VLAN und kann nur mit dem vCenter sprechen.
VEEAM sichert zuerst auf Disk (Storage im SAN) und von dort auf Tapes, welche sich in einer Library befinden.
Die Tapes werden dann regelmäßig entnommen.
Es gibt KEINEN Server, der direkten Kontakt mit VEEAM hat.
Nichtmal RDP ist freigegeben. Administriert wird die Kiste via IPKVM/ IPMI/ iDrac. Status-Infos gegen per MAIL raus.
Eigentlich recht simpel:
VEEAM liegt in einem eigenen VLAN und kann nur mit dem vCenter sprechen.
VEEAM sichert zuerst auf Disk (Storage im SAN) und von dort auf Tapes, welche sich in einer Library befinden.
Die Tapes werden dann regelmäßig entnommen.
Es gibt KEINEN Server, der direkten Kontakt mit VEEAM hat.
Nichtmal RDP ist freigegeben. Administriert wird die Kiste via IPKVM/ IPMI/ iDrac. Status-Infos gegen per MAIL raus.
1
Wir kopieren tägliche Sicherungen klassisch auf LTO Tapes, die nach dem Kopieren ausgeworfen werden.
Danke euch. Bei den Tapes ist aber dann auch Handarbeit angesagt. Ob sie dann nun Platten anklemmen, was erheblich günstiger wäre, oder die Tapes wechseln spielt dann letztlich keine Rolle.
@em-pie: Hab nen Hyper-V als Host laufen.
@em-pie: Hab nen Hyper-V als Host laufen.
Ein NAS ist nur ein temporäres Backup, meiner Meinung nach. Bänder kannst du archivieren und vor dem Überschreiben schützen. Was machst du denn, wenn du 2 Jahre alte Daten wiederherstellen musst und diese auf dem NAS nicht mehr vorhanden sind? Wenn du meinst, es war noch nie notwendig und ihr braucht das nicht, dann warte ab bis ihr z.B. einen Rechtsstreit mit einem unliebsamen Mitarbeiter habt. Bänder (oder Magazine) wechseln gehören zum IT-Tagesgeschäft 
Im übrigen sind auch z.B. Honeypots durchaus üblich. Also überwachte Verzeichnisse. Werden diese manipuliert, kann man z.B die Server oder Clients runterfahren lassen (oder andere Aktionen ausführen) Das geht auch mit Bordmitteln, z.B. mit dem FSRM (auf dem Client per Batch bzw. Aufgabe).
Auch kann man z.B. die alten Office-Formate, die per Mail kommen, entweder erst in die Quarantäne verschieben oder gleich blockieren. Das Haupteinfallstor sind Mails und hier sollte man auch was machen. Auch eine UTM mit HTTPS Proxy inkl. AV schützt.
Im übrigen sind auch z.B. Honeypots durchaus üblich. Also überwachte Verzeichnisse. Werden diese manipuliert, kann man z.B die Server oder Clients runterfahren lassen (oder andere Aktionen ausführen) Das geht auch mit Bordmitteln, z.B. mit dem FSRM (auf dem Client per Batch bzw. Aufgabe).
Auch kann man z.B. die alten Office-Formate, die per Mail kommen, entweder erst in die Quarantäne verschieben oder gleich blockieren. Das Haupteinfallstor sind Mails und hier sollte man auch was machen. Auch eine UTM mit HTTPS Proxy inkl. AV schützt.
Naja, wenn du die 3-2-1-Regel befolgen wirst, kommst du ohne Handarbeit ohnehin nicht aus, außer du hast ausreichend Bandbreite (Upload), um in ein anderes RZ zu replizieren.
Du kannst auch eine kleine Tapelibrary einsetzen. Das ist, gegen einen Verschlüsselungstrojaner auch sicher. Der Trojaner an sich wird ja den VEEAM nicht auffordern, ein bestimmtes Band aus dem Slot ins Drive zu bewegen.
Wir nehmen die Bänder nur Montags raus, lagern die extern ein und bringen die nach vier Wochen wieder.
Und ob ein Tape günstiger ist, als vier Platten, sei mal fraglich.
Das Tape als solches (LTO8) liegt bei rund 90€.
Drive + Lib, 4-5k €
Rechne mal, was dich das alles kostet, wenn du 20 HDDs mit je 12 TB erwirbst.
Edit:
Hyper-V ist doch in dem Grundkonstrukt wie VMware.
Die Nimm ein dediziertes NAS, binde es per iSCSI an VEEAM an und gut.
Wir haben alles per FC angebunden, da kann Veeam dann via FC die VMs sichern, da VEEAM die VMware Datastores sieht, die aber nicht in der selben Zone wie das Backup-Storage liegen.
Du kannst auch eine kleine Tapelibrary einsetzen. Das ist, gegen einen Verschlüsselungstrojaner auch sicher. Der Trojaner an sich wird ja den VEEAM nicht auffordern, ein bestimmtes Band aus dem Slot ins Drive zu bewegen.
Wir nehmen die Bänder nur Montags raus, lagern die extern ein und bringen die nach vier Wochen wieder.
Und ob ein Tape günstiger ist, als vier Platten, sei mal fraglich.
Das Tape als solches (LTO8) liegt bei rund 90€.
Drive + Lib, 4-5k €
Rechne mal, was dich das alles kostet, wenn du 20 HDDs mit je 12 TB erwirbst.
Edit:
Hyper-V ist doch in dem Grundkonstrukt wie VMware.
Die Nimm ein dediziertes NAS, binde es per iSCSI an VEEAM an und gut.
Wir haben alles per FC angebunden, da kann Veeam dann via FC die VMs sichern, da VEEAM die VMware Datastores sieht, die aber nicht in der selben Zone wie das Backup-Storage liegen.
1
Vor allem jetzt gerade. Die Platten sind preislich explodiert....
Mehrstufiges Backup, die letzte Stufe per pull statt push die Daten holt und daher nicht überschrieben oder verschlüsselt werden kann.
Der pull-Server liegt hinter einen Firewall die keinen "reinläßt", sondern nur Verbindungen raus.
Dazu regelmäßig offsite-Backups.
lks
Der pull-Server liegt hinter einen Firewall die keinen "reinläßt", sondern nur Verbindungen raus.
Dazu regelmäßig offsite-Backups.
lks
1
Wirklich gefährdet ist eigentlich nur unser Fileserver und dieser macht 3 mal am Tag Snapshots. Jedes Snapshot wird vom Backupserver geholt und abgelegt. Täglich wird der Inhalt des Backupservers auf großen Disks gesichert, die als Offline-Backups in einem Tresor in einem anderen Brandabschnitt liegen. Im Zweifelsfall können wir auf ältere Snapshots zurückgreifen und wenn es ganz schlimm kommt, dann wird ein Offline-Backup aus dem Schrank geholt. Man kann uns einen Teil des Tagesstands versauen, aber nicht den ganzen Server und schon gar nicht mehrere Tage oder Wochen.
Zitat von @Inf1d3l:
Ein NAS ist nur ein temporäres Backup, meiner Meinung nach. Bänder kannst du archivieren und vor dem Überschreiben schützen. Was machst du denn, wenn du 2 Jahre alte Daten wiederherstellen musst und diese auf dem NAS nicht mehr vorhanden sind? Wenn du meinst, es war noch nie notwendig und ihr braucht das nicht, dann warte ab bis ihr z.B. einen Rechtsstreit mit einem unliebsamen Mitarbeiter habt. Bänder (oder Magazine) wechseln gehören zum IT-Tagesgeschäft
Wird bei dem Kunden nicht vorkommen.Ein NAS ist nur ein temporäres Backup, meiner Meinung nach. Bänder kannst du archivieren und vor dem Überschreiben schützen. Was machst du denn, wenn du 2 Jahre alte Daten wiederherstellen musst und diese auf dem NAS nicht mehr vorhanden sind? Wenn du meinst, es war noch nie notwendig und ihr braucht das nicht, dann warte ab bis ihr z.B. einen Rechtsstreit mit einem unliebsamen Mitarbeiter habt. Bänder (oder Magazine) wechseln gehören zum IT-Tagesgeschäft
Im übrigen sind auch z.B. Honeypots durchaus üblich. Also überwachte Verzeichnisse. Werden diese manipuliert, kann man z.B die Server oder Clients runterfahren lassen (oder andere Aktionen ausführen) Das geht auch mit Bordmitteln, z.B. mit dem FSRM (auf dem Client per Batch bzw. Aufgabe).
Verzeichniszugriffe werden protokolliert.
Auch kann man z.B. die alten Office-Formate, die per Mail kommen, entweder erst in die Quarantäne verschieben oder gleich blockieren. Das Haupteinfallstor sind Mails und hier sollte man auch was machen. Auch eine UTM mit HTTPS Proxy inkl. AV schützt.
Ist vorhanden.Hat nur nicht wirklich was mit meiner Frage zu tun
Aber dennoch Danke.Zitat von @em-pie:
Naja, wenn du die 3-2-1-Regel befolgen wirst, kommst du ohne Handarbeit ohnehin nicht aus, außer du hast ausreichend Bandbreite (Upload), um in ein anderes RZ zu replizieren.
Okay. Hab ich mir schon gedacht. Wollte das nur sicher stellen, weil ich dem Kunden das auch schon sagte, was ihm aber nicht gefällt.Naja, wenn du die 3-2-1-Regel befolgen wirst, kommst du ohne Handarbeit ohnehin nicht aus, außer du hast ausreichend Bandbreite (Upload), um in ein anderes RZ zu replizieren.
Man kann ja auch nicht immer alles mitbekommen, was nun möglich ist und welche Alternativen es gibt.
Du kannst auch eine kleine Tapelibrary einsetzen. Das ist, gegen einen Verschlüsselungstrojaner auch sicher. Der Trojaner an sich wird ja den VEEAM nicht auffordern, ein bestimmtes Band aus dem Slot ins Drive zu bewegen.
Wir nehmen die Bänder nur Montags raus, lagern die extern ein und bringen die nach vier Wochen wieder.
Klingt erstmal interessant, aber wird dem Kunden zu teuer.Wir nehmen die Bänder nur Montags raus, lagern die extern ein und bringen die nach vier Wochen wieder.
Und ob ein Tape günstiger ist, als vier Platten, sei mal fraglich.
Das Tape als solches (LTO8) liegt bei rund 90€.
Drive + Lib, 4-5k €
Rechne mal, was dich das alles kostet, wenn du 20 HDDs mit je 12 TB erwirbst.
Edit:
Hyper-V ist doch in dem Grundkonstrukt wie VMware.
Die Nimm ein dediziertes NAS, binde es per iSCSI an VEEAM an und gut.
Wir haben alles per FC angebunden, da kann Veeam dann via FC die VMs sichern, da VEEAM die VMware Datastores sieht, die aber nicht in der selben Zone wie das Backup-Storage liegen.
Zitat von @Lochkartenstanzer:
Mehrstufiges Backup, die letzte Stufe per pull statt push die Daten holt und daher nicht überschrieben oder verschlüsselt werden kann.
Der pull-Server liegt hinter einen Firewall die keinen "reinläßt", sondern nur Verbindungen raus.
Dazu regelmäßig offsite-Backups.
lks
Mehrstufiges Backup, die letzte Stufe per pull statt push die Daten holt und daher nicht überschrieben oder verschlüsselt werden kann.
Der pull-Server liegt hinter einen Firewall die keinen "reinläßt", sondern nur Verbindungen raus.
Dazu regelmäßig offsite-Backups.
lks
Das klingt interessant. Wie läuft das mit dem Pull? Hast du dazu mal Infos?
Danke dir
@it-fraggle
Ihr habt nur Snspshots?
Wie lange braucht ihr für einen Restore einer ganzen VM? Oder habt ihr zwischendurch (wöchentlich) auch mal ein FullBackup? Das würde ja sonst erwog dauern, bis dass die Kette bis hin zu einer ganzen VM gemerged ist!?
Ihr habt nur Snspshots?
Wie lange braucht ihr für einen Restore einer ganzen VM? Oder habt ihr zwischendurch (wöchentlich) auch mal ein FullBackup? Das würde ja sonst erwog dauern, bis dass die Kette bis hin zu einer ganzen VM gemerged ist!?
Es geht mir nur um den Fall der Fälle, dass morgen jemand das Netz verseucht und wir ein Offlinebackup vom Vortag haben. Mehr ist nicht relevant. D.h. es reichen 5 Platten und viel Daten sind es nicht die gesichert werden müssen.
Du musst ja „nur“ schauen, dass in den Backups der 5 Tage der Trojaner nicht schon existiert und jederzeit losrennen will. Wobei dir das auch mit jeder anderen Strategie passieren kann.Edit:
Hyper-V ist doch in dem Grundkonstrukt wie VMware.
Die Nimm ein dediziertes NAS, binde es per iSCSI an VEEAM an und gut.
Wir haben alles per FC angebunden, da kann Veeam dann via FC die VMs sichern, da VEEAM die VMware Datastores sieht, die aber nicht in der selben Zone wie das Backup-Storage liegen.
Bei @lks -PullPrinzip würde in deinem Fall ein weiteres System dann die Daten vom iscsi-Target aufs Band schieben
@em-pie, gut da hast du natürlich recht. Es soll ja natürlich nicht nur ein Tag drauf liegen, sondern natürlich mehrere "Montage", "Dienstage" usw.
Dann müsste ich doch das iscsi Target auf mehreren Systemen einbinden? Oder wie läuft das dann? Als Freigabe?
Dann müsste ich doch das iscsi Target auf mehreren Systemen einbinden? Oder wie läuft das dann? Als Freigabe?
Das klingt interessant. Wie läuft das mit dem Pull? Hast du dazu mal Infos?
Das ist ein einfaches rsync per SSH.
lks
1
Hi
dediziertes Netzwerk (Wenn möglich auf einer eigenen Hardware. Also eigene Switche und eigene Firewall was allesamt nicht im normalen Managementnetz hängt) in der die Backupumgebung steht. Server, Tapelib usw. Nichts und niemand darf eine Verbindung dahin öffnen. Gemanaged wird das ganze über einen eigenen PC der in dem Netz hängt und nur bei Bedarf gestartet wird. Nichts in dem Netz hat Internet.
Damit ist sichergestellt das von außen keiner an das Netz kommt.
Die gesamte Backupinfrastruktur, ist NICHT in der Domäne. Es gibt eigene Kennwörter für alles.
Die Backupsoftware holt sich dann die Backups auf Disk. Von da gehen die Daten auf Band. Die Bänder werden nach dem Sichern ausgeworfen und in einen Safe gepackt. Möglichst täglich.
Ggf kommen die auch in das Backupsystem und sagen dem schon vor 2 Monaten das die Backups alle mit Kennwort versehen werden sollen. Und dann sind die letzten 2 Monate alle verschlüsselt, mit einem Kennwort das man nicht kennt. Dann hilft das Band einem auch nichts mehr.
Klingt unrealistisch? 2 Mittelständler hier in der Umgebung haben genau so alles verloren. Die Angreifer sind in den Core Router gekommen und hatten damit Zugriff auf das Management Netz. Cisco mit ca 1 Jahr alter Firmware. Darüber sind sie auf die Firewall und haben sich das Backupnetz geöffnet. Damit haben sie dann die Tapelib übernommen, alle Bänder darin gelöscht, die Maglib gecrypted und der Netapp alle Snapshots gelöscht.
Game over. Alles weg. Eine Firma hat zu gemacht, die andere hat mit 3 Monate alten Daten von Band recovered und ist seitdem im Überlebenskampf.
Verabschiedet euch von dem Gedanken das da irgendeine Datei ausgeführt wird und die dann stumpf alles Platt macht was sie in die Finger bekommt. Die öffnen nur das Tor. Dann guckt sich da einer um und schaut wie viel Geld die Firma so macht. Und dann kommt einer, der sich weiter durch das Netz frisst um am Ende die Bombe hochgehen zu lassen.
Führt mich zum Thema Monitoring:
Das Backupsystem hat hoffentlich Events für Dinge wie Änderungen am System, wie z.B dass das Kennwort für die Bänder geändert wurde. Das muss man unbedingt mitbekommen.
Jeder Login am OS, jeder Login am Backupsystem, jede Änderung an den Netzwerkkomponenten usw muss ein Event auslösen das man auch ganz sicher mitbekommt.
dediziertes Netzwerk (Wenn möglich auf einer eigenen Hardware. Also eigene Switche und eigene Firewall was allesamt nicht im normalen Managementnetz hängt) in der die Backupumgebung steht. Server, Tapelib usw. Nichts und niemand darf eine Verbindung dahin öffnen. Gemanaged wird das ganze über einen eigenen PC der in dem Netz hängt und nur bei Bedarf gestartet wird. Nichts in dem Netz hat Internet.
Damit ist sichergestellt das von außen keiner an das Netz kommt.
Die gesamte Backupinfrastruktur, ist NICHT in der Domäne. Es gibt eigene Kennwörter für alles.
Die Backupsoftware holt sich dann die Backups auf Disk. Von da gehen die Daten auf Band. Die Bänder werden nach dem Sichern ausgeworfen und in einen Safe gepackt. Möglichst täglich.
der Trojaner an sich wird ja den VEEAM nicht auffordern, ein bestimmtes Band aus dem Slot ins Drive zu bewegen.
Ne, der Trojaner macht erst mal gar nichts. Der lässt die Späher in das Netz. Und die finden die Tapelib. Und wenn sie in die rein kommen, dann sagen die der, das sie alles in der Lib löschen soll.Ggf kommen die auch in das Backupsystem und sagen dem schon vor 2 Monaten das die Backups alle mit Kennwort versehen werden sollen. Und dann sind die letzten 2 Monate alle verschlüsselt, mit einem Kennwort das man nicht kennt. Dann hilft das Band einem auch nichts mehr.
Klingt unrealistisch? 2 Mittelständler hier in der Umgebung haben genau so alles verloren. Die Angreifer sind in den Core Router gekommen und hatten damit Zugriff auf das Management Netz. Cisco mit ca 1 Jahr alter Firmware. Darüber sind sie auf die Firewall und haben sich das Backupnetz geöffnet. Damit haben sie dann die Tapelib übernommen, alle Bänder darin gelöscht, die Maglib gecrypted und der Netapp alle Snapshots gelöscht.
Game over. Alles weg. Eine Firma hat zu gemacht, die andere hat mit 3 Monate alten Daten von Band recovered und ist seitdem im Überlebenskampf.
Verabschiedet euch von dem Gedanken das da irgendeine Datei ausgeführt wird und die dann stumpf alles Platt macht was sie in die Finger bekommt. Die öffnen nur das Tor. Dann guckt sich da einer um und schaut wie viel Geld die Firma so macht. Und dann kommt einer, der sich weiter durch das Netz frisst um am Ende die Bombe hochgehen zu lassen.
Führt mich zum Thema Monitoring:
Das Backupsystem hat hoffentlich Events für Dinge wie Änderungen am System, wie z.B dass das Kennwort für die Bänder geändert wurde. Das muss man unbedingt mitbekommen.
Jeder Login am OS, jeder Login am Backupsystem, jede Änderung an den Netzwerkkomponenten usw muss ein Event auslösen das man auch ganz sicher mitbekommt.
3
Moin Zusammen,
interessante Punkte die du ansprichst @SeaStorm.
Bisher bin ich bei meinen Kunden von solchen Aktionen verschont geblieben.
Wie wäre denn folgender Aufbau:
VM-Host (ESX/Hyper-V) - mind. zwei getrennte V-Switche (Produktiv und Backup) - Switch mit getrennten VLANs - Backup-Rechner + NAS fürs Backup - Anbindung via iscsi an den Backup-Rechner.
Zweiter Rechner ohne Internetzugang am NAS zieht das Backup vom NAS auf ein anderes NAS, welches nur an dem zweiten Rechner hängt.
Dann müsste man über das NAS auf diesen zweiten Rechner kommen und von dem auf das zweite NAS.
Grüße
interessante Punkte die du ansprichst @SeaStorm.
Bisher bin ich bei meinen Kunden von solchen Aktionen verschont geblieben.
Wie wäre denn folgender Aufbau:
VM-Host (ESX/Hyper-V) - mind. zwei getrennte V-Switche (Produktiv und Backup) - Switch mit getrennten VLANs - Backup-Rechner + NAS fürs Backup - Anbindung via iscsi an den Backup-Rechner.
Zweiter Rechner ohne Internetzugang am NAS zieht das Backup vom NAS auf ein anderes NAS, welches nur an dem zweiten Rechner hängt.
Dann müsste man über das NAS auf diesen zweiten Rechner kommen und von dem auf das zweite NAS.
Grüße
Danke für diesen echt wertvollen Beitrag.
Ich mache auch 3-2-1:
A) Mit einem Backupserver auf eigener Hardware und Linux als OS, Zugriff nur über SSH mit PubKey und natürlich Pull-Backups. Der Server ist grundsätzlich aus und schaltet sich nur während der Backups ein.
B) mit mobilen Platten im täglichen Wechsel.
Um A) noch trojanerfester zu machen, werde ich den auf Deinen Rat vom Netz trennen und das Monitoring ausbauen.
Zum klassischen Pull-Backup muss man natürlich sagen, dass das die Risiken massiv zentriert, weil der Server auf alle zu sichernden Geräte zugreifen können muss, und das meist mit hohen Rechten. Unter Sicherheitsaspekten hübscher wäre wahrscheinlich eine Push-Pull-Kaskade, bei der die Clients die täglichen Backups auf Server A pushen und der Server B sich diese Backups dann zur gesicherten und langfristigen Lagerung holt.
Ich mache auch 3-2-1:
A) Mit einem Backupserver auf eigener Hardware und Linux als OS, Zugriff nur über SSH mit PubKey und natürlich Pull-Backups. Der Server ist grundsätzlich aus und schaltet sich nur während der Backups ein.
B) mit mobilen Platten im täglichen Wechsel.
Um A) noch trojanerfester zu machen, werde ich den auf Deinen Rat vom Netz trennen und das Monitoring ausbauen.
Zum klassischen Pull-Backup muss man natürlich sagen, dass das die Risiken massiv zentriert, weil der Server auf alle zu sichernden Geräte zugreifen können muss, und das meist mit hohen Rechten. Unter Sicherheitsaspekten hübscher wäre wahrscheinlich eine Push-Pull-Kaskade, bei der die Clients die täglichen Backups auf Server A pushen und der Server B sich diese Backups dann zur gesicherten und langfristigen Lagerung holt.
Moin,
zur Backupstrategie gehören auch Aufbewahrungsrichtlinien. Sprich wie sind die SLAs (Service Level Agreements) bezüglich der Aufbewahrungsdauer definiert? Das wird sehr häufig vergessen bzw. nicht beachtet.
Ich betreue mehrere große Datensicherungen von verschiedenen Unternehmen. Fast überall habe ich folgende Aufbewahrungsrichtlinien vorgeschlagen / eingeführt:
Retention Policy:
90 Tage (Standard Policy)
6 Monate
1 Jahr
3 Jahre
5 Jahre
10 Jahre
30 Jahre
Erläuterung: Wenn ein Objekt (Datei, Verzeichnis) gesichert wurde. Und dies gelöscht wird, ist es möglich das Objekt innerhalb der Retention Policy wiederherzustellen. Wobei die Standard Policy 90 Tage beträgt.
Alle anderen Policies sind per SLA definiert und können auf Anforderung angewendet werden. Alle Policies welche NICHT Standard sind (6 Monate, 1 Jahr, 3 Jahre, 5 Jahre, 10 Jahre, 30 Jahre) sind auf LTO Bänder ausgelagert. Diese Bänder werden regelmäßig geprüft, ob die Daten wiederherstellbar sind.
Bezüglich der Sicherungsstrategie (3-2-1) Prinzip wurde schon geschrieben und man findet im Internet genügend Informationen.
Gruss Penny.
zur Backupstrategie gehören auch Aufbewahrungsrichtlinien. Sprich wie sind die SLAs (Service Level Agreements) bezüglich der Aufbewahrungsdauer definiert? Das wird sehr häufig vergessen bzw. nicht beachtet.
Ich betreue mehrere große Datensicherungen von verschiedenen Unternehmen. Fast überall habe ich folgende Aufbewahrungsrichtlinien vorgeschlagen / eingeführt:
Retention Policy:
90 Tage (Standard Policy)
6 Monate
1 Jahr
3 Jahre
5 Jahre
10 Jahre
30 Jahre
Erläuterung: Wenn ein Objekt (Datei, Verzeichnis) gesichert wurde. Und dies gelöscht wird, ist es möglich das Objekt innerhalb der Retention Policy wiederherzustellen. Wobei die Standard Policy 90 Tage beträgt.
Alle anderen Policies sind per SLA definiert und können auf Anforderung angewendet werden. Alle Policies welche NICHT Standard sind (6 Monate, 1 Jahr, 3 Jahre, 5 Jahre, 10 Jahre, 30 Jahre) sind auf LTO Bänder ausgelagert. Diese Bänder werden regelmäßig geprüft, ob die Daten wiederherstellbar sind.
Bezüglich der Sicherungsstrategie (3-2-1) Prinzip wurde schon geschrieben und man findet im Internet genügend Informationen.
Gruss Penny.
Moin Zusammen,
also nicht schimpfen über den IST-Zustand. Deswegen frage ich ja um das zu verbessern, aber im Moment fehlt mir noch der richtige Ansatz. Vielleicht kann mir da jemand noch einen Tipp geben?
Was klar ist, dass Veeam auf einen eigenen Rechner muss. Das habe ich mal mangels Alternativen mit auf die Kamerabüchse gepackt.
Die Frage ist: Zweiten VSwitch auf dem Hyper-V Host (1) in ein separates VLAN in dem das NAS hängt und der Backuprechner oder lieber das NAS direkt an den Backuprechner hängen ohne Switch dazwischen? Und bestenfalls das Backup noch in die Cloud schieben?
Danke euch!
also nicht schimpfen über den IST-Zustand. Deswegen frage ich ja um das zu verbessern, aber im Moment fehlt mir noch der richtige Ansatz. Vielleicht kann mir da jemand noch einen Tipp geben?
Was klar ist, dass Veeam auf einen eigenen Rechner muss. Das habe ich mal mangels Alternativen mit auf die Kamerabüchse gepackt.
Die Frage ist: Zweiten VSwitch auf dem Hyper-V Host (1) in ein separates VLAN in dem das NAS hängt und der Backuprechner oder lieber das NAS direkt an den Backuprechner hängen ohne Switch dazwischen? Und bestenfalls das Backup noch in die Cloud schieben?
Danke euch!
Das wechseln des Tapes ist aber einfacher und nicht so fehleranfällig.
Das kopieren der Daten kann man dann mit einer guten Backupsoftware automatisch starten.
Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Das kopieren der Daten kann man dann mit einer guten Backupsoftware automatisch starten.
Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Zitat von @Xaero1982:
Nun hab ich gesagt, dass man die Sachen zumindest jeden Tag auf wechselnde externe Festplatten kopiert - sprich Handarbeit ist angesagt.
Nun hab ich gesagt, dass man die Sachen zumindest jeden Tag auf wechselnde externe Festplatten kopiert - sprich Handarbeit ist angesagt.
Als Speichermedium nutzen wir das Wechselplattensystem RDX von Tandberg.
Okay, unglücklich ausgedrückt. Der komplette Datenbestand wird täglich auf wechselnden Platten gesichert. Aber für den Tag haben wir eben Snapshots, dass wir jederzeit auf die zurückgreifen können.
Was ich eigentlich mit meinem Post sagen wollte ist, dass Snapshots ein guter Weg ist den Verlust klein zu halten. Natürlich hat man mehr als nur das. Dachte, dass das selbstverständlich ist und keiner weiteren Worte bedarf.
Wie lange braucht ihr für einen Restore einer ganzen VM?
Hängt von der Größe der VM ab. Im günstigen Fall weniger als 1 Minute.Was ich eigentlich mit meinem Post sagen wollte ist, dass Snapshots ein guter Weg ist den Verlust klein zu halten. Natürlich hat man mehr als nur das. Dachte, dass das selbstverständlich ist und keiner weiteren Worte bedarf.
Zitat von @wiesi200:
Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Und bei einem Technologiewechsel (z.B. LTO6 auf LTO8) sollten auch die älteren Daten auf den LTO6-Tapes einmal auf LTO8 kopiert werden.Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Sonst steht man in 10 Jahren da, hat ein LTO4-Tape in der Hand aber nichts mehr, um es einzulesen
@it-fraggle
Sollte auch kein Vorwurf sein. Habe deine Worte nur als Aufhänger genutzt um den Hinweis zu geben, nicht auf reine Snapshots zu gehen, sondern auch immer mal wieder Fullbackups anzufertigen - VEEAM kann ja syntehtische FullBackups erzeugen - dann wird brav per Snapshot gesichert und in größenen Intervallen dann aus mehreren Snapshots wieder ein FullBackup "gezaubert".
Zitat von @em-pie:
Sonst steht man in 10 Jahren da, hat ein LTO4-Tape in der Hand aber nichts mehr, um es einzulesen
Sonst steht man in 10 Jahren da, hat ein LTO4-Tape in der Hand aber nichts mehr, um es einzulesen
- oder eine RLL-Platte ohne Controller und PC außenrum nach 20 Jahren.
- oder Bernoulli-Disks
- oder Syquest Wechselplatten.
- oder QIC-Bänder
- oder Halbzoll-Bänder
- etc.
Das leidige an den meisten Backup- und Archiv-Medien ist, daß man immer rechtzeitig daran denken muß, die Daten umzukopieren, bevor die "alte" Technik ausstirbt.
Bisher haben sich nur und Stein und Papier als relativ dauerhaft erwiesen.
lks
Zitat von @em-pie:
Sonst steht man in 10 Jahren da, hat ein LTO4-Tape in der Hand aber nichts mehr, um es einzulesen
Hm, gute Backupadministratoren haben so etwas regelmäßig auf dem Schirm. Sprich Datenmigration auf aktuelle Technologie.Zitat von @wiesi200:
Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Und bei einem Technologiewechsel (z.B. LTO6 auf LTO8) sollten auch die älteren Daten auf den LTO6-Tapes einmal auf LTO8 kopiert werden.Bei richtiger auslegen der Hardware deutlich schneller. Und die Medien sind auf Dauer auch günstiger, den Festplatten und Tapes gehören regelmäßig erneuert.
Sonst steht man in 10 Jahren da, hat ein LTO4-Tape in der Hand aber nichts mehr, um es einzulesen
Und das man so etwas nicht mal auf einen Rutsch macht bzw. machen kann. Sollte auch klar sein.
Bisher handhabe ich dies so, daß ein spezieller Storage dafür bereitsteht, wo die alten Bänder zurück geladen werden. Und dann auf neue Bänder gesichert werden. Somit kann auch gleich geprüft werden, ob die Bänder Lesefehler haben.
Was auch geht, ist die Gruppierung der gesicherten Daten (Collocation). Zum Beispiel Daten der Personalverwaltung, bestimmte Verzeichnisse des Fileservers, usw.
Gruss Penny.
Zitat von @Lochkartenstanzer:
Das leidige an den meisten Backup- und Archiv-Medien ist, daß man immer rechtzeitig daran denken muß, die Daten umzukopieren, bevor die "alte" Technik ausstirbt.
Bisher haben sich nur und Stein und Papier als relativ dauerhaft erwiesen.
Stimmt nicht ganz. Du vergisst Micro Fiches. Kennt das überhaupt noch jemand?Das leidige an den meisten Backup- und Archiv-Medien ist, daß man immer rechtzeitig daran denken muß, die Daten umzukopieren, bevor die "alte" Technik ausstirbt.
Bisher haben sich nur und Stein und Papier als relativ dauerhaft erwiesen.
lks
Stimmt nicht ganz. Du vergisst Micro Fiches. Kennt das überhaupt noch jemand?
Klar, haben wir früher Zeichnungen drauf "digitalisiert"...
Zitat von @Penny.Cilin:
Zitat von @Lochkartenstanzer:
Bisher haben sich nur und Stein und Papier als relativ dauerhaft erwiesen.
Stimmt nicht ganz. Du vergisst Micro Fiches. Kennt das überhaupt noch jemand?Bisher haben sich nur und Stein und Papier als relativ dauerhaft erwiesen.
Ja, /me.
Die hatte ich vergessen zu erwähnen. Allerdings wird die Zeit zeigen, ob das genauso haltbar ist wie Stein und altes Papier.
PS: "Neues" Papier ist übrigens nicht so haltbar wie man denk. Das zersetzt sich nach einige Jahren!
@Looser27 und @Lochkartenstanzer
Ich mag mich täuschen, aber soweit ich weiß sind Micro Fiches als Langzeitarchiv Medium zertifiert.
Ich habe in den 80er im Rechenzentrum Micro Fiches erstellt. Die wurden dann den Kunden (Banken) ausgeliefert.
Ach ja, Lochkarten sind aus verstärktem Papier (Karton). Auch sowas habe ich schon als Micro Fiches gesehen.
Braucht man nur noch Lochkartenleser und die Software dazu.
Ich mag mich täuschen, aber soweit ich weiß sind Micro Fiches als Langzeitarchiv Medium zertifiert.
Ich habe in den 80er im Rechenzentrum Micro Fiches erstellt. Die wurden dann den Kunden (Banken) ausgeliefert.
Ach ja, Lochkarten sind aus verstärktem Papier (Karton). Auch sowas habe ich schon als Micro Fiches gesehen.
Braucht man nur noch Lochkartenleser und die Software dazu.
Ich mach das immer folgendermaßen:
Clients haben haben natürlich je einen eigenen Zugang nur auf die benötigte Software am Server.
Server macht via Veeam eine Sicherung auf ein NAS auch mit eigenem Zugang.
Das NAS macht intern mit eigenem Nutzer eine Sicherung auf eine externe Platte.
Die wird nach Bedarf getauscht.
Wenn gewollt gibt es an einem zweitem Standort via VPN ein weiteres NAS inkl externe HDD.
Alle X Jahre ist das Zeug eh abgeschrieben und wird vor dem Austausch eh noch mal komplett gesichert
Clients haben haben natürlich je einen eigenen Zugang nur auf die benötigte Software am Server.
Server macht via Veeam eine Sicherung auf ein NAS auch mit eigenem Zugang.
Das NAS macht intern mit eigenem Nutzer eine Sicherung auf eine externe Platte.
Die wird nach Bedarf getauscht.
Wenn gewollt gibt es an einem zweitem Standort via VPN ein weiteres NAS inkl externe HDD.
Alle X Jahre ist das Zeug eh abgeschrieben und wird vor dem Austausch eh noch mal komplett gesichert
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Hab kürzlich noch eine 8" Diskette gefunden
Hab kürzlich noch eine 8" Diskette gefunden
Moin,
B2T
mal die Grafik von hier betrachtet:
Backupstrategie
Edit: mal so am Rande in die Runde:
Hat sich von euch mal jemand mit Fast LTA beschäftigt?
Vermutlich für die Kunden-Umgebung des Kollegen @Xaero1982 zu teuer, aber mal so generell betrachtet...
Zitat von @Xaero1982:
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Jetzt stellst du dich aber an Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
B2T
mal die Grafik von hier betrachtet:
Backupstrategie
- Trenne die Verbindung zwischen NAS und Edge Switch
- Baue zwischen Edge-Switch und Backup/ Kamera-Server (du erwähntest ja selbst, dass das ungünstig ist), eine "Trennwand" ein, entweder via VLAN und ACLs oder eine kleine Firewall. Erleubt ist nur ausgehender Traffic zu den Hyper-Vs und zum Mailserver (für Status-Reports)
- Gib dem Backup-Server eine zusätzlich physische NIC, sodass das NAS nur mit dem Backup-Server verbunden ist.
- Falls du hast/ kannst: Lagere entweder den Backup-Server oder den Kamera-Server auf einen (ausrangierten) Server/ PC aus.
Edit: mal so am Rande in die Runde:
Hat sich von euch mal jemand mit Fast LTA beschäftigt?
Vermutlich für die Kunden-Umgebung des Kollegen @Xaero1982 zu teuer, aber mal so generell betrachtet...
Zitat von @Xaero1982:
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Wieso?
Dann siehst Du, daß das Problem mit den Backup- und Archivmedien schon jahrhundertealt ist und man das auch bei aktuellen Backups nicht vernachlässigen sollte.
Insbesodnere bei Bändern passiert der Technologiewechsel viel schneller als erwartet.
Hab kürzlich noch eine 8" Diskette gefunden
Hast Du auch noch ein Laufwerk dazu?
Oder gar noch einen Computer mit Shugart-Bus, an den man das Laufwerk anschließen und damit dann die Diskette lesen könnte (falls die Beschichtung überhaupt noch auf dem Kunstoff drauf ist.)
lks
Zitat von @em-pie:
Moin,
Ja, ich stell mich ja schon ganz hinten an ;)Moin,
Zitat von @Xaero1982:
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Jetzt stellst du dich aber an Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
B2T
mal die Grafik von hier betrachtet:
Backupstrategie
- Trenne die Verbindung zwischen NAS und Edge Switch
- Baue zwischen Edge-Switch und Backup/ Kamera-Server (du erwähntest ja selbst, dass das ungünstig ist), eine "Trennwand" ein, entweder via VLAN und ACLs oder eine kleine Firewall. Erleubt ist nur ausgehender Traffic zu den Hyper-Vs und zum Mailserver (für Status-Reports)
- Gib dem Backup-Server eine zusätzlich physische NIC, sodass das NAS nur mit dem Backup-Server verbunden ist.
- Falls du hast/ kannst: Lagere entweder den Backup-Server oder den Kamera-Server auf einen (ausrangierten) Server/ PC aus.
Zitat von @Lochkartenstanzer:
Wieso?
Dann siehst Du, daß das Problem mit den Backup- und Archivmedien schon jahrhundertealt ist und man das auch bei aktuellen Backups nicht vernachlässigen sollte.
Insbesodnere bei Bändern passiert der Technologiewechsel viel schneller als erwartet.
Keine Frage, aber ich denke das wird bei dem Kunden eh nichts mit Bändern.Zitat von @Xaero1982:
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Jungs, ich find das total super wie ihr diskutiert, aber hilft mir gerade nur rudimentär weiter
Wieso?
Dann siehst Du, daß das Problem mit den Backup- und Archivmedien schon jahrhundertealt ist und man das auch bei aktuellen Backups nicht vernachlässigen sollte.
Insbesodnere bei Bändern passiert der Technologiewechsel viel schneller als erwartet.
Hab kürzlich noch eine 8" Diskette gefunden
Hast Du auch noch ein Laufwerk dazu?
Oder gar noch einen Computer mit Shugart-Bus, an den man das Laufwerk anschließen und damit dann die Diskette lesen könnte (falls die Beschichtung überhaupt noch auf dem Kunstoff drauf ist.)
Natürlich nicht. Die wird da schon viele viele Jahre im Schrank liegen. Ist nur noch Anschauungsmaterial
Frag sie wie viel Geld sie am Tag verlieren, wenn der Laden steht.
Und dann rechnest du Mal einen vollständigen Recovery aus. Also Backupvolumen durch Geschwindigkeit der Festplatte über was auch immer sie da angesteuert wird
Und dann Geschwindigkeit von einem LTO Laufwerk daneben stellen
Und dann rechnest du Mal einen vollständigen Recovery aus. Also Backupvolumen durch Geschwindigkeit der Festplatte über was auch immer sie da angesteuert wird
Und dann Geschwindigkeit von einem LTO Laufwerk daneben stellen
1
Moin Xaero1982,
wir gehen bei allen unseren Kunden immer nach demselben Muster vor.
Die Hypervisormanagementumgebung befindet sich immer in einem eigenen, vom Produktivnetz abgeschotteten Netzsegment (VLAN) und ist authentifizierungstechnisch ebenfalls komplett getrennt von der Produktivumgebung aufgebaut.
Der Primärbackupspeicher (NAS/SAN) befinden sich ebenfalls in einem eigenen Netzsegment, auf welches nur der Backupserver (Veeam) zugreifen kann.
Von Montag bis Samstag wird auf ein NAS/SAN gesichert, welches in einem anderen Brandabschnitt als die Hauptserverumgebung steht. Von diesem Backup können wir je nach Server bis zu 180 Tage und manchmal auch mehr, zurückspringen.
Zusätzlich wird bei vielen unserer Kunden am Sonntag ein Vollbackup der kritischsten Systeme auf ein oder mehrere RDX Medien geschrieben und am Montag zur Bank in Schliessfach gebracht.
Immer schön auf Benutzer und Netztrennung achten, dann haben die Mistviecher auch keine Chance bis zu den Backups zu kommen. 😉
Beste Grüsse aus BaWü
Alex
wir gehen bei allen unseren Kunden immer nach demselben Muster vor.
Die Hypervisormanagementumgebung befindet sich immer in einem eigenen, vom Produktivnetz abgeschotteten Netzsegment (VLAN) und ist authentifizierungstechnisch ebenfalls komplett getrennt von der Produktivumgebung aufgebaut.
Der Primärbackupspeicher (NAS/SAN) befinden sich ebenfalls in einem eigenen Netzsegment, auf welches nur der Backupserver (Veeam) zugreifen kann.
Von Montag bis Samstag wird auf ein NAS/SAN gesichert, welches in einem anderen Brandabschnitt als die Hauptserverumgebung steht. Von diesem Backup können wir je nach Server bis zu 180 Tage und manchmal auch mehr, zurückspringen.
Zusätzlich wird bei vielen unserer Kunden am Sonntag ein Vollbackup der kritischsten Systeme auf ein oder mehrere RDX Medien geschrieben und am Montag zur Bank in Schliessfach gebracht.
Immer schön auf Benutzer und Netztrennung achten, dann haben die Mistviecher auch keine Chance bis zu den Backups zu kommen. 😉
Beste Grüsse aus BaWü
Alex
2
Hi,
ich habe hier in einem KMU Umfeld eine Synology Rackstation (RS818+) stehen, die ist nach außen dicht gemacht (keine Freigabe, kein SSH/Telnet, etc) und habe dort die ActiveBackupForBusiness App installiert. Die hat einen Windows Client, der sich nur gegenüber dem NAS authentifiziert und die Sicherung durchführt. (Für reine Dateifreigaben geht das auch ohne Client, dann zieht der Server sich die Daten über SMB) Alles andere kommt vom Server (Start der SIcherung, Zeitplan, Rotation, etc...). Dh. Löschen und Wiederherstellen kann auch nur der NAS Admin, der natürlich vom Domänen-Admin komplett abgekapselt ist (eigenes Passwort, eigener Username).
Für den NAS Login ist eine 2-Faktor-Authentifizierung eingestellt, die nur mit einem Gerät generiert werden kann, was nicht im Netzwerk hängt (altes Android Handy bzw. Tablet mit Google-Authenticator App).
Somit kann der böse Verschlüsselungstrojaner nicht auf die Datensicherung zugreifen, da die Synology sich die Sicherung zieht. Sollte er irgendwie dann sogar an die Admin-Daten des NAS kommen, bleibt er bei der 2FA hängen. Hilft alles natürlich nicht mehr, wenn ein Bug im NAS System ausgenutzt werden könnte, wie es vor kurzem bei QNAP der Fall war. Dann ist natürlich Sense.
Aber man könnte hier die Synology auch nochmals auf USB HDDs/SSDs/RDX's/etc sichern, die dann dementsprechend nach Rhytmus gewechselt werden. Dann wäre man auf der sichereren sicheren Seite
Gruß
PS: Soll jetzt keine Werbung für Synology sein, aber die Backup-Software ist wirklich einen Blick wert. Sie ist (noch?) völlig kostenlos (bei x64-Prozessor-Modellen) und mit Deduplizierung und allem PiPaPo... Ich persönlich bin hier relativ begeistert...
ich habe hier in einem KMU Umfeld eine Synology Rackstation (RS818+) stehen, die ist nach außen dicht gemacht (keine Freigabe, kein SSH/Telnet, etc) und habe dort die ActiveBackupForBusiness App installiert. Die hat einen Windows Client, der sich nur gegenüber dem NAS authentifiziert und die Sicherung durchführt. (Für reine Dateifreigaben geht das auch ohne Client, dann zieht der Server sich die Daten über SMB) Alles andere kommt vom Server (Start der SIcherung, Zeitplan, Rotation, etc...). Dh. Löschen und Wiederherstellen kann auch nur der NAS Admin, der natürlich vom Domänen-Admin komplett abgekapselt ist (eigenes Passwort, eigener Username).
Für den NAS Login ist eine 2-Faktor-Authentifizierung eingestellt, die nur mit einem Gerät generiert werden kann, was nicht im Netzwerk hängt (altes Android Handy bzw. Tablet mit Google-Authenticator App).
Somit kann der böse Verschlüsselungstrojaner nicht auf die Datensicherung zugreifen, da die Synology sich die Sicherung zieht. Sollte er irgendwie dann sogar an die Admin-Daten des NAS kommen, bleibt er bei der 2FA hängen. Hilft alles natürlich nicht mehr, wenn ein Bug im NAS System ausgenutzt werden könnte, wie es vor kurzem bei QNAP der Fall war. Dann ist natürlich Sense.
Aber man könnte hier die Synology auch nochmals auf USB HDDs/SSDs/RDX's/etc sichern, die dann dementsprechend nach Rhytmus gewechselt werden. Dann wäre man auf der sichereren sicheren Seite
Gruß
PS: Soll jetzt keine Werbung für Synology sein, aber die Backup-Software ist wirklich einen Blick wert. Sie ist (noch?) völlig kostenlos (bei x64-Prozessor-Modellen) und mit Deduplizierung und allem PiPaPo... Ich persönlich bin hier relativ begeistert...
1
