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
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: 1167746818
Url: https://administrator.de/contentid/1167746818
Ausgedruckt am: 25.11.2024 um 06:11 Uhr
3 Kommentare
Neuester Kommentar
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
