Hi John,
> If I execute:
>
> rsync -zriv --progress --ignore-existing \
> /home/shareddocs/Photos /media/john/PHOTOS
>
> which is a line from my backup job, then it runs successfully even
> when there is NOT a disk plugged in. The "mount point"
> /media/john/PHOTOS is created in the root filesystem and off it goes!
I think I'd expect that if rsync has permission to create the PHOTOS
directory in /media/john.
> So, my hypothesis is that during a backup run the disk sometimes drops
> out and, immediately, a path is created on the root filesystem and the
> job continues.
If you're are running rsync multiple times in one backup then perhaps
the rsync running when the disk drops out might notice, exit with
a non-zero status, but the script ignores that, and then runs the next
rsync which creates the directory under the mount point.
> To overcome that I seem to need a control job that observes what is
> happening and aborts the copying when needed.
Ideally, one of the rsyncs suffers and your script notices and stops.
> let mypid=`Backup-rsync&` #start copying job, but this doesn't work,
> #so how can I save the pid?
There's a variable called ‘!’.
$ sleep 42 &
$ pid=$!
$ echo $pid
21162
> `df /|sed 1d| awk '{print $3}'|sed s/G//` > $limit
Test what's mounted by looking at the kernel's view.
$ awk '$2 == "/boot/firmware" {f=1} END {exit !f}' /proc/mounts
$ echo $?
0
$ awk '$2 == "/not-mounted" {f=1} END {exit !f}' /proc/mounts
$ echo $?
1
> I expect that observing for disk problems using dmesg would be better.
> I'll look into that later.
How is this drop-out disk powered? Does it have options? Some can run
from USB-data power but may accept a separate power input. Boosting its
power may help.
Or you could mount-rsync-umount for each rsync so even if one rsync
suffers a drop-out during, the next one will have a fresh mount to start
with.
> rsync -zriv --progress --ignore-existing \
I'm not sure -z does anything useful when both source and destination
are within the one machine; it may just consume CPU for no reason.
Is --ignore-existing what you want? A file poorly backed up won't be
corrected on a later run. I tend to rsync most of the time, and then
'rsync -c' occasionally so it reads every byte of the backup in running
the checksum compare. But perhaps you only want to back up fresh files,
and then not back them up again if they're modified later.
--
Cheers, Ralph.
--
Next meeting: Online, Jitsi, Tuesday, 2026-01-06 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... https://dorset.lug.org.uk
New thread, don't hijack: mailto:[email protected]
