15
VEEAM BuR Offsite Backup
Hallo zusammen,
folgende Situation,
=> VMWare ESX mit vier VMs
=> VEEAM Backup & Recovery erstellt tägliche Datensicherung auf ein lokales NAS
=> Internet 100M/50M vorhanden
Was wäre aktuell die gängigste Praxis für ein Offsite-Backup auf z.B. ein anderes NAS (auch Synology) oder gibt es einen Cloudanbieter, den man direkt andocken könnte?
folgende Situation,
=> VMWare ESX mit vier VMs
=> VEEAM Backup & Recovery erstellt tägliche Datensicherung auf ein lokales NAS
=> Internet 100M/50M vorhanden
Was wäre aktuell die gängigste Praxis für ein Offsite-Backup auf z.B. ein anderes NAS (auch Synology) oder gibt es einen Cloudanbieter, den man direkt andocken könnte?
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: 669924
Url: https://administrator.de/forum/veeam-bur-offsite-backup-669924.html
Ausgedruckt am: 08.01.2025 um 09:01 Uhr
15 Kommentare
Neuester Kommentar
Hi
Gruß
folgende Situation,
=> VMWare ESX mit vier VMs
=> VEEAM Backup & Recovery erstellt tägliche Datensicherung auf ein lokales NAS
=> Internet 100M/50M vorhanden
Was wäre aktuell die gängigste Praxis für ein Offsite-Backup auf z.B. ein anderes NAS (auch Synology) oder gibt es einen Cloudanbieter, den man direkt andocken könnte?
Ja es gibt verschiedene Cloud Anbieter, welche man direkt andocken kann. Alternativ S3 Storages, welche Immutable sind. Hättest du aber auch in 2 min "googlen" selbst finden können.=> VMWare ESX mit vier VMs
=> VEEAM Backup & Recovery erstellt tägliche Datensicherung auf ein lokales NAS
=> Internet 100M/50M vorhanden
Was wäre aktuell die gängigste Praxis für ein Offsite-Backup auf z.B. ein anderes NAS (auch Synology) oder gibt es einen Cloudanbieter, den man direkt andocken könnte?
Gruß
Moin,
Bedenke aber, dass ein Cloudspeicher/ Außer-Haus-NAS nicht offline ist und damit tendenziell 24/7 erreichbar.
Für Offsite wäre ein Tape/ RDX IMHO am geschicktesten…
Welches Datenvolumen ist eigentlich vorhanden?
Bedenke aber, dass ein Cloudspeicher/ Außer-Haus-NAS nicht offline ist und damit tendenziell 24/7 erreichbar.
Für Offsite wäre ein Tape/ RDX IMHO am geschicktesten…
Welches Datenvolumen ist eigentlich vorhanden?
Geht um ca. 1,5TB..
@informatikkfm
du kannst natürlich auch das erste NAS auf das zweite spiegeln, und das zweite eben zeitgesteuert ein-/ausschalten je nach Job und bedarf. Das ist dann auch in gewisser weise Offline/Offsite.
Bei Cloud-Speicher wäre ich eher skeptisch.
Kreuzberger
du kannst natürlich auch das erste NAS auf das zweite spiegeln, und das zweite eben zeitgesteuert ein-/ausschalten je nach Job und bedarf. Das ist dann auch in gewisser weise Offline/Offsite.
Bei Cloud-Speicher wäre ich eher skeptisch.
Kreuzberger
Zitat von @em-pie:
Moin,
Bedenke aber, dass ein Cloudspeicher/ Außer-Haus-NAS nicht offline ist und damit tendenziell 24/7 erreichbar.
Für Offsite wäre ein Tape/ RDX IMHO am geschicktesten…
Welches Datenvolumen ist eigentlich vorhanden?
Moin,
Bedenke aber, dass ein Cloudspeicher/ Außer-Haus-NAS nicht offline ist und damit tendenziell 24/7 erreichbar.
Für Offsite wäre ein Tape/ RDX IMHO am geschicktesten…
Welches Datenvolumen ist eigentlich vorhanden?
Also wenn man es genau nimmt, kann ein Tape in einer Tape Library auch online sein ;) das was du meinst ist ein AirGap.
Wobei aber ein s3 Speicher mit ObjecktLock weniger kritisch ist, als ein Synology, welcher via smb oder nfs angebunden ist.
Ps.: ein qnap mit QuObject als s3 Speicher ist mittlerweile sogar von Veeam als „VeeamReady“ zertifiziert.
Nutzen wir an den kleinsten Standorten bei uns irgendwo auf der Welt verteilt als First Backup.
Pro Tag oder initial?
Aber auch da kann man zyklisch Tapes ausspucken lassen. Machen wir z.B. das Wochentape wird in den I/O gelegt und für das Offsite extern eingelagert.
Man könnte aber auch an ein Immutable Backup Target denken. Das kann ja auch Remote irgendwo liegen.
Also wenn man es genau nimmt, kann ein Tape in einer Tape Library auch online sein ;) das was du meinst ist ein AirGap.
Stimmt wohl. Wobei ich die Library (noch) nicht ins Rennen gebracht habe Aber auch da kann man zyklisch Tapes ausspucken lassen. Machen wir z.B. das Wochentape wird in den I/O gelegt und für das Offsite extern eingelagert.
Man könnte aber auch an ein Immutable Backup Target denken. Das kann ja auch Remote irgendwo liegen.
Moin zusammen.
Das ist hier die wichtige Frage, wenn keine Bänder oder mobile Festplatten hin- und hergetragen werden sollen.
Denn der Upload bei der beschriebenen Leitung mit 1000/50 Mbit/s würde eine tägliche Sicherung dieser Datenmenge nicht wirklich stemmen können.
Die zu sichernde Differenz wird wahrscheinlich/hoffentlich geringer sein.
Ansonsten die vorgeschlagenen Lösungen mittels RDX Bänder ins Auge fassen.
Etwas Anderes würde bei dem schmalen Upload keinen Sinn machen bei mehreren hundert GB täglich zu sicherndem Volumen.
Grüße
Marc
Moin,
es handelt sich initial um ca. 1,5TB. Lässt sich ein S3-comp Bucket auch auf einer Synology einrichten? Bei Qnap hatte ich das gesehen, für Synology wird mir aktuell nur der C2 Object Storage als Abo-Produkt ausgeworfen.
es handelt sich initial um ca. 1,5TB. Lässt sich ein S3-comp Bucket auch auf einer Synology einrichten? Bei Qnap hatte ich das gesehen, für Synology wird mir aktuell nur der C2 Object Storage als Abo-Produkt ausgeworfen.
+1 für Tape-Sicherung
Ich habe das allerdings mit 2 Einzellaufwerken gebaut, die nach Abschluss das Band auswerfen.
Da die Laufwerke nicht selber einziehen können, war das nach Abschluss des Jobs Offline.
Bedeutet aber, dass Du ein Laufwerk brauchst, bei dem die Datenmenge auf ein Tape passt und Du jeden Tag die Bänder tauschen musst.
Gruß
Looser
Ich habe das allerdings mit 2 Einzellaufwerken gebaut, die nach Abschluss das Band auswerfen.
Da die Laufwerke nicht selber einziehen können, war das nach Abschluss des Jobs Offline.
Bedeutet aber, dass Du ein Laufwerk brauchst, bei dem die Datenmenge auf ein Tape passt und Du jeden Tag die Bänder tauschen musst.
Gruß
Looser
Moin,
Wir haben auch Veeam B&R und eine ESXi-Umgebung, von daher ist es vergleichbar. Unser Backup-Konzept ist folgendermaßen aufgebaut.
Hauptsicherung auf Backup-Server (Hauptjob)
Offsite-Copy-Job zum NAS (Secondary target vom Hauptjob) zu einem Gebäude im gleichen Ort über 600 Mbit Dark-Fiber
Cloud-Copy-Job (Backup Copy Job) zu Wasabi S3
Wasabi ist preislich sehr günstig. Im "Pay-as-you-Go" Modell zahlen wir aktuell für knapp 6,5 TB aktiven Speicher und 1 TB gelöschten Speicher ca. $60 im Monat.
Wir haben auch Veeam B&R und eine ESXi-Umgebung, von daher ist es vergleichbar. Unser Backup-Konzept ist folgendermaßen aufgebaut.
Hauptsicherung auf Backup-Server (Hauptjob)
Offsite-Copy-Job zum NAS (Secondary target vom Hauptjob) zu einem Gebäude im gleichen Ort über 600 Mbit Dark-Fiber
Cloud-Copy-Job (Backup Copy Job) zu Wasabi S3
Wasabi ist preislich sehr günstig. Im "Pay-as-you-Go" Modell zahlen wir aktuell für knapp 6,5 TB aktiven Speicher und 1 TB gelöschten Speicher ca. $60 im Monat.
Moin,
noch was zu wasabi, eigentlich haben die ne 90 tage retention policy für gelöschte Daten. Wenn man es allerdings nur als backup-ziel für veeam benutzt setzen sie das auf Anfrage auf 30 Tage runter, ist ne gute Möglichkeit was zu sparen
noch was zu wasabi, eigentlich haben die ne 90 tage retention policy für gelöschte Daten. Wenn man es allerdings nur als backup-ziel für veeam benutzt setzen sie das auf Anfrage auf 30 Tage runter, ist ne gute Möglichkeit was zu sparen
Initiales Backup könnte man bei Veeam seeden, würde die lange initiale Uploadzeit sparen.
Und solange am anderen Ende nicht nur irgendein Share liegt könnte man sich einen Haufen Traffic sparen und das Repo die Arbeit mit den Vollbackups machen lassen.
Veeam arbeitet gerade an einer Hardened Linux Repository Lösung, quasi "schlüsselfertig" als ISO und aktuell im "experimentellen" Support.
https://forums.veeam.com/veeam-backup-replication-f2/managed-hardened-re ...
Werd ich mir wohl zulegen nächstes Jahr, eines für On-Site und eines Off-Site.
Kommt günstiger als ein neues LTO Laufwerk und Tapes und ein neues NAS.
Und solange am anderen Ende nicht nur irgendein Share liegt könnte man sich einen Haufen Traffic sparen und das Repo die Arbeit mit den Vollbackups machen lassen.
Veeam arbeitet gerade an einer Hardened Linux Repository Lösung, quasi "schlüsselfertig" als ISO und aktuell im "experimentellen" Support.
https://forums.veeam.com/veeam-backup-replication-f2/managed-hardened-re ...
Werd ich mir wohl zulegen nächstes Jahr, eines für On-Site und eines Off-Site.
Kommt günstiger als ein neues LTO Laufwerk und Tapes und ein neues NAS.
Hi,
wir nutzen bei einem Großteil unserer Kunden SMB-Shares bei z.B. Strato oder Keyweb, zT angebunden über unsere Service Provider Console. Wichtig ist, dass die Backups verschlüsselt werden und zusätzlich sicherstellen, dass SMB3+ genutzt wird, damit auch der SMB Traffic selber verschlüsselt ist. Und dann würde ich forever forward incrementals einrichten, sodass der Upload-Traffic gering bleibt. Wir sichern z.T. stündlich, damit die changing rate möglichst klein bleibt. Ein Backuplauf ist dann nach etwa 15 fertig, je nach Datenmenge natürlich. Und daneben die lokalen Backups auf ein NAS. Man muss aaber auch an einen potentiellen restore denken. Im Worst-Case will man vielleicht nicht auf das Internet angewiesen sein.
MfG
wir nutzen bei einem Großteil unserer Kunden SMB-Shares bei z.B. Strato oder Keyweb, zT angebunden über unsere Service Provider Console. Wichtig ist, dass die Backups verschlüsselt werden und zusätzlich sicherstellen, dass SMB3+ genutzt wird, damit auch der SMB Traffic selber verschlüsselt ist. Und dann würde ich forever forward incrementals einrichten, sodass der Upload-Traffic gering bleibt. Wir sichern z.T. stündlich, damit die changing rate möglichst klein bleibt. Ein Backuplauf ist dann nach etwa 15 fertig, je nach Datenmenge natürlich. Und daneben die lokalen Backups auf ein NAS. Man muss aaber auch an einen potentiellen restore denken. Im Worst-Case will man vielleicht nicht auf das Internet angewiesen sein.
MfG
Zitat von @support-m:
Hi,
wir nutzen bei einem Großteil unserer Kunden SMB-Shares bei z.B. Strato oder Keyweb, zT angebunden über unsere Service Provider Console. Wichtig ist, dass die Backups verschlüsselt werden und zusätzlich sicherstellen, dass SMB3+ genutzt wird, damit auch der SMB Traffic selber verschlüsselt ist. Und dann würde ich forever forward incrementals einrichten, sodass der Upload-Traffic gering bleibt. Wir sichern z.T. stündlich, damit die changing rate möglichst klein bleibt. Ein Backuplauf ist dann nach etwa 15 fertig, je nach Datenmenge natürlich. Und daneben die lokalen Backups auf ein NAS. Man muss aaber auch an einen potentiellen restore denken. Im Worst-Case will man vielleicht nicht auf das Internet angewiesen sein.
MfG
Hi,
wir nutzen bei einem Großteil unserer Kunden SMB-Shares bei z.B. Strato oder Keyweb, zT angebunden über unsere Service Provider Console. Wichtig ist, dass die Backups verschlüsselt werden und zusätzlich sicherstellen, dass SMB3+ genutzt wird, damit auch der SMB Traffic selber verschlüsselt ist. Und dann würde ich forever forward incrementals einrichten, sodass der Upload-Traffic gering bleibt. Wir sichern z.T. stündlich, damit die changing rate möglichst klein bleibt. Ein Backuplauf ist dann nach etwa 15 fertig, je nach Datenmenge natürlich. Und daneben die lokalen Backups auf ein NAS. Man muss aaber auch an einen potentiellen restore denken. Im Worst-Case will man vielleicht nicht auf das Internet angewiesen sein.
MfG
Gibt es Gründe, warum ihr speziell smb3 mit strato nutzt und nicht ggf s3, wenns übers Web geht?
Gruß
Zitat von @tech-flare:
Gibt es Gründe, warum ihr speziell smb3 mit strato nutzt und nicht ggf s3, wenns übers Web geht?
Hallo,Gibt es Gründe, warum ihr speziell smb3 mit strato nutzt und nicht ggf s3, wenns übers Web geht?
nee, rückblickend betrachtet war S3 bei uns damals einfach nicht auf dem Schirm. Als wir angefangen haben haben wir unseren eigenen dedizierten Server aufgesetzt und da lief einfach nur ein Ubuntu Server mit einem SMB Server, der nur Verbindungen von unserer Provider Console erlaubt hat. Und dann sind wir halt bei SMB geblieben. Ich werde es mal intern ansprechen, ob S3 vielleicht inzwischen eine bessere Alternative ist
Danke.MfG
