12
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
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: 7172117018
Url: https://administrator.de/forum/acronis-cyberprotect-replikation-auf-band-7172117018.html
Ausgedruckt am: 22.12.2024 um 03:12 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?
Acronis selbst zeigt bei den Aktivitäten die Durchsatzrate nur bei den "normalen" Jobs an.
Also VM bzw. Daten an Depot.
Dabei liegt das immer irgendwo zwischen 50 und 200 MB/s, was ich durchaus ok finde.
Vor allem, weil das teilweise für mehrere Jobs gleichzeitig gilt.
Leider gibt es diese Anzeige bei Replikationsjobs nicht.
Da steht nur Startzeit und aktuelle Dauer sowie eine Prozentanzeige des Fortschritts.
Was von dieser zu halten ist wissen wir ja alle.
Und die angezeigte Restdauer bei Acronis ist nur verlässlich, wenn die unter einer Stunde ist.
Dann werden Minuten angezeigt.
Ist die Restdauer länger, steht da ".. mehr als eine Stunde".
Naja, das können zwei oder 40 sein
Also VM bzw. Daten an Depot.
Dabei liegt das immer irgendwo zwischen 50 und 200 MB/s, was ich durchaus ok finde.
Vor allem, weil das teilweise für mehrere Jobs gleichzeitig gilt.
Leider gibt es diese Anzeige bei Replikationsjobs nicht.
Da steht nur Startzeit und aktuelle Dauer sowie eine Prozentanzeige des Fortschritts.
Was von dieser zu halten ist wissen wir ja alle.
Und die angezeigte Restdauer bei Acronis ist nur verlässlich, wenn die unter einer Stunde ist.
Dann werden Minuten angezeigt.
Ist die Restdauer länger, steht da ".. mehr als eine Stunde".
Naja, das können zwei oder 40 sein
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.
Moin,
was ist das denn für ein LTO-9 Laufwerk und was für eine SAS-Schnittstelle nutzt Du?
Was für eine Controller-Karte stellt Dir SAS bereit?
Und ganz trivial....schon mal die Kabel getauscht?
Gruß
Looser
was ist das denn für ein LTO-9 Laufwerk und was für eine SAS-Schnittstelle nutzt Du?
Was für eine Controller-Karte stellt Dir SAS bereit?
Und ganz trivial....schon mal die Kabel getauscht?
Gruß
Looser
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?
Das hatte ich schonmal, das führte glaub ich dazu, dass die Jobs so lange dauerten, dass die Folgejobs recht lange warten mussten.
Aber das kann ich natürlich nochmal testen - "früher" war es noch ein LTO7 Laufwerk, das ist langsamer.
was ist das denn für ein LTO-9 Laufwerk und was für eine SAS-Schnittstelle nutzt Du?
Was für eine Controller-Karte stellt Dir SAS bereit?
Und ganz trivial....schon mal die Kabel getauscht?
Was für eine Controller-Karte stellt Dir SAS bereit?
Und ganz trivial....schon mal die Kabel getauscht?
Laufwerk : IBM Ultrium 9 HH - extern
Controller: N2225 SAS7SATA-HBA (12GB)
Kabel getauscht ? Nee. Das Laufwerk "langweilt" sich eher, weil zu wenig Daten ankommen.
Zumindest geht das beim einscannen kompletter Bänder deutlich schneller.
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
Naja....
Auf dem NAS (Synology Rackstation RS4017xs+, 48GB, 16x 14TB IronWolf, RAID-6) sind die Depots als iSCSI-LUN mit 135TB Größe angelegt.
Die Anbindung ist mit 2 x 10GBit Bond (auch am Backup-Server).
Die LAN Verbindung wird nicht annähernd ausgelastet, denn dann denke ich, würde wohl noch mehr an Daten am Laufwerk ankommen.
Kann natürlich sein, dass das Laufwerk selbst immer pausiert.
Aber SSDs in der Größe in einen einzelnen Backup-Server zu verfrachten - ich weiß nicht, da wollte ich beim NAS auf Nummer sicher gehen.
Wie gesagt, Backups zum (gleichen) NAS laufen deutlich schneller.
Würde ggf. ein SSD-Cache im NAS helfen ?
Im normalen Betrieb klar, aber bei sequenziellen Daten bin ich noch nie auf die Idee gekommen.
Auf dem NAS (Synology Rackstation RS4017xs+, 48GB, 16x 14TB IronWolf, RAID-6) sind die Depots als iSCSI-LUN mit 135TB Größe angelegt.
Die Anbindung ist mit 2 x 10GBit Bond (auch am Backup-Server).
Die LAN Verbindung wird nicht annähernd ausgelastet, denn dann denke ich, würde wohl noch mehr an Daten am Laufwerk ankommen.
Kann natürlich sein, dass das Laufwerk selbst immer pausiert.
Aber SSDs in der Größe in einen einzelnen Backup-Server zu verfrachten - ich weiß nicht, da wollte ich beim NAS auf Nummer sicher gehen.
Wie gesagt, Backups zum (gleichen) NAS laufen deutlich schneller.
Würde ggf. ein SSD-Cache im NAS helfen ?
Im normalen Betrieb klar, aber bei sequenziellen Daten bin ich noch nie auf die Idee gekommen.
Mir fällt noch ein :
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 ?
Vielleicht ist die Summe dieser Zeiten ja trotzdem kleiner
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 ?
Vielleicht ist die Summe dieser Zeiten ja trotzdem kleiner
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.
Naja, ist einen Versuch wert.
Da werde ich mich wohl später melden.
Muss erstmal ein, zwei große Platten 14TB oder so organisieren
Da werde ich mich wohl später melden.
Muss erstmal ein, zwei große Platten 14TB oder so organisieren
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.....
Hmm, Treiber für Controller und Tapedrive sind jeweils aktuell.
Aber zu spät ich habe ne 14TB WD Gold, einen Wechselrahmen (ging nicht anders in dem Servergehäuse) sowie passendes externes SAS Kabel bestellt.
Somit hängt das Bandlaufwerk und die Pufferplatte am selben Controller.
Aber zu spät
ich habe ne 14TB WD Gold, einen Wechselrahmen (ging nicht anders in dem Servergehäuse) sowie passendes externes SAS Kabel bestellt.Somit hängt das Bandlaufwerk und die Pufferplatte am selben Controller.
