Posted: 19 Apr 2009, 16:17
Fat32 it is. And I am running the latest version of the script. The filesystem may be the reason yes.
forum.excito.com
Bubba community forum
https://forum.excito.com/
Automatic backup, triggered by connecting device
Page 2 of 3
Posted: 20 Apr 2009, 13:25
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).
Posted: 20 Apr 2009, 13:43
Well, I reformated the disk to ext3, and now it seems to work ok. No strange messages in the logfile.
Thans for the tip.
Thans for the tip.
Posted: 22 Apr 2009, 09:32
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.
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.
Re: Automatic backup, triggered by connecting device
Posted: 05 Aug 2009, 09:49
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
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
Re: Automatic backup, triggered by connecting device
Posted: 14 Aug 2009, 12:30
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.
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.
Re: Automatic backup, triggered by connecting device
Posted: 14 Aug 2009, 14:30
Thanks. I'll give it a go
My guess would have been a trace back. Wasn't really sure though
//Jonte
My guess would have been a trace back. Wasn't really sure though
//Jonte
Re: Automatic backup, triggered by connecting device - mount
Posted: 05 Feb 2010, 14:22
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.
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:
The mount.log file says, correctly:
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_POINTHow 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_POINTmount /dev/disk/by-uuid/4712bbff-f59c-4ddd-ad2c-2613c69df2c1 /tmp/backup_mount_point
Re: Automatic backup, triggered by connecting device
Posted: 05 Feb 2010, 14:32
Hi,
Have you tried to mount the drive manually, using the command from the log file you mention?
/Johan
Have you tried to mount the drive manually, using the command from the log file you mention?
/Johan
Re: Automatic backup, triggered by connecting device
Posted: 05 Feb 2010, 16:54
Yes, it works when I do it manually (via sudo).6feet5 wrote:Have you tried to mount the drive manually, using the command from the log file you mention?
Re: Automatic backup, triggered by connecting device
Posted: 05 Feb 2010, 18:14
Ok, that's weird.
What if you change the line with the mount command to (all on the same line):
This will redirect the output to the log file.
/Johan
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/Johan
Re: Automatic backup, triggered by connecting device
Posted: 05 Feb 2010, 18:53
I got this in mount.log:
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.
But again, when I mount it via sudo, it works.mount: special device /dev/disk/by-uuid/4712bbff-f59c-4ddd-ad2c-2613c69df2c1 does not exist
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.
Re: Automatic backup, triggered by connecting device
Posted: 06 Feb 2010, 01:33
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
See my post here for an explanation: http://forum.excito.net/viewtopic.php?f=10&t=2103#p9964
Re: Automatic backup, triggered by connecting device
Posted: 06 Feb 2010, 19:07
Mr. Random might be on to something. This is what syslog says when I have NO_START=1 (note last line in red):RandomUsername wrote: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
When I have NO_START=0, I see this: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
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
Re: Automatic backup, triggered by connecting device
Posted: 07 Feb 2010, 06:15
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 where sdb is replaced with the device name your stick get. Show us the output.
/Johan
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/Johan