10
Veeam Tape Backup bricht ab
Moin,
wir sichern mit Veeam B&R 12 seit ewigen Zeiten 1x wöchentlich quasi alle Systeme auf ein LTO8-Band.
Umgebung:
Seit einigen Wochen haben wir das Problem, dass das Backup mit einer Fehlermeldung abbricht:
Im Eventlog finden sich immer wieder Einträge mit der ID 5008:
Und unmittelbar davor Event 129:
Auffällig ist, dass die Sicherung der NAS-Daten immer problemlos durchläuft, das Sichern der lokalen Serverdaten scheitert.
Was ich schon probiert / geprüft habe:
Ticket bei Veeam läuft, bringt mich aber aktuell auch nicht weiter. Die einzigen Hinweise, die ich ergoogeln konnte, wiesen immer auf das Powermanagement hin (habe ich bereits geprüft).
Gruß
wir sichern mit Veeam B&R 12 seit ewigen Zeiten 1x wöchentlich quasi alle Systeme auf ein LTO8-Band.
Umgebung:
- Fujitsu Primergy RX300 S8 mit Windows Server 2019
- Veeam B&R 12 auf demselben Server als Backup Server
- Adaptec HBA 1100-8e Controller
- Am Controller direkt per Kabel eine Overland NEO S Tape Library mit eingebautem LTO8-Laufwerk IBM Ultrium 8 HH
- Es wird ein Ordner komplett lokal vom Server gesichert (etwa 3,5TB), der andere Ordner liegt auf einem Synology-NAS (etwa 500GB)
Seit einigen Wochen haben wir das Problem, dass das Backup mit einer Fehlermeldung abbricht:
Tape fatal error. The I/O bus was reset. Tape write error. Exception from server: Reconnectable protocol device was closed. TapeRemoteFilesBackupServer failed to process file, list size: 3.
Failed to backup SERVER Backup VMs SO - Filesrv/SERVER Backup VMs SO - FilesrvD2024-03-10T120012_E64A.vbk: Tape fatal error.
Task D:\TAPE-BACKUP\SERVER Backup VMs SO - Filesrv\SERVER Backup VMs SO - FilesrvD2024-03-10T120012_E64A.vbk completed with warning. Details: Tape fatal error.
Incremental backup: Tape fatal error. The I/O bus was reset. Tape write error. Exception from server: Reconnectable protocol device was closed. TapeRemoteFilesBackupServer failed to process file, list size: 3. Tape fatal error. The I/O bus was reset. Tape write error. Exception from server: Reconnectable protocol device was closed. TapeRemoteFilesBackupServer failed to process file, list size: 3.Im Eventlog finden sich immer wieder Einträge mit der ID 5008:
The controller in slot 255 (bus 129, device 0, function 0), the OS requested a Reset of LUN (2, 2, 1).Und unmittelbar davor Event 129:
Ein Zurücksetzen auf Gerät "\Device\RaidPort2" wurde ausgegeben. Auffällig ist, dass die Sicherung der NAS-Daten immer problemlos durchläuft, das Sichern der lokalen Serverdaten scheitert.
Was ich schon probiert / geprüft habe:
- Treiber- / FW-Update von Tape Library und Laufwerk
- Treiber- / FW-Update Adaptec Controller
- Überprüfung der Energiepläne im BIOS für PCIe, alle deaktiviert bzw. Höchstleistung
- Reboot von Server und Library
Ticket bei Veeam läuft, bringt mich aber aktuell auch nicht weiter. Die einzigen Hinweise, die ich ergoogeln konnte, wiesen immer auf das Powermanagement hin (habe ich bereits geprüft).
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82730548187
Url: https://administrator.de/forum/veeam-tape-backup-bricht-ab-82730548187.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
10 Kommentare
Neuester Kommentar
Hi,
hört sich vielleicht banal an, aber ein neues Tape hast du getestet?
Edit: Folgendes KB bereits geprüft? https://www.veeam.com/kb1887
Gruß
hört sich vielleicht banal an, aber ein neues Tape hast du getestet?
Edit: Folgendes KB bereits geprüft? https://www.veeam.com/kb1887
Gruß
@Baubutze
Jupp, andere Tapes mit selbem Problem.
Und sorry, den Link habe ich auch schon gelesen und umgesetzt.
Gruß
Jupp, andere Tapes mit selbem Problem.
Und sorry, den Link habe ich auch schon gelesen und umgesetzt.
Gruß
Moin,
Meine Vermutung: Der HBA ist nicht 100% Kompatibel bzw. könnte eine Abhängigkeit darin bestehen, in welchem PCIe Slot der HBA steckt. Nicht, dass da irgendwelche Kanäle mit dem Controller der internen Discs doppelt belegt sind und der Server beim Sichern der 3,5TB in die Knie geht.
Ist aber alles nur eine wage Vermutung.
Was ich schon probiert / geprüft habe:
Treiber- / FW-Update von Tape Library und Laufwerk
Treiber- / FW-Update Adaptec Controller
Aber der Flutschi-Server hat noch keine (FW-)Updates bekommen?Treiber- / FW-Update von Tape Library und Laufwerk
Treiber- / FW-Update Adaptec Controller
Meine Vermutung: Der HBA ist nicht 100% Kompatibel bzw. könnte eine Abhängigkeit darin bestehen, in welchem PCIe Slot der HBA steckt. Nicht, dass da irgendwelche Kanäle mit dem Controller der internen Discs doppelt belegt sind und der Server beim Sichern der 3,5TB in die Knie geht.
Ist aber alles nur eine wage Vermutung.
Moin @Coreknabe
vielleicht Kopierst du diese 3,5TB mal auf eine andere Platte (USB, was auch immer) und machst einen neuen JOB im VEEAM um zu testen ob das dann durch geht. Es ist ggf nicht ausgeschlossen, dass deinen Platte intern im server eine Macke hat, oder die Daten selbst ne Macke haben!?!?!??!
Ein älteres Backup der 3,5TB sollte erhalten und gesperrt bleiben.
Kreuzberger
vielleicht Kopierst du diese 3,5TB mal auf eine andere Platte (USB, was auch immer) und machst einen neuen JOB im VEEAM um zu testen ob das dann durch geht. Es ist ggf nicht ausgeschlossen, dass deinen Platte intern im server eine Macke hat, oder die Daten selbst ne Macke haben!?!?!??!
Ein älteres Backup der 3,5TB sollte erhalten und gesperrt bleiben.
Kreuzberger
@em-pie
Mr. Flutschi hat regelmäßig Updates bekommen, da die Möhre aber mittlerweile 10 Jahre alt ist, gibt es von Fujitsu nix Neues mehr.
Das lief ja schon jahrelang in der Konstellation. Ich weiß, das tat Omas Waschmaschine auch...
@kreuzberger
Hatte ich auch schon vermutet. Betrifft aber a) immer andere Dateien und b) werden die jeden Samstag neu erzeugt. Festplattentest auch OK.
Gruß
Mr. Flutschi hat regelmäßig Updates bekommen, da die Möhre aber mittlerweile 10 Jahre alt ist, gibt es von Fujitsu nix Neues mehr.
Das lief ja schon jahrelang in der Konstellation. Ich weiß, das tat Omas Waschmaschine auch...
@kreuzberger
Hatte ich auch schon vermutet. Betrifft aber a) immer andere Dateien und b) werden die jeden Samstag neu erzeugt. Festplattentest auch OK.
Gruß
@Coreknabe
es ging eigentlich eher um die frage, ob du das Windows Server SQL nutzt, was ja begrenzt ist, oder einen vollwertigen SQL Server. Ein verdacht wäre ja, das dann die SQL Datenbank voll ist und er sich deshalb verweigert.
Kreuzberger
es ging eigentlich eher um die frage, ob du das Windows Server SQL nutzt, was ja begrenzt ist, oder einen vollwertigen SQL Server. Ein verdacht wäre ja, das dann die SQL Datenbank voll ist und er sich deshalb verweigert.
Kreuzberger
@kreuzberger
Ist eine eigene SQL-Instanz mit SQL2017. Wenn die DB voll wäre, hätten ja auch andere Jobs Probleme.
Gruß
es ging eigentlich eher um die frage, ob du das Windows Server SQL nutzt, was ja begrenzt ist, oder einen vollwertigen SQL Server. Ein verdacht wäre ja, das dann die SQL Datenbank voll ist und er sich deshalb verweigert.
Ist eine eigene SQL-Instanz mit SQL2017. Wenn die DB voll wäre, hätten ja auch andere Jobs Probleme.
Gruß
Moin,
Update: Problem gelöst, auf Anraten von Veeam haben wir das SAS-Kabel getauscht. Und siehe da, es funktioniert wieder.
Gruß
Update: Problem gelöst, auf Anraten von Veeam haben wir das SAS-Kabel getauscht. Und siehe da, es funktioniert wieder.
Gruß
1
