12
Schwarmwissen zu Backup-Konzept gewünscht
Hallo zusammen,
brauche euer Schwarmwissen bzw. eure Schwarmmeinung. :D
Bin dabei ein neues Backup-Konzept zu erarbeiten.
Folgende Situation:
Verwenden VMWare Virtualisierung, mehrere ESX-Hosts.
Backup-Software ist Veeam, läuft auf eigenem Host welcher ortsmäßig vom Rest abgetrennt ist.
Aktuell gibt es mehrere NAS auf welche daily incremental Backups ausgeführt werden.
Wöchentlich wird auf ein Tape-Drive ein Full-Backup gemacht.
Die Infrastruktur ist sehr alt und teilweise nichtmehr mit Updates ausgestattet.
Dadurch wurde einiges investiert, nun möchte ich den ganzen Backup-Prozess hinterfragen und umbauen.
Haben eine neue QNAP-NAS gekauft, redundante 10G Anbindung sowie Netzteil.
Habe einen Storage Space erstellt welcher mit RAID 6 läuft.
Meine Idee war, diese Storage via ISCSI im Netzwerk verfügbar zu machen und in unseren File-Server einzubinden.
Dann sollen darauf Netzwerkfreigaben, Archivdaten etc. gespeichert werden. Mit knapp 90 TB haben wir für unsere Größe mehr als genug.
Des weiteren würde ich gerne einen eigenen Bereich auf der NAS haben, auf welchem täglich ein incremental Backup läuft.
Haben bereits im Netz etwas über Immutal Backup gelesen, verwendet das jemand von euch?
Eine weitere, ältere NAS soll rein als Backup-Device dienen. Kommt dann natürlich in ein eigenes VLAN. Diese befindet sich an einem anderen Standort als NAS1. Auch hier soll täglich ein incremental Backup durchgeführt werden.
Dann gibt es noch das offline-Backup. Haben hier ein neues Tape-Backup angeschafft.
Steht am selben Standort wie NAS2. Hier wird einmal wöchentlich ein Full-Backup durchgeführt.
Bitte lasst mich wissen, was ihr davon haltet. Besonders interessieren würde, wie ihr die Idee mit Produktivdaten und Backup am selben Device haltet, also bei mir aufgeführt mit NAS1.
Sollte dies nicht sauber auf der NAS abgetrennt werden, besteht die möglich noch eine NAS an den selben Standort wie NAS1 zu geben, diese wär dann auch nur rein fürs Backup da und auch im Backup-VLAN.
Wie schon gesagt, ich erfreue mich über jede konstruktive Meinung.
brauche euer Schwarmwissen bzw. eure Schwarmmeinung. :D
Bin dabei ein neues Backup-Konzept zu erarbeiten.
Folgende Situation:
Verwenden VMWare Virtualisierung, mehrere ESX-Hosts.
Backup-Software ist Veeam, läuft auf eigenem Host welcher ortsmäßig vom Rest abgetrennt ist.
Aktuell gibt es mehrere NAS auf welche daily incremental Backups ausgeführt werden.
Wöchentlich wird auf ein Tape-Drive ein Full-Backup gemacht.
Die Infrastruktur ist sehr alt und teilweise nichtmehr mit Updates ausgestattet.
Dadurch wurde einiges investiert, nun möchte ich den ganzen Backup-Prozess hinterfragen und umbauen.
Haben eine neue QNAP-NAS gekauft, redundante 10G Anbindung sowie Netzteil.
Habe einen Storage Space erstellt welcher mit RAID 6 läuft.
Meine Idee war, diese Storage via ISCSI im Netzwerk verfügbar zu machen und in unseren File-Server einzubinden.
Dann sollen darauf Netzwerkfreigaben, Archivdaten etc. gespeichert werden. Mit knapp 90 TB haben wir für unsere Größe mehr als genug.
Des weiteren würde ich gerne einen eigenen Bereich auf der NAS haben, auf welchem täglich ein incremental Backup läuft.
Haben bereits im Netz etwas über Immutal Backup gelesen, verwendet das jemand von euch?
Eine weitere, ältere NAS soll rein als Backup-Device dienen. Kommt dann natürlich in ein eigenes VLAN. Diese befindet sich an einem anderen Standort als NAS1. Auch hier soll täglich ein incremental Backup durchgeführt werden.
Dann gibt es noch das offline-Backup. Haben hier ein neues Tape-Backup angeschafft.
Steht am selben Standort wie NAS2. Hier wird einmal wöchentlich ein Full-Backup durchgeführt.
Bitte lasst mich wissen, was ihr davon haltet. Besonders interessieren würde, wie ihr die Idee mit Produktivdaten und Backup am selben Device haltet, also bei mir aufgeführt mit NAS1.
Sollte dies nicht sauber auf der NAS abgetrennt werden, besteht die möglich noch eine NAS an den selben Standort wie NAS1 zu geben, diese wär dann auch nur rein fürs Backup da und auch im Backup-VLAN.
Wie schon gesagt, ich erfreue mich über jede konstruktive Meinung.
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: 670906
Url: https://administrator.de/forum/schwarmwissen-zu-backup-konzept-gewuenscht-670906.html
Ausgedruckt am: 23.02.2025 um 04:02 Uhr
12 Kommentare
Neuester Kommentar
Moin,
ich greife mal deine Ideen auf, ohne auf den Ist-Zustand einzugehen
Eine Frage noch: ist der ESXi in der 4free-Lizenz oder habt ihr da eine Subscription für (frage bzgl. der Backup-Möglichkeiten)?
Des weiteren würde ich gerne einen eigenen Bereich auf der NAS haben, auf welchem täglich ein incremental Backup läuft.
Nein. Bleibe bitte dabei und trenne Produktiv-Daten auch von den Backup-Daten. Kommt ein böser Bursche an dein QNAP dran, löscht er erstmal alle LUNs. Dann kannst du maximal auf das Backup von vor 7 Tagen zurück greifen, welches noch auf dem Tape liegt. Das (Wochen)-Tape sollte die letzte Insanz sein, auf die man zurückgreifen muss. Da es aber offline ist, kann es zwar selbst bereits verschlüsselte Daten enthalten, ggf. aber auch den Verursacher der Verschlüsselung (die Schadsoftware) - aber das testet man ja dann, bevor man alle Systeme daraus recovert bzw. hat man vor dem Restore herausgefunden, wann doe SOftware eingeschleust wurde
Alternativ: haut doch einfach viele Platten in den Veeam-Server als Primary-Target und von dort dann eine Replikation auf Immutable-Backup-Repository.
Wichtig: sorge immer dafür, dass "irgendwann" Produktivdaten und Backup-Daten räumlich getrennt werden.
Wir haben z. B. das Storage fürs Backup an einem dritten Standort, während die Library für die Tapes sich wiederum an einem der Standorte der Storages steht
ich greife mal deine Ideen auf, ohne auf den Ist-Zustand einzugehen
Haben eine neue QNAP-NAS gekauft, redundante 10G Anbindung sowie Netzteil.
Schon mal gutHabe einen Storage Space erstellt welcher mit RAID 6 läuft.
Nearline oder SSD/ Flash-Disks?Meine Idee war, diese Storage via ISCSI im Netzwerk verfügbar zu machen und in unseren File-Server einzubinden.
Kann man so machen. ICH hätte das QNAP vermutlich direkt am ESXi-Host platziert (iSCSI) und dort alle VMs drauf abgelegt.Eine Frage noch: ist der ESXi in der 4free-Lizenz oder habt ihr da eine Subscription für (frage bzgl. der Backup-Möglichkeiten)?
Dann sollen darauf Netzwerkfreigaben, Archivdaten etc. gespeichert werden. Mit knapp 90 TB haben wir für unsere Größe mehr als genug.
OK. und die Größe ist auch auf die nächsten X-Jahre hochgerechnet bzw. habt ihr noch Luft für weitere Platten?Des weiteren würde ich gerne einen eigenen Bereich auf der NAS haben, auf welchem täglich ein incremental Backup läuft.
Haben bereits im Netz etwas über Immutal Backup gelesen, verwendet das jemand von euch?
Ja, auf einer Debian-Maschine. Die MAschine ist nur am VEEAM-Server direkt angeschlossen und hat KEIN Netzwerkport im LAN. administriert wird die Maschine von der KVM-Konsole im Serverack aus.Eine weitere, ältere NAS soll rein als Backup-Device dienen. Kommt dann natürlich in ein eigenes VLAN. Diese befindet sich an einem anderen Standort als NAS1.
Das ist ein guter Ansatz. Aber was meinst du mit folgendem Satz?Auch hier soll täglich ein incremental Backup durchgeführt werden.
Dann gibt es noch das offline-Backup. Haben hier ein neues Tape-Backup angeschafft.
Steht am selben Standort wie NAS2. Hier wird einmal wöchentlich ein Full-Backup durchgeführt.
Und dann außer Haus ausgelagert? Dann wäre es optimalSteht am selben Standort wie NAS2. Hier wird einmal wöchentlich ein Full-Backup durchgeführt.
Bitte lasst mich wissen, was ihr davon haltet. Besonders interessieren würde, wie ihr die Idee mit Produktivdaten und Backup am selben Device haltet, also bei mir aufgeführt mit NAS1.
Wie oben erwähnt, bitte trennen.Sollte dies nicht sauber auf der NAS abgetrennt werden, besteht die möglich noch eine NAS an den selben Standort wie NAS1 zu geben, diese wär dann auch nur rein fürs Backup da und auch im Backup-VLAN.
Das wäre besser. Und nur VEEAM darf auf das Storage zugreifen.Alternativ: haut doch einfach viele Platten in den Veeam-Server als Primary-Target und von dort dann eine Replikation auf Immutable-Backup-Repository.
Wichtig: sorge immer dafür, dass "irgendwann" Produktivdaten und Backup-Daten räumlich getrennt werden.
Wir haben z. B. das Storage fürs Backup an einem dritten Standort, während die Library für die Tapes sich wiederum an einem der Standorte der Storages steht
1
ICH hätte das QNAP vermutlich direkt am ESXi-Host platziert (iSCSI) und dort alle VMs drauf abgelegt.
Nur mal zwischengefragt: Gibt es hier einen Vorteil von iSCSI gegenüber NFS?
Vielen Dank für die genommene Zeit und die ausführliche Antwort!
SSD wäre schön gewesen, leider nicht im Budget drinnen
Vielen Dank nochmal für die sehr ausführliche Antwort!
Es wird darauf hinauslaufen, dass die neue NAS wirklich nur rein für Produktivdaten und als Archiv genutzt wird.
Dann zwei alte NAS (nicht an selben Standorten) in einem Backup-VLAN, auf welche täglich jeweils ein incremental Backup durchgeführt wird.
Dann noch einmal wöchentlich das Backup auf das Tape.
Nearline oder SSD/ Flash-Disks?
Nearline, 8x16TB HDDSSD wäre schön gewesen, leider nicht im Budget drinnen
Eine Frage noch: ist der ESXi in der 4free-Lizenz oder habt ihr da eine Subscription für (frage bzgl. der Backup-Möglichkeiten)?
Alle ESX-Hosts sind in einer Subscription.OK. und die Größe ist auch auf die nächsten X-Jahre hochgerechnet bzw. habt ihr noch Luft für weitere Platten?
Alle Slots sind belegt, Speichergröße wurde so gewählt, dass vorher die NAS bzw. die Platten selber den Geist aufgeben. Also geht sich easy die nächsten Jahre aus.Nein. Bleibe bitte dabei und trenne Produktiv-Daten auch von den Backup-Daten. Kommt ein böser Bursche an dein QNAP dran, löscht er erstmal alle LUNs. Dann kannst du maximal auf das Backup von vor 7 Tagen zurück greifen, welches noch auf dem Tape liegt. Das (Wochen)-Tape sollte die letzte Insanz sein, auf die man zurückgreifen muss. Da es aber offline ist, kann es zwar selbst bereits verschlüsselte Daten enthalten, ggf. aber auch den Verursacher der Verschlüsselung (die Schadsoftware) - aber das testet man ja dann, bevor man alle Systeme daraus recovert bzw. hat man vor dem Restore herausgefunden, wann doe SOftware eingeschleust wurde
Danke, genau das hat mich zum Verfassen dieses Beitrags veranlasst Und dann außer Haus ausgelagert? Dann wäre es optimal
Genau, dieses wird dann dem Chef in die Hand gedrückt und dieser verschließt es (hoffentlich) bei ihm daheim im Safe😂Vielen Dank nochmal für die sehr ausführliche Antwort!
Es wird darauf hinauslaufen, dass die neue NAS wirklich nur rein für Produktivdaten und als Archiv genutzt wird.
Dann zwei alte NAS (nicht an selben Standorten) in einem Backup-VLAN, auf welche täglich jeweils ein incremental Backup durchgeführt wird.
Dann noch einmal wöchentlich das Backup auf das Tape.
Zitat von @aqui:
Berechtigter Einwand. Hatte NFS nicht auf dem Schirm, bisweilen aber auch noch nicht mit gearbeitet.ICH hätte das QNAP vermutlich direkt am ESXi-Host platziert (iSCSI) und dort alle VMs drauf abgelegt.
Nur mal zwischengefragt: Gibt es hier einen Vorteil von iSCSI gegenüber NFS?Kann zu den Fürs und Widers demnach nichts sagen.
Also, mir ist irgendwie unklar wie viele Daten zwischen den Standorten auf welche art flossen sollen, und wo denn nun der zu sichernde server ist und ob das Bandlaufwerk ebenso dort ist.
Kreuzberger
Kreuzberger
Moin,
sind das alles Standalone ESX oder laufen die in nem Cluster?
Gibt es ein zentrales SAN?
Ich würde auch das NAS als iSCSI Storage den ESX unterjubeln und die Filer VMs darauf laufen lassen.
Bei Veeam dann die Feature Backup from SAN oder from Storage Snapshot nutzen. Damit nimmst du erstmal die ganze Last vom ESX und der Veeam Server zieht sich alles per iSCSI. M.W. geht das nicht bei NFS !?
Persönlich bin ich ein ganz großer Freund von Dedup Backup Repositories. Gerade wenn es um Filer geht, wo oft nur etwas dazu kommt und selten gelöscht wird, kannst du da deine Retention Policy weit nach oben schrauben.
Immutable Option inklusive...
Gruß und Viel Erfolg
sind das alles Standalone ESX oder laufen die in nem Cluster?
Gibt es ein zentrales SAN?
Ich würde auch das NAS als iSCSI Storage den ESX unterjubeln und die Filer VMs darauf laufen lassen.
Bei Veeam dann die Feature Backup from SAN oder from Storage Snapshot nutzen. Damit nimmst du erstmal die ganze Last vom ESX und der Veeam Server zieht sich alles per iSCSI. M.W. geht das nicht bei NFS !?
Persönlich bin ich ein ganz großer Freund von Dedup Backup Repositories. Gerade wenn es um Filer geht, wo oft nur etwas dazu kommt und selten gelöscht wird, kannst du da deine Retention Policy weit nach oben schrauben.
Immutable Option inklusive...
Gruß und Viel Erfolg
1
Hi, danke für deinen Input.
sind das alles Standalone ESX oder laufen die in nem Cluster?
3 ESX sind zusammen in einem Cluster, zusätzlich dazu läuft auf einem eigenen das vCenter und dann haben wir noch einen Standalone ESX auf welchem der zweite DC sowie der Backupserver läuftGibt es ein zentrales SAN?
ja, wär auch eine Idee eine der NAS direkt im vCenter via ISCSI anzubindenM.W. geht das nicht bei NFS !?
Zu mindestens NFS an sich kann VEEAM.
@aqui
Das ist aber das Backup-Target.
@ElmerAcmeee beschreibt mit seiner Aussage aber, dass wenn die ESXis an ein Shared Storage (SAN mit iSCSI oder FC) angebunden sind, VEEAM sich die Daten dann direkt von der LUN holt, statt über das ESXi-Netzwerk zu gehen.
Unser VEEAM hat auch die LUNs eingebunden (wichtig: unter Windows müssen die offline bleiben), die die ESXi-Hosts für Ihre VMs nutzen. VEEAM stößt dann einen Snapshot der VM an, holt sich die Daten aber direkt von der LUN via iSCSI/ FC.
Ob das über NFS geht, weiß ich nicht/ glaube ich nicht.
Edit:
NFS = File Level Protokoll wie SMB
iSCSI = Block Level Protokoll
Das ist aber das Backup-Target.
@ElmerAcmeee beschreibt mit seiner Aussage aber, dass wenn die ESXis an ein Shared Storage (SAN mit iSCSI oder FC) angebunden sind, VEEAM sich die Daten dann direkt von der LUN holt, statt über das ESXi-Netzwerk zu gehen.
Unser VEEAM hat auch die LUNs eingebunden (wichtig: unter Windows müssen die offline bleiben), die die ESXi-Hosts für Ihre VMs nutzen. VEEAM stößt dann einen Snapshot der VM an, holt sich die Daten aber direkt von der LUN via iSCSI/ FC.
Ob das über NFS geht, weiß ich nicht/ glaube ich nicht.
Edit:
NFS = File Level Protokoll wie SMB
iSCSI = Block Level Protokoll
VEEAM sich die Daten dann direkt von der LUN holt, statt über das ESXi-Netzwerk zu gehen.
OK, das war dann im Eifer des Gefechts missverstanden, sorry.Die o.a. VEEAM Maschine holt sich via ESXi Netzwerk die VM (die per NFS auf einem 10G SSD NAS liegt) und sichert sie per NFS auf ein anderes Backup NAS. Simpler Klassiker also.
Daher die Frage ob es Vorteile hat iSCSI zu verwenden statt NFS?
Wir haben ein QNAP welches per iSCSI an Veeam angebunden ist und ich bin froh wenn das weg kommt.
Für den Preis was das kostet kann man sich schon einen kleinen echten Server zusammenstellen mit echter Server CPU und RAM mit Fehlerkorrektur.
Unser QNAP hat auch nur ext4 und find so was für ein Backup Ziel nicht mehr zeitgerecht, sollte schon was sein was auch Fehler erkennen und reparieren kann wie BTRFS,ReFS oder ZFS.
Veeam bietet eine ISO für ein immutable storage an, wird nur auf Hardware unterstützt läuft unter Linux und man sollte das Ding nach dem Setup besser nicht mehr anfassen. Kein Rootzugriff, keine Updates selbst einspielen.
Im Gegensatz zu einer iSCSI Lösung kann das Repository auch auch Sachen wie Fullfilemerges lokal machen ohne das der Backupserver es machen muss... weniger Traffic und weniger RAM und CPU Last auf dem Backupserver.
Und nachdem bei Veeam anscheinend die Tendenz dazu geht, das irgendwann auch der Backupserver unter Linux läuft, wird sicher bald alles nur noch über eine Weboberfläche gesteuert.
Wegen Snapshots und ESXI Netzwerk...so weit ich weiss nutzt Veeam von Haus aus nur 30% des ESXi Netzwerkes.
Sauberer lief bei mir immer auf jeden Host eine VM zu haben in die Veeam einen Proxy installieren konnte. Der hat dann nur nach einen kleineren Snapshot die einzelnen Disks der VMs gemounted und nur die Veränderungen an den Backupserver übertragen, ohne das der Backupserver selbst was damit machen musste.
Für den Preis was das kostet kann man sich schon einen kleinen echten Server zusammenstellen mit echter Server CPU und RAM mit Fehlerkorrektur.
Unser QNAP hat auch nur ext4 und find so was für ein Backup Ziel nicht mehr zeitgerecht, sollte schon was sein was auch Fehler erkennen und reparieren kann wie BTRFS,ReFS oder ZFS.
Veeam bietet eine ISO für ein immutable storage an, wird nur auf Hardware unterstützt läuft unter Linux und man sollte das Ding nach dem Setup besser nicht mehr anfassen. Kein Rootzugriff, keine Updates selbst einspielen.
Im Gegensatz zu einer iSCSI Lösung kann das Repository auch auch Sachen wie Fullfilemerges lokal machen ohne das der Backupserver es machen muss... weniger Traffic und weniger RAM und CPU Last auf dem Backupserver.
Und nachdem bei Veeam anscheinend die Tendenz dazu geht, das irgendwann auch der Backupserver unter Linux läuft, wird sicher bald alles nur noch über eine Weboberfläche gesteuert.
Wegen Snapshots und ESXI Netzwerk...so weit ich weiss nutzt Veeam von Haus aus nur 30% des ESXi Netzwerkes.
Sauberer lief bei mir immer auf jeden Host eine VM zu haben in die Veeam einen Proxy installieren konnte. Der hat dann nur nach einen kleineren Snapshot die einzelnen Disks der VMs gemounted und nur die Veränderungen an den Backupserver übertragen, ohne das der Backupserver selbst was damit machen musste.
1
Moin,
ich glaube hier werden, wie von @em-pie erkannt, verschiedene Themen miteinander vermischt.
Die Anbindung des NAS an VMWare bzw die Filer hat rein gar nichts mit der Anbindung des Backup Repositories zu tun.
Der Hardware-Veeam Server ergibt sich aus der Nutzung von Tapes oder sogar einer Library.
Bindet man diesen nun NICHT an das SAN an, so nutz Veeam zur Sicherung den NBD Mode über den ESX-Kernel-Port. Das sind die erwähnten 30% = langsam. Dies kann man beschleunigen, indem man nen virtuellen Veeam Proxy verwendet. Hier wird nun Hot-Add verwendet. (Sieht man übrigens im Job-log von Veeam hinter jeder vdisk). Dabei läuft der Traffic nicht mehr über den KernelPort.
Bindet man nun den Hardware-Veeam Server direkt an das Storage an und nutz Backup from SAN oder Storage Snapshot (großer Unterschied zwischen beiden!), so bekommt die VM nur noch mitgeteilt dass sie gesichert wird, ein VM Snapshot wird angelegt und Veeam zieht sich alles per Storage Netzwerk (iSCSI oder FC).
Kommt Veeam bei einer VM nicht dran, so wird per Failback wieder NBD oder HotAdd genutzt.
Daher die sauberste Lösung, das NAS als Storage für ESX nutzen.
Greift die Filer VM inhaltlich auf das NAS zu, müsstest du für das NAS einen eigenen Job anlegen. FileShares oder NFS zu sichern ist nicht die Paradedisziplin von Veeam. Langsam und würde es verkomplizieren.
Nun stellt sich noch die Frage, wohin mit den Backup Files = Backup Repository.
Hier kann man die internen Platten des Veeam Servers nutzen oder auf eine beliebige Art und Weise NAS, NFS Shares, Dedup Repositories , uvm anbinden. Die räumliche Trennung hat der TO ja im Griff.
Sobald dieses Target auch noch Veeam Features mitbringt, ergeben sich weitere Möglichkeiten.
(das angesprochen Hardened Repository oder Dedup Appliances mit Veeam Plugin)
Was ich nicht machen würde: Backupdaten auf das gleiche Device legen wie die Nutzdaten.
OffTopic Frage: Warum ein NAS für die Nutzdaten und das Geld nicht in die Erweiterung des SAN gesteckt? Kosten?
Gruß und viel Erfolg!
ich glaube hier werden, wie von @em-pie erkannt, verschiedene Themen miteinander vermischt.
Die Anbindung des NAS an VMWare bzw die Filer hat rein gar nichts mit der Anbindung des Backup Repositories zu tun.
Der Hardware-Veeam Server ergibt sich aus der Nutzung von Tapes oder sogar einer Library.
Bindet man diesen nun NICHT an das SAN an, so nutz Veeam zur Sicherung den NBD Mode über den ESX-Kernel-Port. Das sind die erwähnten 30% = langsam. Dies kann man beschleunigen, indem man nen virtuellen Veeam Proxy verwendet. Hier wird nun Hot-Add verwendet. (Sieht man übrigens im Job-log von Veeam hinter jeder vdisk). Dabei läuft der Traffic nicht mehr über den KernelPort.
Bindet man nun den Hardware-Veeam Server direkt an das Storage an und nutz Backup from SAN oder Storage Snapshot (großer Unterschied zwischen beiden!), so bekommt die VM nur noch mitgeteilt dass sie gesichert wird, ein VM Snapshot wird angelegt und Veeam zieht sich alles per Storage Netzwerk (iSCSI oder FC).
Kommt Veeam bei einer VM nicht dran, so wird per Failback wieder NBD oder HotAdd genutzt.
Daher die sauberste Lösung, das NAS als Storage für ESX nutzen.
Greift die Filer VM inhaltlich auf das NAS zu, müsstest du für das NAS einen eigenen Job anlegen. FileShares oder NFS zu sichern ist nicht die Paradedisziplin von Veeam. Langsam und würde es verkomplizieren.
Nun stellt sich noch die Frage, wohin mit den Backup Files = Backup Repository.
Hier kann man die internen Platten des Veeam Servers nutzen oder auf eine beliebige Art und Weise NAS, NFS Shares, Dedup Repositories , uvm anbinden. Die räumliche Trennung hat der TO ja im Griff.
Sobald dieses Target auch noch Veeam Features mitbringt, ergeben sich weitere Möglichkeiten.
(das angesprochen Hardened Repository oder Dedup Appliances mit Veeam Plugin)
Was ich nicht machen würde: Backupdaten auf das gleiche Device legen wie die Nutzdaten.
OffTopic Frage: Warum ein NAS für die Nutzdaten und das Geld nicht in die Erweiterung des SAN gesteckt? Kosten?
Gruß und viel Erfolg!
4
