Hi,
Bob McGowan wrote:
> I've been trying to figure out how to use my BD disc writer to create
> backups of files.
I do this by Rock Ridge enhanced ISO 9660 on BD-R and BD-RE media,
following this example from the man page of xorriso:
xorriso \
-abort_on FATAL \
-for_backup -disk_dev_ino on \
-assert_volid 'PROJECTS_MAIL_*' FATAL \
-dev /dev/sr0 \
-volid PROJECTS_MAIL_"$(date '+%Y_%m_%d_%H%M%S')" \
-not_leaf '*.o' -not_leaf '*.swp' \
-update_r /home/thomas/projects /projects \
-update_r /home/thomas/personal_mail /personal_mail \
-commit -toc -check_md5 FAILURE -- -eject all
To be used several times on the same medium, whenever an update of the
two disk trees to the medium is desired. Begin with a blank medium and
update it until the run fails gracefully due to lack of remaining space
on the old one.
This makes sense if the full backup leaves substantial remaining
capacity on media and if the expected changes are much smaller than the
full backup. To apply zisofs compression to those data files which get
newly copied from the local filesystem, insert these commands
immediately before -commit :
-hardlinks perform_update \
-find / -type f -pending_data -exec set_filter --zisofs -- \
> What I first found were instructions to create an empty file of the
> propper size, 'mkudffs file', loop mount it, copy files to it, unmount
> and burn to the BD disc.
To my experience, UDF offers no practical advantages over ISO 9660 when
you plan to read the backup by GNU/Linux. Some other free operating
systems have problems iin ISO 9660 filesystems with files of size 4 GiB or
larger. MS-Windows will show the dull ISO 9660 names if you do not give
xorriso command
-joliet on
before the xorriso command -commit.
You could use the program genisoimage with its option -udf together
with a burn program like growisofs, cdrecord, or xorrecord. This produces
an older version of UDF suitable for DVD video but not for Blu-ray video.
growisofs on Debian uses genisoimage by default. Its man page proposes:
growisofs -Z /dev/dvd -R -J /some/files
You would add genisoimage option -udf.
The other burn programs can take their data strem from a pipe fed by
genisoimage. Like:
genisoimage -R -J -udf /some/files \
| xorrecord -v dev=/dev/sr0 -waiti -eject -
Multi-session with genisoimage -udf is known to be problematic (or
impossible). Your apporach with mkudffs might be capable of taking file
changes on BD-RE media when they are mounted with rw-premissions.
(If you can get it mounted, that is.)
> Further searching found that the recommended way to access UDF
> filesystems on optical media is to use "packet writing".
This old statement applies to writing, not to reading. Further it is
mostly about writing of CD media and some DVD media types. BD media can
get written by several write types which all resemble CD packet writing.
But in your case of mkudffs operating on a filesystem image file there
is no special medium involved. This approach assumes that you prepare
a mountable image file and flatly copy it to a medium by whatever
write type is suitable.
> For the life of me I cannot figure out how to make this work. None of
> the suggestions I've found work with my setup.
Did you eject your BD and reload it before mounting it for looking at
its content ?
The Linux kernel offers no way to tell it to re-assess a freshly written
/dev/sr device. You have to force re-assessment by physically reloading
the medium.
If this in-out dance does not help, try to mount your UDF filesystem image
file before copying it to a BD:
sudo mkdir /mnr/udf
sudo mount /my/udf_image_file /mnt/udf
If this works, then you know that your way of writing to BD is flawed.
In this case, describe it here in more detail.
If mount already fails with the UDF image file, then your mkudffs run is
flawed. In this case, describe exactly how you do it.
> It may be that my BD drive is too old but before going the route of
> changing it out, I'd like to know if there's something I've missed in
> the general process.
Try a simple xorriso run. Assuming that your drive is at /dev/sr0:
disk_dir="...path.to.some.directory..."
iso_dir="...name.for.the.directory.on.the.BD.medium..."
xorriso -outdev /dev/sr0 -blank as_needed \
-for_backup \
-map "$disk_dir" "$iso_dir" \
-commit -toc -check_md5 FAILURE -- -eject all
This will copy the tree under "$disk_dir" onto the BD medium and then
perform a check-read run to verify readbility and matching MD5 checksum
of the overall ISO 9660 filesystem.
No UDF involved, of course.
If your BD burner has a tray motor, then the tray is supposed to come
out of the drive when the checksum matchies. In case of mismatch it will
stay in and you will have to eject it manually.
If the xorriso run states in the end:
Ok, session data match recorded md5.
then the medium should be mountable.
If the drive is bad, then the checksum will hardly match.
> The DB burner is an LG and is quite old, as in maybe 15 years.
My oldest one is a LG GGW-H20L from 2008. It survived the demise of two
USB boxes and now lives in its third home.
It cannot burn modern BD-R media or format modern BD-RE. But it works
with BD-RE formatted by a LG BH16NS40 from 2013. It fails to write BD-RE
which were formatted by a newer ASUS BW-16D1HT. In this case the burn run
reports errors.
Have a nice day :)
Thomas
