LTO9 Bachup Geschwindigkeit

Das ergibt jetzt für mich noch weniger Sinn. Wie funktioniert denn das Backup auf Tape?
Daten der letzten Sicherung werden gelesen und an das Band geschickt. Oder nicht?
Ein Verify der letzten Sicherung ist genau das, nur ohne die Daten ans Band zu schicken.
Somit kann man doch gut testen, ob es an der Geschwindigkeit der HDDs liegt oder was anderes.
Und spätestens nach eine Woche "prune" "gc" und "Neusicherungen" liegen die Blöcke sowieso random auf den Datenträgern...
 
Nicht ganz, die aktuellen Inkrements sind so ziemlich am Stück. Beim Copy auf Tape kopiert er ja Komplette VMs, wo auch alte Daten für das Synthetische Full gelesen werden. Dabei sollte theoretisch mehr Random I/O entstehen.
 
Also ist eine Sicherung auf Tape immer der komplette Datastore? Was ja eigentlich auch sinnvoll ist.
Dann würde ein Verify des gesamten Datastores die Lesegeschwindigkeit der HDDs direkt wiedergeben.
 
JensF said:
Also ist eine Sicherung auf Tape immer der komplette Datastore? Was ja eigentlich auch sinnvoll ist.
Click to expand...
Ja, wobei aber schon nur die Chunks aufs Tape geschrieben werden, die sich geändert haben und noch nicht drauf sind.

Z.b am Montag wird ein leeres Tape eingelegt und es werden zb. 8 TB Daten geschrieben (dauert viele Stunden). Am Dienstag gibts wieder Backups und Änderungen am Datastore, die werden dann wieders aufs Tape geschrieben (aber halt nur die Änderungen) das dauert dann nur ein paar Minuten, aber halt nur wenn die Zugriffszeiten auf die Daten auch schnell sind.
 
Wenn du inkrements Backupst dann ist das richtig und sollte ähnlich schnell sein wie dein Verify.
Wie ist denn das Tape angebunden?
Ich hatte mal Stress gesehen bei einem Setup wo das Tape am selben HBA gesteckt war wie einige Disks.
 
Falk R. said:
Wenn du inkrements Backupst dann ist das richtig und sollte ähnlich schnell sein wie dein Verify.
Wie ist denn das Tape angebunden?
Ich hatte mal Stress gesehen bei einem Setup wo das Tape am selben HBA gesteckt war wie einige Disks
Click to expand...
Ich weiß nicht genau, wie das Tape angeschlossen ist. Dafür müsste ich nachsehen. Aber ich denke das hängt alles am gleichen HBA.
 
JensF said:
Also ist eine Sicherung auf Tape immer der komplette Datastore?
Click to expand...

Nicht notwendigerweise. Wenn du beim tape Backup-Job nur einen Namespace auswählst, oder Gruppenfilter setzt, dann werden nur die chunks kopiert, die in den betreffenden backups indexes referenziert werden.
Also, falls du keine Filter setzt, dann wird wirklich alles kopiert, sonst nicht.

Und in jedem Fall werden pro media-set immer nur die neuen chunks, welche seit dem letzen Backup dazugekommen sind, aufs tape gegeben. Wenn man etwa ein beim media-pool einstellt, dass ein neues media-set wöchentlich angefangen (allocated) wird, dann ist das erste backup in der woche ein volles, und die nachfolgenden von derselben Woche sind nur noch inkrementell.
sysadmin_cns said:
Aber ich denke das hängt alles am gleichen HBA.
Click to expand...
Na ja, das könnte (je nach Model und Anbindung) wirklich einen Einfluss haben, insbesondere wenn während des tape Backups auch noch normale Backups in den PBS datastore hereinkommen ist an dem Bus, bzw. für den HBA, schon recht viel los.

Hast du auch schon mal mit den Tuning-Optionen gespielt? Also etwa mal die chunk order von "inode" auf "none" gestellt.
Normal ist inode sortierung besser für Spinning-Disks, aber wir hatten schon mal ein system wo's damit leicht schlechter war.

Was auch interessant wäre, die pressure-stall information während eines tape backups, damit sieht man auch, ob etwa, bspw., nicht doch CPU das problem sein könnte.

head /proc/pressure/*
 
t.lamprecht said:
Nicht notwendigerweise. Wenn du beim tape Backup-Job nur einen Namespace auswählst, oder Gruppenfilter setzt, dann werden nur die chunks kopiert, die in den betreffenden backups indexes referenziert werden.
Also, falls du keine Filter setzt, dann wird wirklich alles kopiert, sonst nicht.

Und in jedem Fall werden pro media-set immer nur die neuen chunks, welche seit dem letzen Backup dazugekommen sind, aufs tape gegeben. Wenn man etwa ein beim media-pool einstellt, dass ein neues media-set wöchentlich angefangen (allocated) wird, dann ist das erste backup in der woche ein volles, und die nachfolgenden von derselben Woche sind nur noch inkrementell.

Na ja, das könnte (je nach Model und Anbindung) wirklich einen Einfluss haben, insbesondere wenn während des tape Backups auch noch normale Backups in den PBS datastore hereinkommen ist an dem Bus, bzw. für den HBA, schon recht viel los.

Hast du auch schon mal mit den Tuning-Optionen gespielt? Also etwa mal die chunk order von "inode" auf "none" gestellt.
Normal ist inode sortierung besser für Spinning-Disks, aber wir hatten schon mal ein system wo's damit leicht schlechter war.

Was auch interessant wäre, die pressure-stall information während eines tape backups, damit sieht man auch, ob etwa, bspw., nicht doch CPU das problem sein könnte.

head /proc/pressure/*
Click to expand...
Hiermal der Head:
Code: 
==> /proc/pressure/cpu <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=1514727467
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

==> /proc/pressure/io <==
some avg10=28.98 avg60=30.99 avg300=31.40 total=511090313582
full avg10=28.11 avg60=30.30 avg300=30.71 total=502109707979

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=473913331
full avg10=0.00 avg60=0.00 avg300=0.00 total=472614810

Es laufen ständig 10 Backup Jobs rein. Dazu das Backup auf Tape.

Hab gestern bei Tuning Options die Chunk Order auf inode und den Sync Level auf Default /Filesystem) gestellt.
Die Frage ist, wann zieht die Änderung ?

Im nächsten Jahr bekommen wir noch ein zweites Drive für die Library. Wir müssen ja irgendwie die fast 200T auf Band bekommen.
Und das ganze soll ja auch nicht ewig dauern.
 
Wenn du Tape und Disk am gleichen HBA hast wird es immer langsam. Tape arbeitet im Stream Modus und Disk macht Wahlfreie Zugriffe.
Eventuell macht es ja Sinn bei den Mengen sich von Tape zu verabschieden.
Meine Kunden in der Größe machen Backup Copy nur noch auf Disk, hauptsächlich wegen den Backup und Restorezeiten. Außerdem bekommt man so einen besseren Ransomwareschutz hin.
 
Für 11 laufende Backups sind das für mich eindeutig zu wenig "W" im nmon.
Was für ein HBA ist das denn überhaupt?
 
Die Empfehlung von allen Herstellern ist, einen dedizierten HBA für Tapes nutzen. Hat bestimmt schon einen Grund.
 
  • Like
Reactions: JensF
Okay, der OnBoard ist ein Broadcom 3008 SAS3 wahrscheinlich mit Expander auf 32 Ports. Sollte eigentlich auch kein Problem sein.
Mir gehen die Ideen aus.
 
Kleines Update:
Folgendes wurde noch versucht.
Wir haben noch ein Special Mirror Device hinzugefügt.
Auch haben wir unsere Backups Jobs angepasst. (Daily/Weekly/Monthly)
Es laufen nun weniger Jobs zeitgleich.
Write auf Band geht jetzt manchmal auf über 100MB/s.
 
Last edited:
Das ist aber trotzdem keine gute Performance. Siehst du während des Jobs noch irgendwo etwas höhere Auslastung? CPU eventuell?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom