3
Veeam Immutable Backups
Hi zusammen,
ich bin aktuell auf der Suche nach einem S3 kompatiblem Object Storage um meine Veeam Backups wirklich immutable zu bekommen.
Wir haben ein QNAP 1277 und ich hab hier die Funktion QUOBJECTS gefunden.
Allerdings finde ich nicht heraus, ob ich damit meine Backups wirklich immutable bekomme oder ob es doch ein eigener Server mit einem hardened Linux sein sollte.
Habt ihr hier Erfahrungen?
Allgemein gefragt:
Wie macht ihr das?
Es gibt ja von allen Möglichen Herstellern (z.B. Claudian, IBM...) schon fertige Storages.
-> Macht es Sinn in diese Richtung zu gehen?
Meine CopyJobs mit GFS benötigen aktuell knapp 45TB.
Vielen Dank,
Leon
ich bin aktuell auf der Suche nach einem S3 kompatiblem Object Storage um meine Veeam Backups wirklich immutable zu bekommen.
Wir haben ein QNAP 1277 und ich hab hier die Funktion QUOBJECTS gefunden.
Allerdings finde ich nicht heraus, ob ich damit meine Backups wirklich immutable bekomme oder ob es doch ein eigener Server mit einem hardened Linux sein sollte.
Habt ihr hier Erfahrungen?
Allgemein gefragt:
Wie macht ihr das?
Es gibt ja von allen Möglichen Herstellern (z.B. Claudian, IBM...) schon fertige Storages.
-> Macht es Sinn in diese Richtung zu gehen?
Meine CopyJobs mit GFS benötigen aktuell knapp 45TB.
Vielen Dank,
Leon
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1167746818
Url: https://administrator.de/contentid/1167746818
Printed on: April 26, 2024 at 22:04 o'clock
3 Comments
Latest comment
Falls der QNAP in der Domain ist, kann auch das Backup ausgelesen werden, wenn sich der Angreifer Admin Rechte in der Domain verschafft hat. Wenn der QNAP eigenständig läuft, reicht eine einfache Freigabe mit einem eigenen (Qnap-lokalen) User für diese Backups.
Sehe ich nicht so... warum würde es dann die neuen Funktionen geben, wenn das reichen würde.
Die Zugangsdaten sind auf dem Veeam Server gespeichert. Ein Keylogger reicht aus und schon wars das mit dem Backup spätestens wenn jemand sich auf dem QNAP anmeldet..
Die Zugangsdaten sind auf dem Veeam Server gespeichert. Ein Keylogger reicht aus und schon wars das mit dem Backup spätestens wenn jemand sich auf dem QNAP anmeldet..
Veeam bietet doch seit der V11 immutable Backups an....dafür gibt es einige Voraussetzungen .
Wir haben dafür zusätzlich einen physischen Linux Server an dem ein SAN Storage per FC direkt dran hängt (du kannst genau ein QNAP mit direkter ISCSI Verbindungen verwenden). Das QNAP sollte dann bestenfalls autark laufen und natürlich auch nicht in der Domäne hängen.
Veeam benötigt für die Installation auf dem Linux Server einmalig SSH Zugang , danach nicht mehr!
Im Anschluss erfolgt die die Kommunikation (Backups kopieren, wiederherstellen etc) nicht mehr über SSH, sondern über den Veeam Server.
Die Backups werden dann mit einem Attribut versehen, welches das löschen erst nach X Tagen erlaubt. Nur der Root User kann das Attribut entfernen. Da der SSH Zugang deaktiviert ist, das Root Passwort bestenfalls nur irgendwo an der Kiste klebt und nicht irgendwo im Netz steht, ist dort erstmal eine relativ große Hürde zu überspringen.
Sollte im WorstCase alles down sein, kommt man immernoch über einen Bildschirm an diesen physischen Server und kann dann die Backups abrufen...Alternativ über IPMI, IRMC etc (das ist dann aber bereits wieder ein Angriffpunkt, weßhalb dies bei uns nicht aktiv ist).
Ps.: Für die Einrichtung werden die SSH Daten eben nicht auf dem Veeam Server gespeichert....Dafür gibt es extra eine Funktion.
Nennt sich Single-use credentials for hardened repository.
Pps.: zusätzlich sichern wir auf LTO8 Tapes
Wir haben dafür zusätzlich einen physischen Linux Server an dem ein SAN Storage per FC direkt dran hängt (du kannst genau ein QNAP mit direkter ISCSI Verbindungen verwenden). Das QNAP sollte dann bestenfalls autark laufen und natürlich auch nicht in der Domäne hängen.
Veeam benötigt für die Installation auf dem Linux Server einmalig SSH Zugang , danach nicht mehr!
Im Anschluss erfolgt die die Kommunikation (Backups kopieren, wiederherstellen etc) nicht mehr über SSH, sondern über den Veeam Server.
Die Backups werden dann mit einem Attribut versehen, welches das löschen erst nach X Tagen erlaubt. Nur der Root User kann das Attribut entfernen. Da der SSH Zugang deaktiviert ist, das Root Passwort bestenfalls nur irgendwo an der Kiste klebt und nicht irgendwo im Netz steht, ist dort erstmal eine relativ große Hürde zu überspringen.
Sollte im WorstCase alles down sein, kommt man immernoch über einen Bildschirm an diesen physischen Server und kann dann die Backups abrufen...Alternativ über IPMI, IRMC etc (das ist dann aber bereits wieder ein Angriffpunkt, weßhalb dies bei uns nicht aktiv ist).
Ps.: Für die Einrichtung werden die SSH Daten eben nicht auf dem Veeam Server gespeichert....Dafür gibt es extra eine Funktion.
Nennt sich Single-use credentials for hardened repository.
Pps.: zusätzlich sichern wir auf LTO8 Tapes
1