#3448 Issue open: Ultrium9 SAS tape drive: OUTPUT=OBDR mkbackup fails (tar: /dev/nst0: Device busy)¶
Labels: support / question, special hardware or VM
DebianGuru opened issue at 2025-04-07 12:56:¶
Requesting support or just a question¶
I can backup to SMB, but backup to tape drive fails.
Platform¶
Linux x64
Output¶
Debian12, rear installed from Debian repository. Relax-and-Recover 2.7 / Git. New Lenovo Server with Ultrium9 SAS drive. I've tested read and write with tools like mt and tar. Drive works fine. Until the tape drive arrived, I had used rear with a SMB network share with no problems.
Modified the local.conf to reflect new tape drive. Here are the relevant lines:
OUTPUT=OBDR
TAPE_DEVICE=/dev/nst0
BACKUP=NETFS
BACKUP_URL=tape:///dev/nst0
rear -d mkbackup results in this:
... (not including previous lines)
Running 'rescue' stage ======================
Creating recovery system root filesystem skeleton layout
ERROR: Failed to copy '/usr/share/rear/skel/default' contents to /var/tmp/rear.wqVfrLLtDdiDtFk/rootfs
Some latest log messages since the last called script 010_merge_skeletons.sh:
2025-04-07 08:22:15.177389748 Creating recovery system root filesystem skeleton layout
2025-04-07 08:22:15.186073304 Copying '/usr/share/rear/skel/default' contents to /var/tmp/rear.wqVfrLLtDdiDtFk/rootfs
tar: /dev/nst0: Cannot open: Device or resource busy
tar: Error is not recoverable: exiting now
The first ERROR looks like a failure to copy one folder into another. I thought maybe a permissions or something, but modifying the local.conf to go back to a SMB share works and I don't see how changing the output could affect a file copy on the local hard drive. The second issue is the "tar: /dev/nst0: Cannot open: Device or resource busy" line. Makes it seem the tape drive is busy, but I assure you that nothing else is using it. I tried running "lsof | grep nst0" to see if anything had it open, but nothing.
Any help is appreciated as I'm under a deadline to get this machine into production with a good backup/restore solution.
Additional information¶
No response
gdha commented at 2025-04-08 06:29:¶
@DebianGuru Please use rear -D mkbackup so we can see the logs in more
detail - thanks for trying OBDR - it has been ages ago somebody used it.
jsmeix commented at 2025-04-08 06:57:¶
First and foremost:
I never used a tape device with Linux
so I cannot really help with tape device issues
and I may not see things which are obvious
for users who actually use a tape device.
So only FYI:
In general regarding OBDR we had
https://github.com/rear/rear/issues/2637
In particular regarding OBDR and 'tar' we
got this information:
https://github.com/rear/rear/issues/2637#issuecomment-1475690995
Here we need to update config file with "" and ()
because of tar behavior, mentioned also in
https://github.com/rear/rear/issues/2911
...
BACKUP_PROG_COMPRESS_OPTIONS=()
BACKUP_PROG_COMPRESS_SUFFIX=""
Apparently
/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
is not yet fixed, see current master code
https://github.com/rear/rear/blob/master/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
and same in ReaR 2.7
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
@DebianGuru
you may try out if it perhaps helps when you modify
/usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
to this content
# Disable compression (as tape drive does compression already)
Log "Disable compression for backup (BACKUP_PROG_COMPRESS_*)"
BACKUP_PROG_COMPRESS_OPTIONS=()
BACKUP_PROG_COMPRESS_SUFFIX=""
and/or set in local.conf
BACKUP_PROG_COMPRESS_OPTIONS=()
BACKUP_PROG_COMPRESS_SUFFIX=""
For the details behind you may read through
https://github.com/rear/rear/issues/2911
jsmeix commented at 2025-04-08 07:16:¶
In general regarding code that sets BACKUP_PROG_COMPRESS_OPTIONS
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep 'BACKUP_PROG_COMPRESS_OPTIONS='
usr/share/rear/conf/default.conf:
# like BACKUP_PROG_COMPRESS_OPTIONS=( -I 'gzip -9 -n -c' )
# Furthermore for advanced things like BACKUP_PROG_COMPRESS_OPTIONS=("--zstd")
BACKUP_PROG_COMPRESS_OPTIONS=( --gzip )
usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh:
BACKUP_PROG_COMPRESS_OPTIONS=
usr/share/rear/output/OBDR/default/840_write_image.sh:
BACKUP_PROG_COMPRESS_OPTIONS=()
In usr/share/rear/output/OBDR/default/840_write_image.sh
setting BACKUP_PROG_COMPRESS_OPTIONS was fixed by
https://github.com/rear/rear/commit/48338ae142b8b585a52e17f2438e31e46dd2c312
via
https://github.com/rear/rear/pull/2963
But apparently setting BACKUP_PROG_COMPRESS_OPTIONS correctly in
usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
had been forgotten.
https://github.com/rear/rear/pull/3450
intends to get that generic syntax error finally fixed.
jsmeix commented at 2025-04-08 07:39:¶
@DebianGuru
for "rear mkbackup" or "rear mkrescue" it cannot help to modify
usr/share/rear/verify/OBDR/NETFS/default/540_set_backup_compression.sh
because scripts in usr/share/rear/verify/
are not run for "rear mkbackup" or "rear mkrescue"
(they are run for "rear recover" and "rear restoreonly")
so syntactically false setting of BACKUP_PROG_COMPRESS_OPTIONS
is likely not the reason why "rear mkbackup" or "rear mkrescue"
fails for you and BACKUP_PROG_COMPRESS_OPTIONS is not used in
usr/share/rear/rescue/default/010_merge_skeletons.sh
which is where "rear mkbackup" or "rear mkrescue" fails for you.
DebianGuru commented at 2025-04-08 12:32:¶
Fellas, thanks for the help.
I did find the strangest thing.
I was running this as root via "sudo su - " then running rear.
I also had environment variable "TAPE=/dev/nst0" in bash.
I removed the environment variable then, run the command with just "sudo
rear -v mkbackup" and it worked.
Unfortunately, afterwards, I cannot find any way to get my Lenovo SR
650V3 to boot of the SAS Ultrium9 drive.
I tried UEFI and legacy.
So I'm back to the drawing board of building an .iso somewhere then
burning/booting from CD. (or perhaps using a flash drive to boot).
Unfortunately, another issue has cropped up and that will be in my next
post.
https://github.com/rear/rear/issues/3451
Thanks again for all the help and suggestions.
jsmeix commented at 2025-04-09 07:15:¶
@DebianGuru
I have no idea how an environment variable "TAPE=/dev/nst0"
could influence what "rear mkbackup" does because
as far as I see TAPE is not used as variable in ReaR.
Only TAPE_BLOCKSIZE TAPE_DEVICE TAPE_LABEL are used in ReaR.
Perhaps a program which is called by rear
may use TAPE as environment variable?
Current GitHub master code and same in ReaR 2.7:
# find usr/sbin/rear usr/share/rear/ -type f | xargs grep 'TAPE' | grep -v 'TAPE_DEVICE'
usr/share/rear/conf/default.conf:
# (NETFS, ISO, TAPE ...)
TAPE_BLOCKSIZE=
usr/share/rear/prep/TAPE/default/500_set_tape_blocksize.sh:
Log "Set tape block size to ${TAPE_BLOCKSIZE:-0}"
usr/share/rear/prep/OBDR/default/500_check_tape_label.sh:
[[ "$USB_DEVICE_FILESYSTEM_LABEL" == "${TAPE_LABEL:0:8}" ]]
[Export of Github issue for rear/rear.]