Automatic backup, triggered by connecting device

[ahoff]

Fat32 it is. And I am running the latest version of the script. The filesystem may be the reason yes.

[Xnij]

Try replacing the rsync option -a (which according to the man page is equivalent to -rlptgoD) to maybe just -rt (recurse into sub directories and preserve modification times).

[ahoff]

Well, I reformated the disk to ext3, and now it seems to work ok. No strange messages in the logfile.

Thans for the tip.

[msx]

Fantastic script, i'll test it out soon

A small improvement: it should be possible to use the screen application to detach the program instead of having to create a fork script.
something like:

screen -m -d command

should do the trick.

[jonte]

Now with the 1.2.0 update, the built in backup option kind of makes this (great and impressive) backup solution obsolete for me.
I was just wondering if any of you guys can think of an easy way to reset all the changes made when using the automatic backup described in this thread, to enable the new B2-bulit in backup to function without conflicting.

Thanks
//Jonte

[Xnij]

I guess removing /etc/udev/rules.d/010_backup.rules would stop the script triggering when the drive is inserted.

There are a few more files. Just trace your steps backward from the initial guide and you should get most of them (I think the log function was created later)

Probably best to move the files first just in case something goes wrong.

[jonte]

Thanks. I'll give it a go
My guess would have been a trace back. Wasn't really sure though

//Jonte

[scott-2]

Even after the 1.2.0 update, I am trying to use this wonderful script. My best backup solution is to copy the data onto a cheap USB disk and store it offsite. This is a lower cost plan than using the 1.2.0 built-in backup feature for remote backups across the internet.

So, my question is about the mount command. Everything seems to work as advertised except mount, which fails silently. I can't find any logs which explain why it is not mounting my disk.

Code: Select all

mkdir -p $MOUNT_POINT && mount /dev/disk/by-uuid/$UUID $MOUNT_POINT

The mkdir successfully creates /tmp/backup_mount_point. The mount fails. Further down in the script, rsync creates the backup files in the tmp subdirectory. But since my USB disk was not mounted, this directory exists on Bubba's disk instead of on my USB disk.

How can I diagnose this problem?

I added a logger to echo the mount command:

Code: Select all

### Mount device by uuid
echo mount /dev/disk/by-uuid/$UUID $MOUNT_POINT > /var/log/mount.log
mkdir -p $MOUNT_POINT && mount /dev/disk/by-uuid/$UUID $MOUNT_POINT

The mount.log file says, correctly:

mount /dev/disk/by-uuid/4712bbff-f59c-4ddd-ad2c-2613c69df2c1 /tmp/backup_mount_point

[6feet5]

Hi,

Have you tried to mount the drive manually, using the command from the log file you mention?

/Johan

[scott-2]

Have you tried to mount the drive manually, using the command from the log file you mention?

Yes, it works when I do it manually (via sudo).

[6feet5]

Ok, that's weird.

What if you change the line with the mount command to (all on the same line):

Code: Select all

mkdir -p $MOUNT_POINT && mount /dev/disk/by-uuid/$UUID $MOUNT_POINT >>/var/log/mount.log 2>&1

This will redirect the output to the log file.

/Johan

[scott-2]

I got this in mount.log:

mount: special device /dev/disk/by-uuid/4712bbff-f59c-4ddd-ad2c-2613c69df2c1 does not exist

But again, when I mount it via sudo, it works.

At this point I'll mention that this is the second USB disk I've tried to use. The first one is a very old 1 GB stick, and the script works when configured for this device. When I changed it over to run on my newer 4 GB stick, it fails. Perhaps something about the device itself is causing the problem. I don't know.

[RandomUsername]

This is a bit of a shot in the dark but have a look in syslog and see if it's detecting your drive being connected several times.

See my post here for an explanation: http://forum.excito.net/viewtopic.php?f=10&t=2103#p9964

[scott-2]

This is a bit of a shot in the dark but have a look in syslog and see if it's detecting your drive being connected several times.

See my post here for an explanation: http://forum.excito.net/viewtopic.php?f=10&t=2103#p9964

Mr. Random might be on to something. This is what syslog says when I have NO_START=1 (note last line in red):

Feb 5 16:34:54 bubba kernel: usb 1-1.1: new high speed USB device using fsl-ehci and address 3
Feb 5 16:34:54 bubba kernel: usb 1-1.1: configuration #1 chosen from 1 choice
Feb 5 16:34:54 bubba kernel: scsi4 : SCSI emulation for USB Mass Storage devices
Feb 5 16:34:54 bubba kernel: usb-storage: device found at 3
Feb 5 16:34:54 bubba kernel: usb-storage: waiting for device to settle before scanning
Feb 5 16:34:54 bubba usb_backup: Not starting backup - edit /etc/default/usb_backup and change NO_START to 0
Feb 5 16:34:55 bubba last message repeated 6 times
Feb 5 16:34:59 bubba kernel: scsi 4:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 4.05 PQ: 0 ANSI: 2
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] 8013453 512-byte hardware sectors (4103 MB)
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Write Protect is off
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Assuming drive cache: write through
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] 8013453 512-byte hardware sectors (4103 MB)
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Write Protect is off
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Assuming drive cache: write through
Feb 5 16:34:59 bubba kernel: sdb: sdb1
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: [sdb] Attached SCSI removable disk
Feb 5 16:34:59 bubba kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0
Feb 5 16:34:59 bubba kernel: usb-storage: device scan complete
Feb 5 16:34:59 bubba usb_backup: Not starting backup - edit /etc/default/usb_backup and change NO_START to 0
Feb 5 16:35:00 bubba last message repeated 7 times

When I have NO_START=0, I see this:

Feb 5 19:08:56 bubba kernel: usb 1-1.1: new high speed USB device using fsl-ehci and address 4
Feb 5 19:08:56 bubba kernel: usb 1-1.1: configuration #1 chosen from 1 choice
Feb 5 19:08:56 bubba kernel: scsi5 : SCSI emulation for USB Mass Storage devices
Feb 5 19:08:56 bubba kernel: usb-storage: device found at 4
Feb 5 19:08:56 bubba kernel: usb-storage: waiting for device to settle before scanning
Feb 5 19:09:01 bubba kernel: scsi 5:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 4.05 PQ: 0 ANSI: 2
Feb 5 19:09:01 bubba kernel: sd 5:0:0:0: [sdb] 8013453 512-byte hardware sectors (4103 MB)
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Write Protect is off
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Mode Sense: 03 00 00 00
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] 8013453 512-byte hardware sectors (4103 MB)
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Write Protect is off
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Mode Sense: 03 00 00 00
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through
Feb 5 19:09:02 bubba kernel: sdb: sdb1
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: [sdb] Attached SCSI removable disk
Feb 5 19:09:02 bubba kernel: sd 5:0:0:0: Attached scsi generic sg1 type 0
Feb 5 19:09:02 bubba kernel: usb-storage: device scan complete

[6feet5]

Judging by the log, it's not the device being detected several times but the backup script being called several times.

I'm thinking the lock file mechanism that RandomUsername mention will probably not help in this case, since your device is missing when the script is run. By the way, my script already have a similar lock mechanism (@RandomUsername: I'm interested in knowing if my solution didn't work so I can rewrite it). Maybe it should be put earlier in the script (the test is done after logging to syslog, which is why you will see the entry several times).

Could it be that your udev rule (the one in /etc/udev/rules.d) is too general? In this case the script might be called before the device node exist. Show us the rule.

Also, start 'udevmonitor' as root, then connect the device and show us the resulting output.

While the device is connected, run

Code: Select all

udevtest /class/block/sdb

where sdb is replaced with the device name your stick get. Show us the output.

/Johan