Acronis Cyberprotect Replikation auf Band
Guten Tag in die Runde,
ich bräuchte mal Schwarmwissen bzw. Erfahrungen, wir Ihr so etwas realisiert.
Folgende Konfiguration wird bei uns bei Backups gefahren :
Software : Acronis Cyberprotect Version 15.0.31791
Backup-Server : einzelne Maschine, XEON E-2278G 8core (16vCores), 64GB, Systemvolume auf SSDs
BACKUP-Ziel (Depots) : Storage-Node, angebunden per iSCSI (20GBit) auf einem NAS
Gesichert wird in GVS-Konfiguration (Voll monatlich, Diff wöchentlich, Incr. täglich) auf die Depots
Nun möchte ich alle Backups auf Bänder replizieren.
Dazu habe ich zwei Replikationsjobs erstellt, welche alle Backups aus den Depots auf Bänder (LTO9, Laufwerk per SAS direkt am Backupserver) replizieren sollen.
Das funktioniert im Grunde auch.
Allerdings laufen die Replikationsjobs extrem lange - teilweise über 48 Stunden - und blockieren mir natürlich andere Backups, da Überschneidungen entstehen.
Dabei sind die zu sichernden Daten jetzt nicht so groß. Einzelne Backups mit wenigen (60-100GB) replizieren teilweise 2-3 Stunden. Deren normales Backup dauert nur Minuten.
Gesamtgröße aller Backups pro Tag liegt bei ca. 500GB, außer monatlich, da kommen dann mal eben 6-7 TB zusammen.
Hat jemand Erfahrungen oder funktionierende Konfigurationen, die evtl. schneller laufen.
Acronis wurde schon befragt - kam allerdings noch keine brauchbare Antwort.
Grüße
Mike
ich bräuchte mal Schwarmwissen bzw. Erfahrungen, wir Ihr so etwas realisiert.
Folgende Konfiguration wird bei uns bei Backups gefahren :
Software : Acronis Cyberprotect Version 15.0.31791
Backup-Server : einzelne Maschine, XEON E-2278G 8core (16vCores), 64GB, Systemvolume auf SSDs
BACKUP-Ziel (Depots) : Storage-Node, angebunden per iSCSI (20GBit) auf einem NAS
Gesichert wird in GVS-Konfiguration (Voll monatlich, Diff wöchentlich, Incr. täglich) auf die Depots
Nun möchte ich alle Backups auf Bänder replizieren.
Dazu habe ich zwei Replikationsjobs erstellt, welche alle Backups aus den Depots auf Bänder (LTO9, Laufwerk per SAS direkt am Backupserver) replizieren sollen.
Das funktioniert im Grunde auch.
Allerdings laufen die Replikationsjobs extrem lange - teilweise über 48 Stunden - und blockieren mir natürlich andere Backups, da Überschneidungen entstehen.
Dabei sind die zu sichernden Daten jetzt nicht so groß. Einzelne Backups mit wenigen (60-100GB) replizieren teilweise 2-3 Stunden. Deren normales Backup dauert nur Minuten.
Gesamtgröße aller Backups pro Tag liegt bei ca. 500GB, außer monatlich, da kommen dann mal eben 6-7 TB zusammen.
Hat jemand Erfahrungen oder funktionierende Konfigurationen, die evtl. schneller laufen.
Acronis wurde schon befragt - kam allerdings noch keine brauchbare Antwort.
Grüße
Mike
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7172117018
Url: https://administrator.de/contentid/7172117018
Ausgedruckt am: 21.11.2024 um 10:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Performanceprobleme hatte ich auch mal.
Mein Backupserver ist auch bare metal, firewalled und sichert mit 2x 10GBit einen HyperV-Cluster. Als Software setze ich Veeam ein. Zwei Sicherungswege:
1. Weg: Hauptjob sichert alle VMs als reverse inkrementell und komprimiert auf ein per SAS angeschlossenes RAID-0 (dauert bei 6TB etwa 6,5h). Nach Abschluss dieses Jobs greift ein anderer die Sicherung auf und schreibt sie auf Band im GVS-Konzept (dauert dann nochmal 3h).
2. Weg: An Wochenenden wird ein zweites Backup auf ein NAS weggeschrieben (dauert auch etwa 6h).
Die Performanceprobleme bei mir lagen hauptsächlich in den Pfaden zum RAID-0 und zum Bandstreamer. Beides habe ich durch Einsatz entsprechend geeigneter Controller und Treiber in den Griff bekommen und bin zufrieden. Noch anhaltende Performanceprobleme kommen leider vom Cluster. Je nach Lastausgleich kann ich einen Hypervisor mit nicht mehr als zwei Tasks gleichzeitig ansteuern, sonst antworten die VMs dem Watchdog nicht mehr und werden durchgerissen. Das ist nicht Sinn der Sache. Wichtig für mich ist, dass das Hauptbackup während der Nacht fertig wird.
Kannst Du denn im Acronis irgendwelche Bottlenecks sehen oder listet der Datentransferraten auf?
Performanceprobleme hatte ich auch mal.
Mein Backupserver ist auch bare metal, firewalled und sichert mit 2x 10GBit einen HyperV-Cluster. Als Software setze ich Veeam ein. Zwei Sicherungswege:
1. Weg: Hauptjob sichert alle VMs als reverse inkrementell und komprimiert auf ein per SAS angeschlossenes RAID-0 (dauert bei 6TB etwa 6,5h). Nach Abschluss dieses Jobs greift ein anderer die Sicherung auf und schreibt sie auf Band im GVS-Konzept (dauert dann nochmal 3h).
2. Weg: An Wochenenden wird ein zweites Backup auf ein NAS weggeschrieben (dauert auch etwa 6h).
Die Performanceprobleme bei mir lagen hauptsächlich in den Pfaden zum RAID-0 und zum Bandstreamer. Beides habe ich durch Einsatz entsprechend geeigneter Controller und Treiber in den Griff bekommen und bin zufrieden. Noch anhaltende Performanceprobleme kommen leider vom Cluster. Je nach Lastausgleich kann ich einen Hypervisor mit nicht mehr als zwei Tasks gleichzeitig ansteuern, sonst antworten die VMs dem Watchdog nicht mehr und werden durchgerissen. Das ist nicht Sinn der Sache. Wichtig für mich ist, dass das Hauptbackup während der Nacht fertig wird.
Kannst Du denn im Acronis irgendwelche Bottlenecks sehen oder listet der Datentransferraten auf?
Mir fehlt da leider die Erfahrung in Acronis.
Bei Veeam wurde mir empfohlen den Bandjob keinesfalls nochmal zu komprimieren, was auch Sinn macht.
Hast Du mal probiert, ob es einen Unterschied macht, wenn Du keinen Replikationsjob erstellst, sondern einen normalen Sicherungsjob, der als Ausführzeitpunkt einfach direkt nach der Hauptsicherung startet - als Folgejob?
Vielleicht ändert sich ja dann etwas.
Es könnte sein, dass der Replikationsjob anders mit den Bändern haushaltet und viel auf Deduplizierung Wert legt. Das könnte dann zu einer längeren Laufzeit führen.
Bei Veeam wurde mir empfohlen den Bandjob keinesfalls nochmal zu komprimieren, was auch Sinn macht.
Hast Du mal probiert, ob es einen Unterschied macht, wenn Du keinen Replikationsjob erstellst, sondern einen normalen Sicherungsjob, der als Ausführzeitpunkt einfach direkt nach der Hauptsicherung startet - als Folgejob?
Vielleicht ändert sich ja dann etwas.
Es könnte sein, dass der Replikationsjob anders mit den Bändern haushaltet und viel auf Deduplizierung Wert legt. Das könnte dann zu einer längeren Laufzeit führen.
Nee. Das Laufwerk "langweilt" sich eher, weil zu wenig Daten ankommen.
Da hast Du Deinen Grund, warum das so lange dauert. Klingt seltsam, aber wenn ein LTO-LW die Daten nicht in adäquater Geschwindigkeit bekommt, geht die Leistung massiv runter, da das LW ständig neu anfängt.
Also schau, dass Du die Daten dem LW schneller zur Verfügung stellen kannst, z.B. mittels SSDs und jede Menge RAM Das NAS ist hier das Bottleneck......zum Test mal die Daten auf den Backup-Server und von dort auf das Band. Hier solltest Du eine deutliche Steigerung sehen.
Gruß
Looser
Ich hatte diese Probleme in meiner damaligen Konfig mit einem LTO-6 nicht. Backup per LAN auf das NAS geschoben (angebunden mit 4x 1GBit). Das LTO selbst hing an nem 6GBit-Controller. Da war das Tape-Backup von den knapp 4TB in wenigen Stunden erledigt.
Das kannst Du mit einem Backup und 2 Copy-Jobs erledigen. Einen Versuch ist es wert. Nach erfolgreichem 2. Kopiervorgang kannst Du die Platte mittels Skript wieder frei schaufeln.
Würde es etwas bringen, eine erste Replikation vom NAS zu einer Platte im Backup-Server zu machen (die geht ja schneller) und dann im Nachgang diese von der nunmehr lokalen Platte des Backup-Servers zum LTO-Laufwerk zu replizieren ?
Das kannst Du mit einem Backup und 2 Copy-Jobs erledigen. Einen Versuch ist es wert. Nach erfolgreichem 2. Kopiervorgang kannst Du die Platte mittels Skript wieder frei schaufeln.
Bevor Du jetzt wild Equipment tauscht, würde ich noch den Hinweis von @beidermachtvongreyscull beachten und schauen, ob alle Treiber aktuell sind.
Vielleicht hängts auch am Controller...es muss schließlich einen Grund haben, dass die Daten nicht schnell genug kommen.
Ich habe mir die Specs von dem NAS nochmal angesehen....ich glaube nicht mehr, dass das NAS selber schuld trägt.....eher etwas danach, also vom NAS Richtung Tape.....
Vielleicht hängts auch am Controller...es muss schließlich einen Grund haben, dass die Daten nicht schnell genug kommen.
Ich habe mir die Specs von dem NAS nochmal angesehen....ich glaube nicht mehr, dass das NAS selber schuld trägt.....eher etwas danach, also vom NAS Richtung Tape.....