SMB Chunkstore und Rechte

[beta]

Moin,

ja SMB ist nicht die beste Lösung für PBS. Aber PVE wird ja auch übers Netz gesichert, sonst wäre es ja ein zentrales Backup.
Schön wäre also eine GUI Lösung für CIFS/NFS. Davon abgesehen ...

Ich versuche gerade den PBS einzurichten stoße aber auf ein paar Probleme:

1. Wenn ich einen Datastore anlege werden ca. 65500 Ordner erstellt. Hat das einen bestimmten Grund? Warum zig tausend Ordner?
Es dauert fast 30 Minuten bis die Ordner erstellt sind. So etwas habe ich im Bereich Backup noch nie gesehen.

2. Nach dem Erstellen das Datasore wird wegen Zugriffsrechten gemeckert: OS Error 13.
Ich habe hier schon unterschiedliche Ansätze durch uid und gid gelesen, nachvollziehen kann ich das aber nicht.
PBS legt ja auch die Ordner an, warum sollte er dann also keine Rechte haben darauf zuzugreifen?

 

[dcsapak]

1. Wenn ich einen Datastore anlege werden ca. 65500 Ordner erstellt. Hat das einen bestimmten Grund? Warum zig tausend Ordner?
Es dauert fast 30 Minuten bis die Ordner erstellt sind. So etwas habe ich im Bereich Backup noch nie gesehen.

die directories werden preallocated damit jedesmal beim chunk speichern nicht noch zusätzlich das checken ob directory erstellt ist + erstellen dazu kommt
alle chunks in ein directory zu packen ist nicht gut, da filesysteme normalerweise nicht gut skalieren damit, dh die ersten 4 characters vom chunk namen werden zu ordnern

hier auf einem lokalen ext4 dauert das erstellen keine 10s, warum das bei dem smb share solange dauert kann ich nicht genau sagen
(smb/nfs ist übrigens genau wegen solchen performance problemchen nicht wirklich empfohlen)

2. Nach dem Erstellen das Datasore wird wegen Zugriffsrechten gemeckert: OS Error 13.
Ich habe hier schon unterschiedliche Ansätze durch uid und gid gelesen, nachvollziehen kann ich das aber nicht.
PBS legt ja auch die Ordner an, warum sollte er dann also keine Rechte haben darauf zuzugreifen?

wie lautet die exakte fehlermeldung? je nachdem kann es auch sein dass zb ein .lock file im top level ordner nicht angelegt werden darf (oder locking überhaupt nicht geht)

 

[beta]

Hmmm ... das Directorys vorher angelegt werden ist ja noch verständlich, aber 65500?
Die SMB Freigabe ist auf dem selben PC in einer VM mit HDD Paththrough.
Etwas kompliziert, aber die SMB Freigabe dient halt auch für File-Backups.
Die VM's wollte ich jetzt einfach auch darauf sichern. Biher mache ich das direkt aus PVE auf die Freigabe.
Wenn das über PBS zu lange dauert oder zu viele Umwege genommen werden, dann wir das evtl. auch so bleiben.
In der GUI stand "os error 13".
Ein .lock wurde angelegt genau wie die Ordner.
Desahlb finde ich es ja merkwürdig, die Schreibrechte funktionieren ja.

 

[Falk R.]

Wenn du unbedingt ein langsames NAS mit SMB oder NFS nutzen möchtest, mach doch einfach die PVE eingebauten VZDump Backups.
Ich fahre meine Backups alle auf einer SSD. Für meine 370GB Echtdaten habe ich auf dem PBS nur 227GB verbraucht bei derzeit 142 Snapshots.
Dedupfaktor 1:40.
Da der PBS sehr effektiv schreibt, lieber kleinere aber schnelle Disks oder SSDs nutzen.

 

[beta]

So richtig viele Vorteile bietet PBS ja auch nicht. Zumindest nicht für mich.
Den Einzelfilezugriff find ich noch nett, aber Pull Backups gehen vom PVE ja leider auch nicht.
Ich muss mal überlegen, ob ich die HDD partitioniere und mir doch was für PBS HDD Paththrougt durchreiche.
Das hätte aber den Nachteil, dass ich das Backupsvolume nie ganz nutzen kann und ich auch nicht von überall auf die Backups per SMB zugreifen kann.
Ich habe irgendwie immer ein schlechtes Gefühl nicht per SMB auf Backup Files direkt zugreifen zu können.
Wobei das für VMs ja nicht so schlimm wäre wie für meine privaten Files.

 

[dcsapak]

Hmmm ... das Directorys vorher angelegt werden ist ja noch verständlich, aber 65500?

wurde so gewählt da es zukunftssicher ist (auch für große datastores) und eigentlich gut performt (auch beim anlegen). ich würde sagen dass das order anlegen solange dauert is eher die ausnahme...

EDIT: hab zu früh abgesendet:

Wenn das über PBS zu lange dauert oder zu viele Umwege genommen werden, dann wir das evtl. auch so bleiben.
In der GUI stand "os error 13".

was sagt denn das pbs journal dazu währenddessen?

Ich habe irgendwie immer ein schlechtes Gefühl nicht per SMB auf Backup Files direkt zugreifen zu können.

nur zur info: ohne pbs kommt man an den inhalt der backups nicht so leicht ran, da die daten gechunkt und dedupliziert werden

 

[Dunuin]

So richtig viele Vorteile bietet PBS ja auch nicht. Zumindest nicht für mich.

- Deduplizierung also viel platzsparender (hier z.B. 3444 GiB an Backups die nur reale 61 GiB an Platz brauchen), also mehr Revisionen möglich zu behalten. Ich habe da ein deutlich besseres Sicherheitsgefühl wenn ich auf die Backups der letzen paar Jahre zugreifen kann, anstatt nur auf die Backups der letzten paar Tage.
- erlaubt inkrementelle Backups also sind die Backups viel schneller durch, da nur das gesichert werden muss, was sich seit dem letzten Backup geändert hat
- verschlüsselte Backups
- Datenintegritätsprüfung auf Softwäre-Ebene, was nützlich ist, wenn man z.B. kein ZFS als Dateisystem benutzen kann
- ...

wurde so gewählt da es zukunftssicher ist (auch für große datastores) und eigentlich gut performt (auch beim anlegen). ich würde sagen dass das order anlegen solange dauert is eher die ausnahme...

Problem wird eher die HDD hinter dem SMB sein. PBS auf HDD ist eh schon echt nicht toll. SMB/NFS dazwischen macht es dann halt noch schlimmer.

 

[Falk R.]

Ich habe irgendwie immer ein schlechtes Gefühl nicht per SMB auf Backup Files direkt zugreifen zu können.
Wobei das für VMs ja nicht so schlimm wäre wie für meine privaten Files.

Dann sind die VZDumps besser für dich geeignet, da kannst du rein gucken.

 

[beta]

Ich bin da jetzt echt nicht schlüssig.
Hat Vor- und Nachteile.
Deduplizierung hört sich schon nicht schlecht an.
Braucht das nur weniger Platz oder schickt PVE auch weniger Daten übers Netz (würde dann ja auch schneller gehen)?
Theoretisch kann ich PBS ja auch parallel zu PVE installieren, was einen Umweg über eine VM spart.
Vielleicht bringt NFS auch nochmal Geschwindigkeitvorteile zu SMB?

 

[Dunuin]

Ich bin da jetzt echt nicht schlüssig.
Hat Vor- und Nachteile.
Deduplizierung hört sich schon nicht schlecht an.
Braucht das nur weniger Platz oder schickt PVE auch weniger Daten übers Netz (würde dann ja auch schneller gehen)?

Alles was an Daten eingespart wird muss auch nicht übers Netz geschickt werden. Hast du ein 100GB Backup bei dem sich nur 100MB geändert haben, dann müssen auch nur die 100MB gesichert und zum PBS geschickt werden, anstatt da wie beim Vzdump immer die vollen 100GB erneut und erneut speichern zu müssen.

Theoretisch kann ich PBS ja auch parallel zu PVE installieren, was einen Umweg über eine VM spart.
Vielleicht bringt NFS auch nochmal Geschwindigkeitvorteile zu SMB?

Hauptproblem wird wie gesagt die HDD sein. PBS speichert wegen Deduplizierung alles als Millionen von kleinen Chunk Dateien von max 4MB Größe. Meistens sind die Chunks eher so ca 2MB. Speicherst du da eine 1000 GB virtuelle Qcow2-Disk, dann schreibt da PBS nicht sequentiell eine 1000GB Datei, sondern es werden 500.000x 2MB Chunk-Dateien geschrieben die dann in die 65535 Ordner einsortiert werden. Du hast also viele kleine IO und die sind eher random als sequentiell. Sprich du brauchst IOPS Performance und da sind HDDs schrecklich, wenn da eine typische HDD so 100 IOPS schafft und eine gute SSD auch mal 1 Mio IOPS und mehr.

 

[beta]

Hmm .. OK.
Schade, es scheint ja alles über diese mini Chunks zu laufen.
Für eine HDD ja weniger optimal, für eine SSD egal ob es viele kleine Files oder ein paar Große sind?
Die Schreibzyklen sind ja auch bei einer SSD begrenzt.
Auf eine SSD als Backup wäre ich bei den Preisen und Kapazitäten aber auch nicht gekommen.
Zumindest nicht in Kombination mit einem Filebackup.
Mit einer HDD bin ich da wohl raus und es wird wohl doch wieder ein Vzdump.
Danke an alle für Aufklärung und Hilfe.

 

[Falk R.]

Eine direkt angeschlossene HDD mit ZFS ist OK für das Backup zuhause.
Für Backups kann man auch eine QLC SSD nehmen, es wird ja nur einmal beim Backup drauf geschrieben.

 

[Dunuin]

HDD geht schon für zuhause, man darf nur keine guten Geschwindigkeiten erwarten und die HDD sollte für nichts anderes da sein als PBS Backups. Mein Raidz1 aus 4 HDDs ohne SSDs als Special Device braucht über NFS z.B. bei 1TB an Daten gute 4-6 Stunden für ein GC Job, wo dann die HDDs für diese Zeit bis ans Limit ausgelastet und damit für nichts anderes nutzbar sind. Der andere Server mit Raidz1 aus 4 HDDs + 2 SSDs als Special Device über NFS macht die gleichen 1TB an Daten beim GC Job in wenigen Minuten.

 

[beta]

Das ist schon ein riesiger Unterschied.
Bei ZFS bin ich raus.
Dafür reicht der RAM weder beim Heim-Hauptserver (16GB) noch beim Backupserver (8GB).
Aber als Backupserver Nachts und tagsüber als HTPC schon eine schöne Sache.
Wenn ich das vorher gewusst hätte, wäre meine SSD wahrscheinlich deutlich größer ausgefallen und die Backups wäre direkt mit auf der SSD gewesen.

 

[beta]

Kann man auch 2 Partitionen einer HDD an 2 VMs durchreichen, oder geht immer nur die ganze Platte?

 

[Dunuin]

Kann man auch 2 Partitionen einer HDD an 2 VMs durchreichen, oder geht immer nur die ganze Platte?

Wenn ich mich recht erinnere hat Linux da kein Problem mit, aber Windows weigert sich mit durchgereichten Partitionen zu arbeiten. Am besten selbst mal testen.

 

[beta]

OK, als Datastorage bereiten die 2 Partitionen aktuell für OMV und PBS wohl keine Probleme.
Wobei ich die Partition für PBS unformatiert lassen musste, damit PBS selbst ein Ext4 Dateisystem anlegen konnte.
Die Geschwindigeit im Gegensatz zu einer SMB Freigabe ist doch wirklich groß. Die Chunks wurden jetzt innerhalb von ein paar Sekunden angelegt.