Bitmap sehr schnell dirty

[fabian]

das problem ist nicht der storage unter deiner VM, der spielt absolut keine rolle. das problem ist dass das backup in 4M chunks erfolgt, und jeder chunk einen fixen bereich deiner disk abdeckt. wenn du jetzt deine mini writes so ueber die disk verteilst, dass sich von vielen 4M chunks ein winziger teil aendert, dann musst du trotzdem jeden dieser chunks neu lesen und schreiben wenn du ihn sichern willst. das ist keine write amplification im klassischen sinne (die haettest du wenn du bei ZFS 4MB blocksize einstellen wuerdest ).

es gibt hier ein paar moegliche loesungen oder improvements:
- das write pattern anpassen, dass die writes lokaler sind und somit weniger chunks betreffen
- temp writes auf nicht gesicherte platten auslagern
- sicherstellen, dass daten die geloescht sind als nullen bzw. loecher zurueckgelesen werden (damit zumindest chunks die wieder komplett leer sein sollen auch wirklich als leer gelesen und wegoptimiert werden koennen, statt dass da quasi "nicht mehr gebrauchter muell" drin steht den PBS nicht als solchen erkennen kann)

fuer den letzten punkt waeren backup logs von ein und demselben backup von beiden seiten interessant, daraus sollte sich naemlich rekonstruieren lassen ob das passiert oder nicht

die chunksize nennenswert kleiner machen fuehrt zu einer explosion der chunkanzahl wodurch dann andere operationen/teile von PBS nicht mehr skalieren (riesen backup indizes, verification und vor allem GC viel teurer, ..)

 

[richardl]

Danke, Fabian. Ich denke, du hast da vollkommen recht.

„Temp-Writes auf nicht gesicherte Platten auslagern“ ist, denke ich, die einfachste und logischste Lösung hier, die mit wenig Aufwand großen Erfolg bringen würde. Eine RAM-Disk oder eine „Skip Backup“-Disk einrichten und dann das tmpdir in der Konfiguration setzen. Ich denke, wir müssen hier nicht mehr allzu viel Zeit investieren. Leider kann ich das Log nicht mehr finden.

Als letzten „Versuch“ habe ich aber noch einen Test mit einem Installatron DirectAdmin Backup-Server gemacht (nur SFTP-basierte ZIP-Datei-Transfers großer Dateien anstatt kleine random writes), um so auch die Effizienz auf der anderen Seite des Spektrums zu untersuchen.

---

INFO: scsi0: dirty-bitmap status: OK (217.3 GiB von 900.0 GiB dirty)
INFO: scsi1: dirty-bitmap status: OK (196.8 GiB von 500.0 GiB dirty)
...
INFO: Backup is sparse: 114.56 GiB (27%) total zero data

Insgesamt wurden also ca. 300 GB transferiert (dauerte auch eine ganze Stunde). ZFS hat das Ganze (mit Kompression) auf 70 GB reduziert. Da es sich um bereits gezippte Dateien handelt, denke ich, dass die Kompression nicht viel ausgemacht hat. Der Faktor liegt also in dieser Situation eher bei 4x anstatt bei 20x.

Wichtig für alle, die dies auch testen möchten: Wenn ich nur eine Datei hochlade, ist das Backup ungefähr 100 % effizient. Es scheint eine Folge von vielen verschiedenen Dateien, Dateisystem-Metadaten-Änderungen, fstrim, usw. nach mehreren Tagen zu sein, die schließlich eine Amplifikation um den Faktor 4 verursacht. Das ist nicht einfach herauszufinden. Meiner Meinung nach gibt es nur eine Möglichkeit es zu testen: selbst ein ZFS-Setup aufbauen, vor den PBS-Backups Snapshots machen und diese über eine längere Periode vergleichen mit einem server der auch wirklich stark benutzt wird.

Meine Schlussfolgerung
(Ich weiß, dass nicht alles validiert ist oder 100 % genau so sein muss, aber ich bin überzeugt, dass es der Wahrheit nahekommt.)

Im Vergleich zu ZFS (was mit kleiner Blockgröße sehr sehr effizient und leistungsfähig ist) gibt es in der Praxis immer einen Preis, den man für bitmap-basierte inkrementelle Backups zahlt. Abhängig davon, ob es um kleine Writes (wofür es eine Lösung gibt) oder große Writes geht, kann es eine Amplifikation um den Faktor 2 bis 20 geben, wenn man ZFS + LVM + ext4/ZFS nutzt.

• Die Deduplikation + Kompression von PBS gleicht das wieder aus und sorgt insgesamt für eine gute Effizienz.
• Die Deduplikation hat weniger Effekt als erwartet, da die großen Blöcke von 4 MB vor allem durch die Kompression profitieren. Dies häng natürlich ab von mehreren factoren, aber in meiner situation ist das so.
  • Die Anzeige „Deduplication Factor 13.40“, die ich beispielsweise sehe, entspricht ungefähr dem, was meine ZFS-Snapshots insgesamt benötigen (ca. 120 % im Vergleich zu PBS), um die gleichen Daten zu sichern – jedoch ohne Deduplikation. Vielleicht liegt das daran, dass durch die Amplifikation mehr Duplikate entstehen, wie bei ZFS. PBS ihre Deduplikation biegt das aber wieder „gerade“ und statischtisch bringt das dann viel Erleichterung (die bei ZFS nicht notwendig ist).

Wie auch immer – der Gesamteinfluss von Deduplikation ist geringer als erwartet, und ich persönlich bin zufrieden mit ZFS ohne Deduplikation, aber mit der erhöhten Effizienz der inkrementellen Backups weil mir die Bandbreite und andere resourcen wichtiger sind. Da ich sehr aktive Server mit vielen kleinen Writes betreibe und nicht überall eine Lösung einführen möchte, die nur teilweise hilft, halte ich eine selbst entwickelte ZFS offsite Replikation in meinem Fall für die bessere Option.

Ich teile meine Erkenntnisse, weil ich denke, dass sie anderen helfen könnten, selbst abzuwägen, was für sie die beste Lösung ist. PBS ist meiner Meinung nach keine „One-Size-Fits-All“-Lösung – muss es ja auch nicht sein.

Ich werde vieles an PBS vermissen, während ich meine eigene Lösung nutze. Ich finde PBS ein geniales Produkt und möchte mich auch herzlich für eure Unterstützung bedanken. Ich denke das es für die meisten Leute keinen Sinn macht sich um dass hier sorgen zu machen und PBS ist die richte Wahl in den meisten Fällen.