On 7/4/22 05:36, B.M. wrote:
Hello I create encrypted backups on blu-ray discs for some years now with a bash script, but now I encountered a problem mounting some of these discs (but not all of them - in fact, my last backups consist of two discs each, and I cannot mount the first one but I can mount the second one for each of them - seems strange...). It's not date-related (and they are not too old). In detail, I use the following commands: IMGFILE=/home/TMP_BKP/backup.img IMGSIZE=24064000K IMGLOOP=`losetup -f` touch $IMGFILE truncate -s $IMGSIZE $IMGFILE losetup $IMGLOOP $IMGFILE cryptsetup luksFormat --cipher aes-xts-plain64 $IMGLOOP cryptsetup luksOpen $IMGLOOP BDbackup mkudffs -b 2048 --label $1 /dev/mapper/BDbackup mount -t udf /dev/mapper/BDbackup /mnt/BDbackup ... then I create my compressed backup files ... umount /mnt/BDbackup cryptsetup luksClose /dev/mapper/BDbackup losetup -d $IMGLOOP growisofs -dvd-compat -Z /dev/dvd=$IMGFILE; eject In order to mount the disc, I use: cryptsetup luksOpen -r /dev/dvd BDbackup mount -t udf /dev/mapper/BDbackup /mnt/BDbackup Unfortunately, this fails now for some of my discs and also for the last image file I created (not deleted yet...): mount: /mnt/BDbackup: wrong fs type, bad option, bad superblock on /dev/ mapper/BDbackup, missing codepage or helper program, or other error. And dmesg shows: UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found UDF-fs: Scanning with blocksize 2048 failed UDF-fs: warning (device dm-10): udf_load_vrs: No VRS found UDF-fs: Scanning with blocksize 4096 failed Any ideas what may happen here? Thank you. Best, Bernd
That approach is complex and Linux specific. I am unclear if a contents put into a UDF filesystem mounted on a dm-scrypt volume inside a loopback device, mastered and burned to BD-R, opened directly with cryptsetup(1), and mounted results in an exact copy of the starting contents (data and metadata). I would want to built a script to do round-trip validation.
I prefer to do filesystem archive operations at the filesystem level, and to use standard tools such as tar(1), gzip(1), rsync(1), and ccencrypt(1). My scripts typically produce an encrypted file (plus an MD5 file and a SHA256 file), which I then burn to disc using whatever standard tool the platform provides. Later, I mount the disc using whatever standard tool that particular platform provides and use standard tools to access the content.
Suggestions:1. Put your commands into one or more scripts. I try to keep my scripts simple, each doing some incremental step of an overall process. I can run them individually by hand, or feed them into higher level scripts. Traditional Bourne syntax works well in many cases. I upgrade to Perl if and when I need more power.
2. Assuming Bourne, enable the 'errexit' and 'nounset' options in the script:
set -o errexit set -o nounset3. Assuming Bourne, enable the 'xtrace' option during development. Once the script is working reliably, you can comment it out:
set -o xtrace4. Put good comments in the script. Once a backup script like this is working, I am loath to touch it. But when I must, climbing the learning curve again is far easier with good comments.
5. For every command issued that makes some change to the system, include additional commands to check that the command succeeded. The script should stop and dump useful debugging information if a check fails.
6. Some shell commands may return before the changes have fully propagated throughout the system, but the script will blindly charge ahead at full speed regardless; resulting in race condition bugs. Ironically -- the faster the computer, the more likely the problem. Ideally, devise commands and checks that are smart enough to accommodate such delays. A quick and dirty work-around is to add a short delay between such the command and the check:
sleep 3
7. Add option processing to the script. Provide a "-n" option ("dry run").
8. Decompose the overall script into smaller pieces, and work each
piece in turn.
9. Refactor common functionality into reusable components (e.g. functions, libraries). Beware that KISS coding techniques such as cut-and-paste can be easier to write, debug, and maintain than advanced programming techniques.
10. Idempotent scripts are nice, especially when there are failures part way through a long process:
https://en.wikipedia.org/wiki/Idempotent11. Do round-trip testing -- e.g. backup, restore to a side location, and confirm the two are identical (e.g. data and metadata).
12. Write an automated test suite for the script and/or its components. Perl has good support for test driven development.
13. Write documentation for the script and/or its components. Perl has support for built-in text documentation, and automation for converting that into manual pages.
David