Schnelle Sicherung v. großen Containern / Fast Backup with container of many files

[dcsapak]

hi,

danke dass du dir die zeit für den test genommen hast.

ich hab aber noch ein paar Fragen/Anmerkungen:

Mein Versuchsaufbau:

KVM-System auf ssd
container mit einem 30 GB großen Mount als Raw-File

wie genau ist die vm konfiguriert? und wie sieht der storage stack aus (am client + server)? ich frage, weil hardware beschleunigte avx/sse instructions einen riesen unterschied machen können
ich weiß grad nicht was für einen Algorithmus borg verwendet, habs auf die schnelle auch nicht herausgefunden aber pbs setzt auf crc32 + sha256, dh wenn beides hw unterstützt
laufen kann (am client!) wäre das super. vielleicht in der vm ein 'proxmox-backup-client benchmark' eventuell mit repository ausführen dann sieht man da einiges
ich glaube borg hat auch einen benchmark command, der output wäre auch interessant

der storage stack ist auch interessant um zu sehen wie die performance mit der Konfiguration zusammenhängt

Meine Testdaten:

sieht nach einem sinnvollen test aus, ich hoffe du hast sowohl am client als auch am server jeweils den page cache gelöscht?
mir passiert es immer mal wieder beim benchmarken dass ich vergesse zwischen runs bzw. zwischen den verschiedenen tools den cache zu löschen. hat natürlich riesige Auswirkungen
wenn alle files schon im cache sind... (je nach storage den host nicht vergessen...)

Ergänzung zu borg:

macht leider den vergleich ein wenig ungünstiger, da wir immer auf zstd (lvl1) setzen, welche compression ist denn default bei borg?
(sieht man auch gut am Speicherverbrauch des Repos)

zum benchmark selber:

welche Kommandos wurden denn ausgeführt?
mich wundert besonders die schlechte performance des image tests...
wenn du auch hier ein 'pxar' Archiv erstellt hast, hast du nicht ein image backup gemacht, sondern ein file-backup von einem image file
da würde dann wieder der dynamische Chunker laufen, und du hast nicht wirklich was gewonnen außer die stats der einzelnen files

(grundsätzlich sind bei einem benchmark immer die genaue Konfiguration + Kommandos sinnvoll, sodass andere die Ergebnisse nachvollziehen können, siehe zb unser zfs/ceph benchmark im PVE forum)

Zu den ergebnissen:
Wundert mich doch ein bisschen. Normales file-backup vs Borg hab ich mal vor einiger zeit hier: https://bugzilla.proxmox.com/show_bug.cgi?id=3174 gebenchmarkt und war beim initialen backup
ungefähr gleichauf wie borg. Das wäre zu erwarten, denn Borg und PBS machen grundsätzlich das gleiche: über files iterieren, metadaten + daten lesen, chunken, senden

Warum kein Imagebackup bei Containern?

habe ich bereits erklärt. Das würde eine grobe Umstellung im code für container restores + backup notwendig machen, die wir im Moment nicht in betracht ziehen, sowie grobe inkonsistenten in der backup art zwischen verschiedenen
storage typen.

Leider gibt es noch Probleme mit meiner Testumgebung, deshalb folgen dann die weiteren Zahlen.

Ich bin auf jeden Fall gespannt

 

[floh8]

@dcsapak:
Danke für dein Interesse.

CPU hat diese Features in der Testumgebung:

Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clfl
ush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopol
ogy cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2a
pic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm cpuid_fault p
ti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust xsa
veopt arat umip md_clear arch_capabilities

borg:
Nach den Algorithmen müßtest du mal selber schauen, wenn es dich interessiert. LZA oder sowas war es für die Komprimierung. Der Default halt. CRC weiß ich auch gerade nicht. Es wurde ja schon im Thread differenziert, dass borg anders vorgeht als ihr. Es arbeitet mit der FS-Table oder so.

Cache:
Spielt keine Rolle, denn es werden ja 'ne Menge Daten (viel größer als der Cache) gelesen und geschrieben. Da würde der Cache das Ergebnis nur zu 0.001% oder so verfälschen.

Befehle:
proxmox-backup-client backup ct102_data2.pxar:/mnt/vzsnap0/
proxmox-backup-client backup ct102_data.img:/mnt/pve/Big-storage/images/102/vm-102-disk-0.raw
borg --progress create --stats /mnt/pve/XFS_Teststor/::ct-data-full /mnt/vzsnap0/

performance:
proxmox-client sowie borg haben die gleiche Ausgangssituation. Das System ist natürlich nicht schnell. Damit müssen beide zurecht kommen. Es wird keiner bevorteilt oder benachteiligt. In diesem Test ging es ja gerade darum, den Vergleich zu sehen wie beide mit einem langsamen Storage+CPU zurecht kommen. Absolute Zahlen sind nicht relevant, sondern das Verhältnis zwischen den Testergebnissen.
Jeder kann ja auf seinem Produktivsystem diesen Test wiederholen, aber die Tendenz wird dann wohl ähnlich sein.
Ich habe noch die Auslastung während des Vollbackups und die Dateianzahl bei den Durchläufe oben hinzugefügt, die wollte ich noch angeben.

 

[dcsapak]

Hi, Vielen dank

CPU hat diese Features in der Testumgebung:

wie sieht es mit dem storage aus? (konkret, was ist 'Big-storage' und 'XFS_Teststor' für ein storage?

borg:
Nach den Algorithmen müßtest du mal selber schauen, wenn es dich interessiert. LZA oder sowas war es für die Komprimierung. Der Default halt. CRC weiß ich auch gerade nicht. Es wurde ja schon im Thread differenziert, dass borg anders vorgeht als ihr. Es arbeitet mit der FS-Table oder so.

ok so wies aussieht für compression lz4 (zitat aus den docs: low compression, but super fast) und die chunks hmac sha256
lz4 ist halt nicht so gut für einen vergleich geeignet.... vielleicht doch nochmal mit zstd lvl1 probieren?

Spielt keine Rolle, denn es werden ja 'ne Menge Daten (viel größer als der Cache) gelesen und geschrieben. Da würde der Cache das Ergebnis nur zu 0.001% oder so verfälschen.

Wieso sollte der host page cache keine rolle spielen? wenn alle daten aus /mnt/vzsnap0 schon mal gelesen wurden mit dem pbs client sind sie (zumindest zum teil) im page cache... und beim borg
backup kann direkt aus dem cache gelesen werden.
auch hast du keine angabe zur ram größe des clients gemacht....
auch wenn nur die inodes im page cache sind, kann das schon einen erheblich unterschied machen

was ich vorher vergessen habe: bitte bei einem benchmark *immer* mehrere Durchgänge (ich mach meistens 5-10) durchführen und den durchschnitt/median nehmen
damit kann man gut Ausreißer (sowohl in positive als auch negative Richtung) ausschließen

proxmox-backup-client backup ct102_data2.pxar:/mnt/vzsnap0/
proxmox-backup-client backup ct102_data.img:/mnt/pve/Big-storage/images/102/vm-102-disk-0.raw
borg --progress create --stats /mnt/pve/XFS_Teststor/::ct-data-full /mnt/vzsnap0/

was mir hier noch auffällt, scheinbar wird borg nicht auf ein netzwerk repo gesichert?
bei pbs ist *immer* netzwerk involviert was den test natürlich verändert

bitte auch bei borg ein remote repository verwenden (am besten auf den gleichen host wie pbs). kann auch via ssh auf localhost sein, macht den vergleich aber besser...

 

[floh8]

was mir hier noch auffällt, scheinbar wird borg nicht auf ein netzwerk repo gesichert?
bei pbs ist *immer* netzwerk involviert was den test natürlich verändert

Das ist richtig, das bringt eine minimal höhere Latenz, da es durch den Networkstack muss, aber da alles auf einer Maschine läuft, ist die aus meiner Sicht auch vernachlässigbar.

ok so wies aussieht für compression lz4 (zitat aus den docs: low compression, but super fast) und die chunks hmac sha256
lz4 ist halt nicht so gut für einen vergleich geeignet.... vielleicht doch nochmal mit zstd lvl1 probieren?

zu borg und zstd habe ich oben geschrieben, warum dies praktisch keinen Sinn macht. Dafür ist ja auch das Backup größer als bei proxmox.
ich hätte ja den Kompressionsalgorithmus für den proxmox-client angepasst, aber ihr lasst für den Client keine Ändernug zu (nachvollziehbar), also würde man im Praxisbetrieb die beiden Tools genau so einsetzen wie ich es getestet habe.

 

[dcsapak]

Das ist richtig, das bringt eine minimal höhere Latenz, da es durch den Networkstack muss, aber da alles auf einer Maschine läuft, ist die aus meiner Sicht auch vernachlässigbar.

Ob es vernachlässigbar ist kann man wohl erst nach dem testen sagen. TCP ist sehr latency sensitiv und außerdem wird das ganze dann bei pbs (und bei borg über ssh) noch durch tls durchgejagt...
außerdem schlägt bei lokalem backup wieder der page cache zu...

also würde man im Praxisbetrieb die beiden Tools genau so einsetzen wie ich es getestet habe.

mag sein (ist aber sehr individuell), dann macht der vergleich aber viel weniger sinn

 

[floh8]

wie sieht es mit dem storage aus? (konkret, was ist 'Big-storage' und 'XFS_Teststor' für ein storage?

bitte schau in die Info zur Testumgebung! ich habe sie nochmal genauer formuliert

 

[floh8]

danke noch für den Link oben: Peter spiegelt genau meine Meinung wieder. Damit meine ich jetzt nicht, dass er die ähnlichne Ergebnisse festgestellt hat wie ich, sondern eure Herangehensweise bzw. Einstellung. Ihr habt ein V-Produkt mit VMs und CT auf dem Markt und bringt eine Backuplösung heraus für diese Umgebung. Bei eurer Backuplösung vernachlässigt ihr aber die effiziente und damit praxistaugliche Sicherung von großen Containern bzw. Containern mit viele Dateien und gebt dann als Reaktion zu Kritiken den Hinweis, doch die VM zu nutzen, da es bei Containern zu aufwändig wäre, es anders umzusetzen. Ich glaube nicht, das Veeam jetzt dort stehen würde, wo sie jetzt stehen, wenn sie diese Einstellung gehabt hätten. Die Frage für mich ist auch, warum ihr euch so bitten lasst und wo eigentlich das Problem liegt. Denn technisch ist es auf jeden Fall lösbar, denn andere können es ja auch. Wenn ihr Manpower oder Know-How braucht, müßte ihr Entwickler einstellen oder Dienstleistung einkaufen. Wenn es an Geld fehlt, müßt ihr die Preise erhöhen. Wie ist eigentlich die Meinung eurer Geschäftsführung dazu? Kennen die eigentlich solche Problematiken, denn meistens interessiert die Manager das techn. Gewäsch ja nicht, aber sie interessiert vielleicht, was die Verbraucher wollen und wie sie ihr Produkt attraktiver machen können.

 

[tom]

Die Frage für mich ist auch, warum ihr euch so bitten lasst und wo eigentlich das Problem liegt.

Na ja, @dcsapak nimmt sich extras Zeit für dich und erklärt dir alle techn. Hintergründe. Offenbar gibts hier noch Verständisprobleme auf deiner Seite, da du immer wieder dieselben Fragen stellst und schon etwas sehr verwunderliche Schlussfolgerung aufstellst ("Angriff" auf die GF ...).

Ich glaube nicht, das Veeam jetzt dort stehen würde, wo sie jetzt stehen, wenn sie diese Einstellung gehabt hätten.

Von welcher "Einstellung" sprechen wir denn hier? Community User direkt und kostenfrei im Forum zu beraten und alle technischen Fragen zu beantworten ist für die meisten hier in der Community schon sehr fein, was stört dich daran?

Die User Fragen bei Veeam seit vielen Jahren nach KVM Unterstützung, leider ohne Erfolg.
(zb. https://forums.veeam.com/veeam-back...veeam-doing-anything-in-kvm-space-t23343.html)

 

[floh8]

Na ja, @dcsapak nimmt sich extras Zeit für dich und erklärt dir alle techn. Hintergründe. Offenbar gibts hier noch Verständisprobleme auf deiner Seite, da du immer wieder dieselben Fragen stellst und schon etwas sehr verwunderlich Schlussfolgerung aufstellst ("Angriff" auf die GF ...).

Von welcher "Einstellung" sprechen wir denn hier? Community User direkt und kostenfrei im Forum zu beraten und alle technischen Fragen zu beantworten ist für die meisten hier in der Community schon sehr fein, was stört dich daran?

Die User Fragen bei Veeam seit vielen Jahren nach KVM Unterstützung, leider ohne Erfolg.
(zb. https://forums.veeam.com/veeam-back...veeam-doing-anything-in-kvm-space-t23343.html)

Ich weiß nicht, warum du dich schon wieder in diesem Thread einmischst. Ich werde jedenfalls auf deine absichtliche Irreführung meines Posts nicht eingehen. Du verstehst anscheinend kein Deutsch bzw. willst es nicht verstehen und bringst keinen kostruktiven Beitrag. Ich bin mir sicher, alle Leser verstehen meinen Text und fragen sich auch, was deine Masche, die du ständig abziehst, bedeuten soll. Statt zu Diskreditieren hättest du mal Stellung beziehen sollen.

Einen Hinweis habe ich noch für euch: Wie in den bugzilla oben auch nachvollziehbar, geht ihr immer in Diskussion mit den Anwendern, um zu erklären, warum das Problem nicht lösbar wäre, anstatt intern unter den Entwicklern brain storming zu betreiben oder an einer Lösung zu basteln.
Als Anwender erwartet man bei so einer offensichtlichen Fehlfunktion eine Reaktion wie " Ja, danke für den Hinweis. Wir sind uns des Problems bewußt und disskutieren momentan noch über mögliche Lösungen. Momentan können wir in solchen Anwendungsfällen nur den Workaround anbieten, VMs statt Container einzusetzen." oder ähnliches. Damit wäre alles gesagt und der Anwender ist zufrieden.

Ich bin gespannt, was du Tom nun hier wieder rausliest. Vermutlich den ANGRIFF auf die Entwickler, die ja gar nix dafür können, wenn das Produkt nicht richtig funktioniert, gelle? Ich weiß echt nicht, was in deinen Hirn so verdreht ist. Naja, ich weiß es. Wer es auch wissen möchte, der schreibt mir bitte 'ne kurze pm.
Man kann nur hofffen, dass die GF nicht so verdreht ist wie du und vor allem, dass die das hier mal liest. Ich fordere dich auch höfflichst auf, zukünftig meinen Threads fern zu bleiben und deine dummen Kommentare für dich zu behalten.

 

[tom]

Ich weiß nicht, warum du dich schon wieder in diesem Thread einmischst.

Na ja, ich bin hier Forum Moderator und greife zb. ein, wenn User falsche Behauptungen aufstellen und Threads "abgleiten" und abstruse Theorien verbreitet werden.

anstatt intern unter den Entwicklern brain storming zu betreiben oder an einer Lösung zu basteln.

Zu behaupten das unser Entwickler sowas genau nicht machen ist dann schon etwas an der Haaren herbeigezogen.

Dein Art zu posten wird von mir nicht wirklich so gern gesehen, bitte halte dich an allgemeingültige Forenregeln. Natürlich kannst du das anderst sehen, aber wenn du in unserer Community posten willst, solltest dich an unsere Vorgaben halten müssen und dann bekommst du auch weiterhin Antworten auf deine Fragen.

 

[floh8]

Also, dann solltest du dich ja erst recht daran halten, was du nicht tust.

Zitat aus euren Terms:
"You agree to not use the Service to submit or link to any Content which is defamatory,......." und deine Post waren ein Paradebeispiel für Verleumdungen.

Ich gebe nun mal eine akzeptable Antwort, die man von Menschen mit Anstand und sozialer Kompetenz erwarten kann. "Danke floh8 für deine Hinweise, wir werden uns verbessern." Was macht der tom? Er verleumdet schon wieder, aber er hat nicht wieder den Begriff "Angriff" verwendet, sondern einfach mit anderen Wörten meine Aussage anders dargestellt. Herzallerliebst der tom. Für alle, die sich fragen, wie man dieses Vorgehen der Meinungsverdrehung nennt, der lese doch bitte mal Hinweise zur Kommunikation von Narzissten. Vielleicht findet man auch ähnliche Beispiele bei Hilfestellung zu Argumentationen, wenn ich keine Argumente mehr habe.

Ich habe mich gefragt, warum in dem Forum hier eigentlich immer nur die gleichen Leute Anworten posten. Naja, wenn du solche Moderatoren hier hast, ist das kein Wunder. Zum Glück ist die Software besser als die Moderationsfähigkeit, sonst wäre Proxmox wohl schon Pleite. Das wäre ein großer Verlust.

So ich bin jetzt hier raus. Das ist mir zu dumm und meine Zeit ist mir auch zu Schade.
Ach so: Und danke für die Views. So schnell, so viele Views ist ein neur Rekord.

 

[tom]

Offenbar keine Einsicht. Bitte nur noch Postings zum Thema des Threadstopics, sonst muss ich den Thread schliessen.

"Schnelle Sicherung v. großen Containern / Fast Backup with container of many files"

 

[Falk R.]

@floh8 du machst ja immer wieder sehr gute Tests, nur leider rutscht die Diskussion immer wieder ab, wenn nicht die richtigen Antworten kommen.

Eventuell ist auch einfach der Ansatz falsch. :duck:

Meine Meinung: Container sind super um Services getrennt vom Host mit geringem Overhead abzubilden. Ich würde nie "große" Container anlegen.
Fileservices sowie große Datenbanken kommen bei mir in VMs, da habe ich ganz andere Möglichkeiten mit dem Backup und die VMs kann ich im laufenden Betrieb migrieren.

Man muss auch den Aufwand sehen, für solche Anforderungen Code zu ändern und zu testen.

 

[floh8]

ja, danke für deinen post. natürlich ist dies so. vms haben viel mehr vorteile. migration, CDP möglich, großen Datenspeicher, aber darum geht es ja nicht in dem Thread, sondern eben darum, wie man am besten große container sichert, wenn man sich nunmal für container entschieden hat, wie peter das getan hat - aus welchen gründen auch immer. PRoxmox wirbt ja nicht damit, wenn sie wenig wollen, nehmen sie einen container, aber bei mehr musst du schon vms nehmen.
außerdem sorgt ja immer tom dafür, dass es wirklich in eine ganz andere richtgung geht. ich kritisiere natürlich auch mal die herangehensweise, weil sich ja die fehler in der kommunikation immer wieder hier wiederholen, obwohl schon öfter angemerkt.
Lies dir mal bitte den Austausch folgend durch, da liest man genau das, was ich nochmal hier kritisiere. nur ist dort wirklich ein Entwickler beteiligt.
https://bugzilla.proxmox.com/show_bug.cgi?id=3174
Ich kann auch aus erfahrung sagen, dass viele entwickler immer sehr schwer zugänglich sind, was ihre Arbeit und Kritik angeht. Ihnen fehlt manchmal die praktische Betrachtungsweise. Ein guter Projektkoordinator ist da gold wert.

 

[Falk R.]

Das Problem ist noch schwieriger. Der Programmierer hat den Code und Funktionsweisen im Kopf. Du kommst dann mit Funktionswünschen aus der Praxis. Diese Kommunikation ist bei jeder Software schwer, wenn du wirklich etwas willst, musst du versuchen dich auf den Entwickler einzulassen und wenn du seine Denkweise verstanden hast, kannst du ihn viel besser in deine gewünschte Richtung lenken.
Da der Ton die Musik macht und der Ton in den Threads nicht immer gut gewählt ist, kommt ihr nie auf einen Nenner.

Da eine Blockbasierte Sicherung nicht so einfach möglich ist, solltet ihr beide eventuell mal eure Gedanken schweifen lassen ob man nicht bei der Wahl des Unterbaus des Containers etwas machen kann um das Backup zu optimieren. Eventuell anderes FS oder so.

Gibt es eventuell ein Hostbasiertes Change Block Tracking, was man für Container missbrauchen könnte?

 

[floh8]

das ist offtopic...ich glaube ich schließe gleich den Thread...

 

[dcsapak]

Hi,

ich hab in meiner ersten Antwort versucht unsere Entscheidungen und die aktuelle Situation zu erklären, offenbar ist mir dies nicht gut gelungen, daher hier ein weiterer Versuch.

Wir sind uns bewusst, dass File-Backups mit großen Datenmengen (große Container, große Verzeichnisse) nicht so schnell sind wie manche andere Lösungen (Borg/Restic/etc.), zumindest bei den 'inkrementellen' Sicherungen.
Für dieses Problem haben wir aktuell noch keine gute und fertige Lösung, haben es aber nicht vergessen, und sobald wir etwas haben mit dem wir zufrieden sind, wird es ins Produkt eingepflegt. Das kann je nachdem leider dauern.

Es ist nicht möglich, die Vorgehensweise von Borg/Restic/etc. zu kopieren, da deren Konzept ein anderes ist und viele Dinge bei uns nicht funktionieren/skalieren. (Chunk-Blowup, Multi-Client, etc.)
Image Backup für Container ist aus unserer Sicht keine gute Wahl, einerseits aus Code-technischen Gründen, andererseits wegen fehlenden Features (Dirty-Bitmap).

Falls es unklare Dinge/Probleme gibt, bitte ich darum konkret zu fragen, dann fällt es uns am leichtesten zu antworten, da das ganze Thema ziemlich komplex ist.
Hier im Forum (und auch im Enterprise Support) sind die meisten Staff-Member direkt die Entwickler der Produkte (auch ich) und daher sind wir in der Lage das ganze aus dieser Sicht zu beurteilen.

 

[Falk R.]

Wir sind uns bewusst, dass File-Backups mit großen Datenmengen (große Container, große Verzeichnisse) nicht so schnell sind wie manche andere Lösungen (Borg/Restic/etc.), zumindest bei den 'inkrementellen' Sicherungen.
Für dieses Problem haben wir aktuell noch keine gute und fertige Lösung, ....

Hallo Dominik,

habt ihr euch mal angeschaut wie Veeam die Filebackups macht? Ich habe das System dahinter auch nicht verstanden, aber die Performance bei Inkrementellen Filesicherungen ist schon mega. Da die jeden Filer / NAS, whatever gleich behandeln, müsste das ja was portier oder adaptierbares sein. So zumindest meine Hoffnung.

Gruß Falk

 

[dcsapak]

Hi @SkyDiver79 ,

Ja wir wissen wie die meisten anderen Lösungen funktionieren (zumindest die öffentlich zugängliche Dokumentation, Veeam ist schließlich closed-source). Veeam verwendet im Gegensatz zu uns inkrementelle Backups, was manche Sachen, wie inkrementelle File-backups, viel einfacher macht. Leider funktionieren diese Ansätze von Veeam leider bei unseren deduplizierten Chunk-basierten Backups nicht.

EDIT: nur zur Erklärung: der PBS Client sendet die Daten auch inkrementell beim Backup, aber der resultierende Snapshot ist immer ein full (aber dedupliziertes) Backup. Bei Veeam sind die gespeicherten Backups selbst full oder Inkrementell.

 

[imadevel]

Hallo zusammen!

Zuerst einmal meinen Dank an Team und Community. Eine gewisse Emotionalität zeigt eine Verbundenheit auf beiden Seiten ;-) .

Der Threat ist zwar schon einige Wochen alt aber sicher noch nicht veraltet. Wir setzen bei uns die Proxmox-KVM-Virtualierung ein, primär allerdings VMs und keine Container, müssen aber auch "banale" Linux-Rechner sichern und haben hier angefangen, den PBS einzusetzen, nachdem wir bisher viel mittels rsync auf Backups synchronisiert haben.

Wir haben auch das im Threat angesprochene Problem von "zuviel Daten" auf den Platten: Auch wenn die Platen bmit 140M/s sichern ... bis da 10TB durch sind, dauert das ... zu lange. Daher meine Ideen hier.

a) ggf. kann die "Verlustentscheidung", also wenn Dateien nicht mit gesichert werden, dem Anwender überlassen werden. Wenn ich mir das Risiko bewusst bin, ein Risiko einzugehen, kann ich mich nachher auch nicht beschweren, wenn Dateien nicht mit gesichert werden. Ob man dann auf ctime, atime, inode-Nummer setzt, kommt sicher auf die Einstellungen des jeweiligen Systems ein (z. B. ein Mount mit noatime).

b) ist da dann natürlich die Problematik einer dateiübergreifenden Chunk-Zusammensetzung. Ich habe nun nicht in den Code geschaut, aber ich vermute, dass es da schon Spare-Platz oder Dateigrenzmarkierungen etc, geben wird, da ansonsten bei einer kleinen Dateilängenänderung über das ganze Archiv komplett neue Chunks generiert würden oder, alternativ, nicht die Dateien als Dateien, sondern die Blocks der Dateien gesichert werden. Gehe ich also in meinen folgenden Gedanken von einer solchen Lösung aus: Die bisherigen Daten der Sicherung liegen dann ja in den Chunks auf dem PBS vor. Statt nun die bestehende Datei zu lesen und ins Archiv einzubauen, den Hashwert zu berechnen, zum Server zu übertragen und den Chunk dann nicht mehr zu übertragen, weil sich nichts geändert hat, könnte man da nicht so vorgehen: Feststellen, dass sich eine Datei (angblich nach den fesgelegten Kriterien) nicht geändert hat, wenn der Bereich einen Chunk komplett betrifft, dem Server nur melden "nichts neues", wenn im jeweiligen Chunk mehr drin ist, als die eine Datei: Chunk vom Server laden, Teil der Datei aus dem Chunk nehmen (nicht von der Datei selbst, den die könnte sich ja faktisch entgegen der eigenen Annahme geändert haben und da habe ich lieber ein konsistentes Backup), die weiteren Dateien betrachten und weiter machen ...

Viele Grüße
Martin