PBS und entfernbare Datastores

[JensF]

Endlich kam ich mal dazu, die neue Funktion der entfernbaren Datastores zu testen, aber so ganz funktioniert das nicht so wie erwartet.
Beim Hinzufügen das Datastores kann man ja auswählen, dass man den bereits existierenden Datastore wieder verwenden will (was schon mal sehr nice ist!) und dass es sich um einen entfernbaren Datastore handelt.

Wie man hier auch schön sehen kann, kann man das RDX Laufwerk mit /dev/sdb1 auswählen.
Allerdings speichert der PBS als backing-device die UUID der einzelnen RDX-HDD in der datastore.cfg ab und nicht /dev/sdb1!
Beim Wechsel der RDX Kassette ändert sich aber diese UUID und der PBS kann den Datastore dann nicht mehr mounten.
Lässt sich das umstellen? Ich brauche da zwingend /dev/sdb1.
Ich will ja nicht für jede einzelne RDX Kassette einen eigenen Datastore anlegen.

 

[Hannes Laimer]

Hey,

nein. Es geht um das Gerät welches den Datastore enthält, wenn du zwei Geräte hast dann gibt es auch mindestens zwei Datastores. Ein Gerät kann mehrere Datastores enthalten, aber ein Datastore ist auf genau einem Gerät.

 

[JensF]

Hallo Hannes, vielen Dank für Deine Antwort.
Dann hat das Feature für mich, in Verwendung mit RDX, keinen Sinn und ich bleib bei meiner "manuellen" Lösung.

 

[Falk R.]

Hallo Hannes, vielen Dank für Deine Antwort.
Dann hat das Feature für mich, in Verwendung mit RDX, keinen Sinn und ich bleib bei meiner "manuellen" Lösung.

Dann hast du aber ein logisches Problem in deinem Konstrukt. Bei einer Tape Library inventarisierst du auch jedes Tape und nicht das Laufwerk ist immer das gleiche "Device". Dann weißt du auch nicht was auf welchem tape ist. So auch bei deinen RDX.
Klar kann man sich das alles Manuell notieren, aber schöner ist es, wenn dir die Software beim Restore anzeigen kann, welches Medium benötigt wird.

 

[JensF]

Viel einfacher Falk.
Auf jeden der 3 RDX-HDDs ist der gleiche Datastore mit der gleichen Anzahl (3) an Backups, nur mit unterschiedlichen Tagen.
Zur Verdeutlichung bei täglichen Wechsel:
RDX1: Mo, Do, Di
RDX2: Di, Fr, Mi
RDX3: Mi, Mo, Do
Dann beginnt das ganze wieder von vorne mit RDX1 und immer so weiter.
Als Disaster Recovery vollkommen ausreichend.
Edit: die Tage angepasst.

 

[Falk R.]

Kann man natürlich so machen. Bei 3 RDX geht das natürlich, aber das skaliert nicht ernsthaft, wenn man deutlich mehr Medien hat. Bei 3 RDX hätte ich auch kein Problem, die als 3 Datastores anzulegen. Bei dem Setup ist es etwas Geschmacksfrage, aber generell sollte eine Lösung skalieren können. Zumindestens meine Meinung.

 

[JensF]

Wie machst Du dann den Sync mit 3 Datastores? Legst 3 Syncs an, syncst zur gleichen Zeit und ignorierst die 2 die fehlschlagen?

 

[Falk R.]

Wie machst Du dann den Sync mit 3 Datastores? Legst 3 Syncs an, syncst zur gleichen Zeit und ignorierst die 2 die fehlschlagen?

Ich habe das Feature noch nicht getestet, aber entweder du baust 3 Sync Jobs, die jeweils zu den Tagen laufen, wo die RDX stecken. Also keine Fehler produzieren und ignorieren.
Eventuell kann man das ja genau so bauen wie mit Tapes. im Moment komm ich aber nicht zum testen von so etwas.

 

[JensF]

die jeweils zu den Tagen laufen, wo die RDX stecken

Und das ist schon wieder zusätzlicher Aufwand und müsste geprüft werden.
Muss ja nur derjenige, der die Kassetten wechselt, krank werden oder es mal vergessen haben und schon läuft gar kein Sync mehr, weil die Tage nicht mehr zum eingelegten RDX passen...
Baut man für jedes Tape einen eigenen Datastore? Finde ich ja sehr umständlich ehrlich gesagt.

 

[Falk R.]

Und das ist schon wieder zusätzlicher Aufwand und müsste geprüft werden.
Muss ja nur derjenige, der die Kassetten wechselt, krank werden oder es mal vergessen haben und schon läuft gar kein Sync mehr, weil die Tage nicht mehr zum eingelegten RDX passen...
Baut man für jedes Tape einen eigenen Datastore? Finde ich ja sehr umständlich ehrlich gesagt.

Tape funktioniert etwas anders. So eine Medienpool Verwaltung wie bei Tape für RDX wäre dann sinnvoll. Ich bin eh kein Freund vonn all den Manuellen Medien wie Tape oder RDX. Tape ist gut für Archive, aber nicht mehr für Backup. Ich habe bei mir zuhause sowie bei allen Kunden nur noch Syncs zu entfernten PBS. Mal in einem anderen Raum, mal anderer Standort und auch mal bei einem Hoster.

 

[Johannes S]

Und das ist schon wieder zusätzlicher Aufwand und müsste geprüft werden.
Muss ja nur derjenige, der die Kassetten wechselt, krank werden oder es mal vergessen haben und schon läuft gar kein Sync mehr, weil die Tage nicht mehr zum eingelegten RDX passen...

Das ist ja das grundsätzliche Problem von solchen manuellen Medien. Man kann das versuchen auf Prozessebene aufzufangen, aber auch das kann nie ganz vor menschlichen Versagen schützen, sondern es nur unwahrscheinlicher machen. Wenn man z.B. als Regel festlegt, dass die Frühschicht jeden Tag ein neues Tape einlegen muss, ist es deutlich wahrscheinlicher, dass es nicht vergessen wird. Aber wenn alle Leute ausfallen, hilft das nicht. Und wenn es doch mal jemand vergisst, auch nicht. Genau dann würde ich aber alamiert werden wollen, gerade wenn ich selbst der Mensch bin, der es vergessen könnte, weil sonst keiner die Tapes/RDX wechselt

 

[JensF]

Wenn kein Sync gelaufen ist gibt's ja den Alert per Mail. Das ist ja auch kein Problem.
Wenn am nächsten Tag dann wieder irgendeine Kassette eingelegt wird, geht's ganz normal weiter.
Ohne das irgendjemand irgendwas anpassen/umstellen muss.

 

[t.holzem@stiftung-waldhei]

Endlich kam ich mal dazu, die neue Funktion der entfernbaren Datastores zu testen, aber so ganz funktioniert das nicht so wie erwartet.
Beim Hinzufügen das Datastores kann man ja auswählen, dass man den bereits existierenden Datastore wieder verwenden will (was schon mal sehr nice ist!) und dass es sich um einen entfernbaren Datastore handelt.
View attachment 78843
Wie man hier auch schön sehen kann, kann man das RDX Laufwerk mit /dev/sdb1 auswählen.
Allerdings speichert der PBS als backing-device die UUID der einzelnen RDX-HDD in der datastore.cfg ab und nicht /dev/sdb1!
Beim Wechsel der RDX Kassette ändert sich aber diese UUID und der PBS kann den Datastore dann nicht mehr mounten.
Lässt sich das umstellen? Ich brauche da zwingend /dev/sdb1.
Ich will ja nicht für jede einzelne RDX Kassette einen eigenen Datastore anlegen.

Guten Morgen Jens,

wie bist du zu der Funktion der entfernbaren Datastores gekommen?
Bei uns gibt es diese nicht.

Beste Grüße

 

[fabian]

Guten Morgen Jens,

wie bist du zu der Funktion der entfernbaren Datastores gekommen?
Bei uns gibt es diese nicht.

Beste Grüße

ist neu seit PBS 3.3 (und dafuer gedacht, neue datastores auf "entfernbaren" medien (externe festplatten oder der gleichen) anzulegen - um bestehende zu uebersiedeln am besteln dann die eingebaute sync function verwenden)

 

[JensF]

Die Funktion mit dem Removable Datastores ist ja wirklich sexy und ich hab mir wieder meine eigene Lösung dafür gebastelt. Nur hab ich jetzt wieder die gleichen Benachrichtigungen im Log wie vorher, wenn der Store nicht gemountet ist:

Dec 11 11:30:00 pbs2 proxmox-backup-proxy[6519]: lookup_datastore failed - datastore 'RDX' is not mounted
Dec 11 11:31:00 pbs2 proxmox-backup-proxy[6519]: lookup_datastore failed - datastore 'RDX' is not mounted
Dec 11 11:32:00 pbs2 proxmox-backup-proxy[6519]: lookup_datastore failed - datastore 'RDX' is not mounted
Dec 11 11:33:00 pbs2 proxmox-backup-proxy[6519]: lookup_datastore failed - datastore 'RDX' is not mounted

Lässt sich das noch abschalten?

 

[Hannes Laimer]

Das kommt von der UI, also die fragt nach und das führt zu diesen Meldungen. Generell gibt es zu dem "Sync bei mount ausführen" Thema ein Issue (und auch schon einen ersten Patch) auf Bugzilla[1]. Wie du das vorhin beschrieben hast, sollte das eigentlich dein Problem lösen.

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=5964

 

[JensF]

Sync-on-mount ist auch ein nice to have! Aber das löst ja nicht das Problem mit den Messages im SysLog, oder übersehe ich da was?
Ich meine die UI muss doch nicht jede Minute nach den Store suchen, wenn ich diesen in der UI selbst unmounte.

 

[Hannes Laimer]

Hab das nicht ganz eindeutig formuliert.

Muss ja nur derjenige, der die Kassetten wechselt, krank werden oder es mal vergessen haben und schon läuft gar kein Sync mehr, weil die Tage nicht mehr zum eingelegten RDX passen...

ich meinte das hier, also es wird genau dann gesynct wenn eingelegt wird. Es gibt dann keinen fixen "Zeitplan".

 

[JensF]

Hab das nicht ganz eindeutig formuliert.

ich meinte das hier, also es wird genau dann gesynct wenn eingelegt wird. Es gibt dann keinen fixen "Zeitplan".

Ach so, nein. Das ist kein Thema mehr. Mein Pool aus RDX-HDDs funktioniert jetzt genau so wie es soll, als entfernbarer Datastore und synct zur passenden Uhrzeit.
Ich bekomme nur wieder die SysLog-Messages mit nicht gemounteten Datastore.

 

[JensF]

Ich stelle mir gerade vor, ich hätte pro RDX-HDD einen Datastore angelegt. Dann bekäme ich ja jede Minute mindestens zwei mal die Meldung, dass Storages nicht gemountet sind! Tagsüber, wenn ich keine RDX gemountet habe um einfach wechseln zu können, dann drei unnötige Meldungen pro Minute...
Ich hoffe, da wird noch dran gearbeitet!