Hallo, guten Tag!
Ich bin ganz großer Fan von PBS und möchte nun mein externes
Standalone Bandlaufwerk "HP ULTRIUM 5-SCSI" (HP-Typ: EH958B)
mit PBS zum Laufen bringen.
Das Laufwerk wird erkannt und das Schreiben von Backups
funktioniert auch problemlos. Beim Restore tritt allerdings
ein Fehler auf, den ich mir noch nicht so richtig erklären
kann.
Testszenario: ich habe ein beschriebenes Band mit
ca. 100 GByte VM-Images. Nun möchte ich ein einzelnes
VM-Image vom Band holen. Dazu lösche ich ein VM-Image von der
lokalen Festplatte und versuche dann einen Restore vom Band.
Während des Restores wird versucht, das passende File auf
dem Band anzufahren, z.B. File Nummer 178. Intern wird
dann quasi der Befehl "pmt asf 178" an das Laufwerk geschickt.
Leider ist bei meinem Laufwerk immer das Resultat, dass
ein Filemark vorher positioniert wird, also in diesem Fall 177.
So sieht das dann im Restore-Log aus:
An Position 177 ist natürlich ein falscher File-Typ, das ganze bricht also ab.
Das scheint wirklich ein Problem mit dem SCSI-Befehl LOCATE(16) zu sein.
Ich habe das auch mit anderer Software getestet. Das Laufwerk
positioniert immer ein File vorher.
Mache ich da irgendwas falsch? Hat jemand auch so ein Laufwerk und kann
den Bug nachvollziehen?
Die Firmwareversion des Laufwerks ist jedenfalls die neueste (Z6ED), und
ich wusste mir jetzt nicht anders zu helfen, als einen Patch für PBS zu basteln.
Hier wird einfach nach dem LOCATE-Befehl nochmal geguckt, ob ich genau ein
File zurück liege und dann bewege ich das Band einfach ein File nach vorne:
Das Ergebnis sieht dann so aus, es funktioniert prima:
Gibt es solche Probleme mit File Marks oder habe ich einfach nur ein kaputtes Gerät?
Bis denn,
Michael
Ich bin ganz großer Fan von PBS und möchte nun mein externes
Standalone Bandlaufwerk "HP ULTRIUM 5-SCSI" (HP-Typ: EH958B)
mit PBS zum Laufen bringen.
Das Laufwerk wird erkannt und das Schreiben von Backups
funktioniert auch problemlos. Beim Restore tritt allerdings
ein Fehler auf, den ich mir noch nicht so richtig erklären
kann.
Testszenario: ich habe ein beschriebenes Band mit
ca. 100 GByte VM-Images. Nun möchte ich ein einzelnes
VM-Image vom Band holen. Dazu lösche ich ein VM-Image von der
lokalen Festplatte und versuche dann einen Restore vom Band.
Während des Restores wird versucht, das passende File auf
dem Band anzufahren, z.B. File Nummer 178. Intern wird
dann quasi der Befehl "pmt asf 178" an das Laufwerk geschickt.
Leider ist bei meinem Laufwerk immer das Resultat, dass
ein Filemark vorher positioniert wird, also in diesem Fall 177.
So sieht das dann im Restore-Log aus:
Code:
2021-06-10T21:53:36+02:00: found media label MD0001L5 (d5cfcd87-8576-4f4d-baa9-6feefaa60bda)
2021-06-10T21:53:36+02:00: was at file 2, moving to 178
2021-06-10T21:55:12+02:00: now at file 177
2021-06-10T21:55:12+02:00: TASK ERROR: could not restore snapshots to tmpdir: unexpected file type: [109, 49, 99, 109, 215, 2, 131, 191]An Position 177 ist natürlich ein falscher File-Typ, das ganze bricht also ab.
Das scheint wirklich ein Problem mit dem SCSI-Befehl LOCATE(16) zu sein.
Ich habe das auch mit anderer Software getestet. Das Laufwerk
positioniert immer ein File vorher.
Mache ich da irgendwas falsch? Hat jemand auch so ein Laufwerk und kann
den Bug nachvollziehen?
Die Firmwareversion des Laufwerks ist jedenfalls die neueste (Z6ED), und
ich wusste mir jetzt nicht anders zu helfen, als einen Patch für PBS zu basteln.
Hier wird einfach nach dem LOCATE-Befehl nochmal geguckt, ob ich genau ein
File zurück liege und dann bewege ich das Band einfach ein File nach vorne:
Code:
diff --git a/src/api2/tape/restore.rs b/src/api2/tape/restore.rs
index 14e20ee4..d0640237 100644
--- a/src/api2/tape/restore.rs
+++ b/src/api2/tape/restore.rs
@@ -727,6 +727,12 @@ fn restore_snapshots_to_tmpdir(
drive.move_to_file(*file_num)?;
let current_file_number = drive.current_file_number()?;
task_log!(worker, "now at file {}", current_file_number);
+
+ if current_file_number == (*file_num - 1) {
+ drive.move_to_file(*file_num + 1)?;
+ let current_file_number = drive.current_file_number()?;
+ task_log!(worker, "now at file {}", current_file_number);
+ }
}
let mut reader = drive.read_next_file()?;
@@ -806,6 +812,12 @@ fn restore_file_chunk_map(
drive.move_to_file(*nr)?;
let current_file_number = drive.current_file_number()?;
task_log!(worker, "now at file {}", current_file_number);
+
+ if current_file_number == (*nr - 1) {
+ drive.move_to_file(*nr + 1)?;
+ let current_file_number = drive.current_file_number()?;
+ task_log!(worker, "now at file {}", current_file_number);
+ }
}
let mut reader = drive.read_next_file()?;
let header: MediaContentHeader = unsafe { reader.read_le_value()? };Das Ergebnis sieht dann so aus, es funktioniert prima:
Code:
2021-06-19T15:04:07+02:00: Phase 1: temporarily restore snapshots to temp dir
2021-06-19T15:04:08+02:00: found media label MD0001L5 (5b625b1c-a3ed-41ce-9651-2bb985471170)
2021-06-19T15:04:08+02:00: was at file 2, moving to 86
2021-06-19T15:05:29+02:00: now at file 85
2021-06-19T15:05:29+02:00: now at file 86
2021-06-19T15:05:29+02:00: File 86: snapshot archive local-data:vm/101/2021-04-01T22:30:02ZGibt es solche Probleme mit File Marks oder habe ich einfach nur ein kaputtes Gerät?
Bis denn,
Michael
