Backup dauert lange - Backupstrategie hinterfragen

BigChris · May 26, 2024

Ich habe mir heute frisch meinen PBS aufgesetzt.

In meiner Konstellation zu Hause habe ich mich dazu entschieden, den PBS als VM auf meinem PVE laufen zu lassen. Einen Speicher binde ich über NFS von meinem Unraid-NAS ein. Mir ist bewusst, dass es bestimmt bessere Wege gibt, aber einen dritten Server wollte ich aktuell nicht dazu stellen.
Der PBS hat 4 Kerne auf einem i5 Prozessor der 9. Generation und 8GB Arbeitsspeicher bekommen. Die CPU Auslastung gerade liegt bei ca. 40%, Arbeitsspeicher bei 12%.

Ich habe meine LXCs und VMs gesichert, bei der letzten scheint es aber ewig zu dauern.
Dabei handelt es sich um eine VM mit openmediavault. An den openmediavault habe ich zwei Festplatten durchgereicht, welche ins Backup mit eingebunden werden. Eine ist mit ca. 400GB gefüllt, die zweite mit ca 300GB. Es handelt sich jeweils um 2TB Festplatten.

Das Backup läuft nun seit 7 Stunden ca. und ist gerade mal zu 17% (640GB) abgeschlossen.

Meine Fragen dazu:

ist es normal, dass das erste Backup so lange dauert?
Ich dachte, PBS würde nur die wirklich benutzen Daten der Festplatte kopieren, es steht nun aber etwas von 3,7TB in der Task Liste.
Ist es überhaupt sinnvoll auf diese Weise die openmediavault VM zu sichern?
Wenn ich die beiden Festplatten mit einem rsync auf das NAS synchronisiere, geht das bedeutend schneller und scheint weniger Daten zu brauchen, warum ist das so?
Sollte man die Datendisks evt. ausschließlich über rsync sichern? Ich dachte zwei verschiedene Wege wäre besser / sicherer.

Vielen Dank für Eure Hilfe!

Falk R. · May 26, 2024

BigChris said:
Ich habe meine LXCs und VMs gesichert, bei der letzten scheint es aber ewig zu dauern.
Dabei handelt es sich um eine VM mit openmediavault. An den openmediavault habe ich zwei Festplatten durchgereicht, welche ins Backup mit eingebunden werden. Eine ist mit ca. 400GB gefüllt, die zweite mit ca 300GB. Es handelt sich jeweils um 2TB Festplatten.

Das Backup läuft nun seit 7 Stunden ca. und ist gerade mal zu 17% (640GB) abgeschlossen.

Meine Fragen dazu:

ist es normal, dass das erste Backup so lange dauert?

Ja kann vorkommen, vor allem wenn du auf ein NFS schreibst.

BigChris said:
Ich dachte, PBS würde nur die wirklich benutzen Daten der Festplatte kopieren, es steht nun aber etwas von 3,7TB in der Task Liste.

Er zeigt immer die volle Diskgröße an, aber wenn du guckst wie schnell manche Blöcke verarbeitet werden, dann siehst du, dass er die leeren Blöcke überspringt.

BigChris said:
Ist es überhaupt sinnvoll auf diese Weise die openmediavault VM zu sichern?

Ja.

BigChris said:
Wenn ich die beiden Festplatten mit einem rsync auf das NAS synchronisiere, geht das bedeutend schneller und scheint weniger Daten zu brauchen, warum ist das so?

Weil der PBS Deduplizierung macht und ganz viele kleine Chunks schreibt und nicht einen Stream wie bei rsync.

BigChris said:
Sollte man die Datendisks evt. ausschließlich über rsync sichern? Ich dachte zwei verschiedene Wege wäre besser / sicherer.

Sicherer ist der PBS, aber er ist nun mal für die Nutzung von SSDs konzipiert worden. Die Inkrementellen Backups sind dann aber um ein vielfaches schneller.
Im Homelab kannst du mit der Performance einfach leben oder du machst es wie im Professionellen Umfeld und nutzt SSDs.

BigChris · May 26, 2024

Vielen Dank! Jetzt bin Ich schlauer und beruhigt

news · May 26, 2024

Noch als Ergänzung, Ich nutze den Proxmox VE und den Proxmox BS in einem LXC.
So kann ich den ZFS Pool, bzw. ein ZFS Dataset durchreichen.

Die beiden ZFS Pool sehen wie folgt aus:

Der RPool: ZFS Mirror mit 2x NVMe PCIe für den Proxmox VE.

Der Datenpool: ZFS Mirror 2x HDD 7200 RPM
-- 2x NVMe PCIe, ZFS Mirror special device
-- 2x NVMe PCIe, ZFS Mirror SIL/LOG und
-- 2x NVMe PCIe, ZFS stripe cache

Das sind alles die selben NVMe PCIe 4 x4, die über PCIe 3 x4 angebunden sind.
Das Partionslayout musste ich per Hand anlegen und entsprechend die Pools einrichten.

Der Server ist ein Intel Core I3 10105 mit 32 GB DDR4 Speicher auf einem B560 Board.

Mit dem Proxmox BS Durchsatz bei 2.5 GBit/s NIC bin ich sehr zufrieden.

Falk R. · May 27, 2024

news said:
Noch als Ergänzung, Ich nutze den Proxmox VE und den Proxmox BS in einem LXC.
So kann ich den ZFS Pool, bzw. ein ZFS Dataset durchreichen.

Die beiden ZFS Pool sehen wie folgt aus:

Der RPool: ZFS Mirror mit 2x NVMe PCIe für den Proxmox VE.

Der Datenpool: ZFS Mirror 2x HDD 7200 RPM
-- 2x NVMe PCIe, ZFS Raid1 special device
-- 2x NVMe PCIe, ZFS Mirror SIL/LOG und
-- 2x NVMe PCIe, ZFS stripe cache

Das sind alles die selben NVMe PCIe 4 x4, die über PCIe 3 x4 angebunden sind.
Das Partionslayout musste ich per Hand anlegen und entsprechend die Pools einrichten.

Der Server ist ein Intel Core I3 10105 mit 32 GB DDR4 Speicher auf einem B560 Board.

Mit dem Proxmox BS Durchsatz bei 2.5 GBit/s NIC bin ich sehr zufrieden.

Das Setup ist aber nicht ganz Standard und du hast am Ende des Tages aber trotzdem nur die Performance der HDDs, wenn die Daten nicht zum Cache passen.

news · May 27, 2024

Danke Falk R. für deinen Einwand.
Man beachte meine Aussage zu 2,5 GBit/s NIC und dem ZFS special device für die Meta Daten.

Das ZFS Layout wurde speziell für den Einsatz Proxmox BS angelegt.

Die HDDs liefern rund 440 GByte/s Leserate im besten Fall.
Geschrieben wird die ersten 5 Sekunden in den SIL/LOG und dann in nächsten Schritt weiter auf die HDDs.

UdoB · May 27, 2024

news said:
Das ZFS Layout wurde speziell für den Einsatz Proxmox BS angelegt.
Geschrieben wird die ersten 5 Sekunden in den SIL/LOG und dann in nächsten Schritt weiter auf die HDDs.

Damit ist das hier gemeint?

news said:
-- 2x NVMe PCIe, ZFS Mirror SIL/LOG und

Richtig ist natürlich, dass geschriebene Daten zunächst im ZIL landen, wo sie (maximal) 5 Sekunden lang in einer Transaction-Group (TXG) gesammelt werden. Dieses "Standard"-ZFS-Intention-Log befindet sich im RAM. Immer. Es ist also Non-Persistent, und damit verlustbehaftet, falls beispielsweise der Strom ausfällt.

Wenn man dem ZIL Persistenz spendieren möchte, weil dann auch SYNC-writes als "ist geschrieben" bestätigt werden, bevor sie auf den langsameren Datenplatten landen, kann man einen separaten ZIL auf physischen Datenträgern (SSD/NVMe) anlegen. Den nennt man dann SLOG.

Ich schreibe schon wieder viel zu viel, sorry, das wissen natürlich alle hier Lesenden längst. Ich möchte eigentlich nur gerne wissen, ob du einen Hinweis gefunden hast, ob/dass die ".chunks" des PBS per SYNC geschrieben werden.

Viele Grüße

BigChris · May 27, 2024

UdoB said:
Ich schreibe schon wieder viel zu viel, sorry, das wissen natürlich alle hier Lesenden längst

Nö, hier lesen auch Leute mit, die das nicht wissen. Ich freue mich regelmäßig über viel Input. Auch wenn ich nicht alles verstehe

UdoB · May 27, 2024

BigChris said:
Nö, hier lesen auch Leute mit, die das nicht wissen. Ich freue mich regelmäßig über viel Input. Auch wenn ich nicht alles verstehe

Ja, klar. Danke für die Aufmunterung!

Es ist nicht immer einfach, im richtigen Kontext eines konkreten Threads zu bleiben und nicht abzuschweifen. Und viele, viele Dinge wurden und werden ja auch immer wieder erneut erzählt...

news · May 27, 2024

Danke Udo B., ich lese eine Beiträge auch immer und finde sie immer angemessen und in die Tiefe gehend, gut.

Ich nehme es an, da ich den Proxmox BS mit allen seinen Funktionen auf einen ZFS Dataset am laufen habe:
RAM -> ZIL/ LOG -> HDD.

Wie ich in einem anderen Beitrag gelernt hatte, ist

Code:

zfs atime=on <dataset>

für den Proxmox BS notwendig.
Sonst schalte ich das immer für das Hauptdataset ab. Somit vererbt es die Eigenschaft an die weiteren Dataset.

Und dieses ZFS Layout ist eine Evolution über einige Generation Proxmox BS über meine Schaffensperiode.
Die Hardware ist nur in meinem Homelab, kleinen Betrieb im Einsatz und der Server wird nur im Backupfall gestartet.

Evtl. kann die YT level1techs oder die US Firma YT 45drives das zu 100% beantworten.

UdoB · May 27, 2024

news said:
Danke Udo B., ich lese eine Beiträge auch immer und finde sie immer angemessen und in die Tiefe gehend, gut.

Danke für die Blumen

news said:
RAM -> ZIL/ LOG -> HDD.

Ich habe gerade mal versucht, das Verhalten, insbesondere den potentiellen Nutzen eines SLOG, für mich experimentell zu klären. Das Folgende geschieht auf einem PVE mit PBS in einem Container. (Eines meiner Reserve-Systeme.) Der .chunk-Store ist hier ein Mount-Point, also direkt auf dem PVE angesiedelt. Der Pool besteht aus Blech ohne “Special Device”, das ist wirklich, wirklich langsam und dient hier explizit als schlechtes Beispiel.

man zpool-iostat zeigt wie man diverse Laufzeit-Informationen eines ZFS Pools beobachten kann.

Code:

     -q      Include active queue statistics.  Each priority queue has both pending (pend) and
             active (activ) I/O requests.  Pending requests are waiting to be issued to the disk,
             and active requests have been issued to disk and are waiting for completion.  These
             stats are broken out by priority queue:
             syncq_read/write   Current number of entries in synchronous priority queues.
             asyncq_read/write  Current number of entries in asynchronous priority queues.

Ein Backup einer VM (von einem anderen PVE per langsamen 1 GBit/s Netzwerk) mit frisch aus /dev/urandom generierten “Daten” erzeugt folgendes Bild:

Code:

~# zpool iostat rpool   -q 15
              capacity     operations     bandwidth    syncq_read    syncq_write   asyncq_read  asyncq_write   scrubq_read   trimq_write  rebuildq_write
pool        alloc   free   read  write   read  write   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ
----------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
rpool       14.7T  7.11T     14    439  60.0K   148M      0      0      0      5      0      0    156      9      0      0      0      0      0      0
rpool       14.7T  7.11T     13    529  52.8K   158M      0      0      0      0      0      0    419     40      0      0      0      0      0      0
rpool       14.7T  7.11T     11    533  47.5K   155M      0      1      0      0      0      0    280     40      0      0      0      0      0      0
rpool       14.7T  7.11T     11    490  44.8K   188M      0      1      0      0      0      0    238     40      0      0      0      0      0      0
rpool       14.7T  7.10T      9    544  36.8K   121M      0      0      0      0      0      0    300     27      0      0      0      0      0      0
rpool       14.7T  7.10T      8    556  33.9K   201M      0      0      0      0      0      0    296     40      0      0      0      0      0      0
rpool       14.7T  7.10T     10    531  70.7K   171M      0      0      0      0      0      0    488     40      0      0      0      0      0      0
rpool       14.7T  7.10T      6    617  27.5K   152M      0      0      0      0      0      0    294     37      0      0      0      0      0      0

Lediglich die "asyncq" wird genutzt. Es finden praktisch keinerlei SYNC-Schreibvorgänge statt. Auf dieser Maschine würde ein SLOG rein gar nix nützen.

Das ist allerdings nur ein einziger Datenpunkt, andere Konfigurationen mögen sich anders verhalten - YMMV...

Neobin · May 28, 2024

UdoB said:
Danke für die Blumen

Ich habe gerade mal versucht, das Verhalten, insbesondere den potentiellen Nutzen eines SLOG, für mich experimentell zu klären. Das Folgende geschieht auf einem PVE mit PBS in einem Container. (Eines meiner Reserve-Systeme.) Der .chunk-Store ist hier ein Mount-Point, also direkt auf dem PVE angesiedelt. Der Pool besteht aus Blech ohne “Special Device”, das ist wirklich, wirklich langsam und dient hier explizit als schlechtes Beispiel.

man zpool-iostat zeigt wie man diverse Laufzeit-Informationen eines ZFS Pools beobachten kann.

Code:

-q Include active queue statistics. Each priority queue has both pending (pend) and active (activ) I/O requests. Pending requests are waiting to be issued to the disk, and active requests have been issued to disk and are waiting for completion. These stats are broken out by priority queue: syncq_read/write Current number of entries in synchronous priority queues. asyncq_read/write Current number of entries in asynchronous priority queues.

Ein Backup einer VM (von einem anderen PVE per langsamen 1 GBit/s Netzwerk) mit frisch aus /dev/urandom generierten “Daten” erzeugt folgendes Bild:

Code:

~# zpool iostat rpool -q 15 capacity operations bandwidth syncq_read syncq_write asyncq_read asyncq_write scrubq_read trimq_write rebuildq_write pool alloc free read write read write pend activ pend activ pend activ pend activ pend activ pend activ pend activ ---------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- rpool 14.7T 7.11T 14 439 60.0K 148M 0 0 0 5 0 0 156 9 0 0 0 0 0 0 rpool 14.7T 7.11T 13 529 52.8K 158M 0 0 0 0 0 0 419 40 0 0 0 0 0 0 rpool 14.7T 7.11T 11 533 47.5K 155M 0 1 0 0 0 0 280 40 0 0 0 0 0 0 rpool 14.7T 7.11T 11 490 44.8K 188M 0 1 0 0 0 0 238 40 0 0 0 0 0 0 rpool 14.7T 7.10T 9 544 36.8K 121M 0 0 0 0 0 0 300 27 0 0 0 0 0 0 rpool 14.7T 7.10T 8 556 33.9K 201M 0 0 0 0 0 0 296 40 0 0 0 0 0 0 rpool 14.7T 7.10T 10 531 70.7K 171M 0 0 0 0 0 0 488 40 0 0 0 0 0 0 rpool 14.7T 7.10T 6 617 27.5K 152M 0 0 0 0 0 0 294 37 0 0 0 0 0 0

Lediglich die "asyncq" wird genutzt. Es finden praktisch keinerlei SYNC-Schreibvorgänge statt. Auf dieser Maschine würde ein SLOG rein gar nix nützen.

Das ist allerdings nur ein einziger Datenpunkt, andere Konfigurationen mögen sich anders verhalten - YMMV...

Man könnte das Ganze nochmal mit: sync-level=file testen; wenn man die Muse dazu hat...

:
https://pbs.proxmox.com/docs/storage.html#tuning ("sync-level" -> "file")

UdoB · May 28, 2024

Neobin said:
Man könnte das Ganze nochmal mit: sync-level=file testen; wenn man die Muse dazu hat...

Könnte man. Das ganze kann natürlich nur langsamer werden, aber gut, aus Interesse am Detail:

Innerhalb einer Test-VM --> 30 GB frische Zufallsdaten:

Code:

root@debian:/fio# dd if=/dev/urandom bs=1M count=30000 of=30gb.urandom status=progress

Auf dem PBS:

Code:

root@pbsc:~# proxmox-backup-manager datastore update pbsc --tuning 'sync-level=file'

Im Cluster: triggern eines manuellen Backups der Test-VM.

Auf dem PBS-Host-Node:

Code:

root@pvec:~# zpool iostat rpool   -q 10

              capacity     operations     bandwidth    syncq_read    syncq_write   asyncq_read  asyncq_write   scrubq_read   trimq_write  rebuildq_write
pool        alloc   free   read  write   read  write   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ
----------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
rpool       14.7T  7.11T     13    604   175K   192M      0      1      0      0      0      0    361     34      0      0      0      0      0      0
rpool       14.7T  7.10T      1    743  6.80K   145M      0      0      0      0      0      0    422     40      0      0      0      0      0      0
rpool       14.7T  7.10T      1    664  18.4K   116M      0      0      0      0      0      0    292     34      0      0      0      0      0      0
rpool       14.7T  7.10T     11    622   172K   208M      0      0      0      0      0      0    331     39      0      0      0      0      0      0
rpool       14.7T  7.10T      3    661  13.6K   232M      0      0      0      0      0      0    339     40      0      0      0      0      0      0
rpool       14.7T  7.10T      1    641  4.80K   155M      0      0      0      0      0      0    368     40      0      0      0      0      0      0
rpool       14.7T  7.10T     12    525  67.2K  83.6M      0      3      0      0      0      0    466     40      0      0      0      0      0      0

Das entspricht nicht meiner Erwartung. Entweder meine Messmethode ist falsch, oder ich habe “sync-level=file” trotz Dokumentation lesen falsch verstanden. Das ist offenbar alles weiterhin asyncron.

Host-Node: der .chunk-Store des PBS-LXC ist ein normaler Dataset, dem kann ich ebenfalls “sync” aufzwingen:

Code:

root@pvec:~# zfs set sync=always  rpool/data/subvol-2004-disk-1

Ich sehe nach kurzem schnellen Start eine drastische Verlangsamung, und zwar auf nur noch 14 MB/s. Das scheint mir realistisch für Blech mit mehreren Kopfbewegungen pro Schreibvorgang. Eventuell schlägt zusätzlich der ZFS-Slowdown-Mechanismus zu. Ein guter Artikel dazu war hier vor kurzem verlinkt, natürlich finde ich den Link nicht wieder. (In der Tabelle stehen 30 MB/s. Wenn das die Parity enthält, sollten es 42 sein, die Basis ist ein RaidZ2. Merkwürdig...)

Code:

              capacity     operations     bandwidth    syncq_read    syncq_write   asyncq_read  asyncq_write   scrubq_read   trimq_write  rebuildq_write
pool        alloc   free   read  write   read  write   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ   pend  activ
----------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
rpool       14.7T  7.09T      0    343  2.40K  31.2M      0      0      0      4      0      0    380      8      0      0      0      0      0      0
rpool       14.7T  7.09T      0    355  11.2K  29.4M      0      0      0      4      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    353  4.40K  31.4M      0      0      0      3      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    348  12.4K  30.9M      0      0      0      1      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    362  10.4K  31.5M      0      0      0      2      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    350  5.60K  31.7M      0      0      0      2      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    350  14.8K  30.6M      0      0      0      3      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    342  4.80K  29.5M      0      0      9     30      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    349  4.80K  33.2M      0      0      8     27      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    345  8.40K  30.6M      0      0      0      4      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    356  4.40K  31.5M      0      0      7     22      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    371    409  32.8M      0      0      0     14      0      0     53      8      0      0      0      0      0      0
rpool       14.7T  7.09T      0    353  2.40K  30.0M      0      0      0      4      0      0     16      4      0      0      0      0      0      0
rpool       14.7T  7.09T      0    355  8.40K  30.2M      0      0      8     32      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    344  6.00K  31.3M      0      0      0      1      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    347  11.6K  30.6M      0      0      0      5      0      0      4      2      0      0      0      0      0      0
rpool       14.7T  7.09T      0    361  19.2K  31.1M      0      0      0      8      0      0      0      0      0      0      0      0      0      0
rpool       14.7T  7.09T      0    347  11.2K  30.7M      0      0      0      5      0      0      4      2      0      0      0      0      0      0
rpool       14.7T  7.09T      0    353  6.40K  31.3M      0      0      0      5      0      0      7      2      0      0      0      0      0      0
rpool       14.7T  7.09T      0    353  7.60K  30.2M      0      0     35     40      0      0     26      2      0      0      0      0      0      0
rpool       14.7T  7.09T      0    366  7.60K  30.5M      0      0      0      5      0      0    138      8      0      0      0      0      0      0

Ich hätte in “syncq_write” mehr “pending” erwartet. Aber natürlich darf diese Queue nicht lang werden, denn dann wäre ja genau der SYNC-Aspekt nicht mehr gewährleistet. Wo die relativ vielen "async"-Vorgänge herkommen, ist mir unklar. Ich habe natürlich dafür gesorgt, dass keine anderen Prozesse laufen. Denke ich.

Wenig überraschende Resultate:

PBS schreibt per Default asyncron
warum "sync-level=file” keinen Effekt zeigt, ist mir unklar
Blech ist langsam ;-)

----
FTR: aufräumen, wieder sync=standard

Code:

root@pvec:~# zfs set sync=standard  rpool/data/subvol-2004-disk-1

Wo landete eigentlich “sync-level=file”? Ach dort - manuell editierbar:

Code:

root@pbsc:~# vi /etc/proxmox-backup/datastore.cfg

Sonst noch Wünsche? ;-)

fabian · May 28, 2024

sh. doku - sync level file heisst nicht dass das file selbst sync geschrieben wird, sondern nur dass pro file (chunk) das geschrieben wird am ende ein fsync gemacht wird. O_SYNC wuerde bedeuten, jeder einzelne write wird so behandelt als waere direkt danach ein fsync. der default ist am ende des backup erstellens einmal das ganze file system rauszuflushen, das kann aber im bezug auf crash consistency nachteile bringen, deswegen ists konfigurierbar.

UdoB · May 28, 2024

fabian said:
sync level file heisst nicht dass das file selbst sync geschrieben wird, sondern nur dass pro file (chunk) das geschrieben wird am ende ein fsync gemacht wird.

Danke für die Erläuterung! Das ganze ist... schwierig, auf dieser Ebene treibt mal sich als Otto-Normaladmin ja selten herum.

Also kann ich sagen: das meiste wird auch mit "sync-level=file" asyncron geschrieben, aber die Häufigkeit der "fsync"-Aufrufe ist innerhalb eines Tasks höher als mit "filesystem (default)" --> einmal pro "fertigem" Chunk gegenüber einmal pro Task. Beim vierten mal durchdenken macht dann die Tabelle und die sehr kurze "syncq_write"-pending-Queue für mich wieder Sinn

Hier geht es nur um das Verständnis. Ursprünglich wollten wir (bzw. der OP bzw. @news ) ja die Performance optimieren...

Neobin · May 28, 2024

Danke fürs Testen, @UdoB und Aufklären, @fabian.

Search

Search

Backup dauert lange - Backupstrategie hinterfragen

BigChris

Member

Falk R.

Famous Member

BigChris

Member

news

Active Member

Falk R.

Famous Member

news

Active Member

UdoB

Famous Member

BigChris

Member

UdoB

Famous Member

news

Active Member

UdoB

Famous Member

Neobin

Distinguished Member

UdoB

Famous Member

fabian

Proxmox Staff Member

UdoB

Famous Member

Neobin

Distinguished Member