[HOWTO] Daily incremental backup with rsnapshot

[DeepBlueDiver]

Updating to firmware 3.4.0 will break your rsnapshot setup.
Read http://forum.qnap.com/viewtopic.php?f=142&t=40959

[micke]

Updating to firmware 3.4.0 will break your rsnapshot setup.
Read http://forum.qnap.com/viewtopic.php?f=142&t=40959

[The link is about the changed home directories in /etc/passwd]

I have my own configuration for rsnapshot, so I don't know how easy it would be to modify the configuration in crushdepth's HOWTO, but instead of depending on the default location of root's home directory you could specify the location of a configuration file for ssh and then include the required information in that file.

For example, in your rsnapshot.conf file you could add a line like this

Code: Select all

ssh_args        -o BatchMode=yes -F /etc/config/ssh/rsnapshot_config

The /etc/config/ssh/rsnapshot_config could contain something like this (update locations according to where you have stored the files)

Code: Select all

Host *
  UserKnownHostsFile /etc/config/ssh/known_hosts
  IdentityFile       /etc/config/ssh/id_rsa

Now, rsnapshot should pick up the correct settings for ssh when it is run.

/Mike

[DeepBlueDiver]

Good idea, Mike. This should make rsnapshot independent from changes in home dir location in future firmwares.
Those following Crushdepth's HOWTO should edit ssh_args in /opt/etc/rsnapshot.conf and follow Mike's directions.

[peace_man]

Hi!

I tried to run rsnapshot with BatchMode=yes, but that didn't help. After the firmware update running ssh with "BatchMode yes"-option doesn't work at all and I can run rsnapshot only by entering the passphrase. I also tried to run

Code: Select all

"ssh -vvv -o "BatchMode yes" admin@192.168.1.2"

and it returned

Code: Select all

"Permission denied (publickey,password,keyboard-interactive)."

. (Logfile attached)

Does anybody know what's the specific problem with ssh after the firmware update and how it can be solved so that rsnapshot is working again ?

Thanks!

[crushdepth]

Please see this thread, its a simple fix. However, a better fix may be listed a few posts above in this thread, but I haven't tested it yet. The issue is that the firmware update changed the path of the home directory, so its looking for the .ssh files in the wrong place.

[Ceco]

Hi.

Here is a hint for anyone who wants to have "Postpone the restart/shutdown schedule when a replication job is in progress" option
to work with rsnapshot. This works for my TS-219 and probably other systems. Just replace HDA_DATA with your device's data dir.

1) Create "scripts" directory on HDA_DATA and copy original /etc/init.d/wait_RR into it

Code: Select all

# cd /share/HDA_DATA
# mkdir scripts
# cp /etc/init.d/wait_RR /share/HDA_DATA/scripts

2) Now edit /share/HDA_DATA/scripts/wait_RR.
Replace

Code: Select all

/bin/ps | /bin/grep /usr/bin | /bin/grep "rsync "

With

Code: Select all

/bin/ps | /bin/grep "rsync " | /bin/grep -v "grep "

3) Rename original /etc/init.d/wait_RR and symlink to new one

Code: Select all

# cd /etc/init.d
# mv wait_RR wait_RR.orig
# ln -s /share/HDA_DATA/scripts/wait_RR wait_RR

4) Add Step 3 into your autorun script to preserve your new /etc/init.d/wait_RR after reboot.
Refer to http://wiki.qnap.com/wiki/Running_Your_ ... at_Startup for more info

EDIT: grep fix to exclude grep process itself. Thanx to Eduardo.

[paolomarino]

I have read of a RSnapshot Qkpg:
http://forum.qnap.com/viewtopic.php?f=121&t=44555
It will be a nice develop

[smholmes]

Please see this thread, its a simple fix. However, a better fix may be listed a few posts above in this thread, but I haven't tested it yet. The issue is that the firmware update changed the path of the home directory, so its looking for the .ssh files in the wrong place.

What's the fix? I'm not seeing it.

[Magnus8513]

The "home-directory problem" can be solved with a symlink:

Code: Select all

ln -s /root /share/homes/admin

[virtualdj]

I followed crushdepth guide on rsnapshot and it works well (thanks!) and I backup to /opt/var/rsnapshot.
Now the question: is it possible to mount the backup folder under a subfolder such as /share/Public/Backup and make this mount read-only (so all users can view and recover files without messing the backup)?

How can I do this?

[smholmes]

It's still broken for me. Adding the symlink for the home directory worked, and key-based authentication is working for me when I try to log into to my target server from the shell, but whenever I try to run rsnapshot, I keep getting a password prompt. That means in wont' work automatically with my cron jobs. Any idea what I might be missing?

[micke]

is it possible to mount the backup folder under a subfolder such as /share/Public/Backup and make this mount read-only (so all users can view and recover files without messing the backup)?

You can re-mount the directory read-only at a new location using the following commands,

Code: Select all

/bin/mount --bind /opt/var/rsnapshot /share/Public/Backup
/bin/mount -o remount,ro /share/Public/Backup

The permissions of the file system won't change, so whether users can access files in the backup depends on the settings in /opt/var/rsnapshot.

/Mike

[virtualdj]

@ micke
Thanks, actually I already tried the 2 commands you have suggested to me (I found them using Google here) but they didn't work because a normal user was able to delete the files in the backup.

Maybe I was missing this:

The permissions of the file system won't change, so whether users can access files in the backup depends on the settings in /opt/var/rsnapshot.

But, look, these are my permissions:

Code: Select all

[/opt/var] # ls -l
drwxr-xr-x    3 admin    administ     4096 Feb 18 20:34 cache/
drwxr-xr-x    2 admin    administ     4096 May  3 17:17 empty/
drwxr-xr-x    2 admin    administ     4096 May 24 20:29 log/
drwxr-xr-x    4 admin    administ     4096 May 24 21:12 rsnapshot/
drwxr-xr-x    2 admin    administ     4096 May 24 21:12 run/
drwxr-xr-x    3 admin    administ     4096 May 16  2010 spool/
drwxr-xr-x    3 admin    administ     4096 Sep 15  2010 state/

So apart from root/admin, other users shouldn't be able to delete files; anyway, inside the backup, the things are different (a sample follows):

Code: Select all

[/opt/var] # ls -l rsnapshot/hourly.0/localhost/share/Public/script/
-rwxrwxrwx    2 admin    administ      735 Nov 24 21:04 alreadyrunning.sh*
drwxrwxrwx    2 web      everyone     4096 May 24 21:12 empty/
-rwxrwxrwx    2 admin    administ     8644 Dec  7 21:33 jdn.sh*

Under that folder, we see 2 files created by admin and 1 created by the user "web".
However, the user "web" CAN delete everything and that's what I want to prevent. How can I do that?

Should I have to change permissions for all the files in the backup? That isn't so easy, because everytime a new backup is created the permissions have to be changed too, so I'm looking for an easier solution. The article that I linked before mentions mounting using NFS and localhost, but I don't know how to do that on QNAP (i.e. not using the webend as the folder is not shared and I want the "folder read-only view" inside another shared older). Please, can you enlighten me?

[micke]

Thanks, actually I already tried the 2 commands you have suggested to me (I found them using Google here) but they didn't work because a normal user was able to delete the files in the backup.

Note that you must run both commands in the specified order or it most likely won't work. I have tried it on my TS-239 Pro and it worked just fine (i.e. it is not possible to remove any files from the read-only mount point; not even the admin user can remove files).

However, the user "web" CAN delete everything and that's what I want to prevent. How can I do that?

By making the file system read-only and that is exactly what the two mount commands (should) do

When I wrote that "the permissions of the file system won't change" I meant that if a user e.g. cannot read a file in /opt/var/rsnapshot then that will still be the case in the new (read-only) mount point.

/Mike

[virtualdj]

I have tried it on my TS-239 Pro and it worked just fine (i.e. it is not possible to remove any files from the read-only mount point; not even the admin user can remove files).

After I've read your post, I've tried again. The commands are written in the correct order and the mount works:

Code: Select all

 # mount
/proc on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,size=32M)
none on /proc/bus/usb type usbfs (rw)
/dev/sda4 on /mnt/ext type ext3 (rw)
/dev/md9 on /mnt/HDA_ROOT type ext3 (rw)
/dev/sda3 on /share/HDA_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,nodelalloc,noacl)
tmpfs on /.eaccelerator.tmp type tmpfs (rw,size=32M)
/share/HDA_DATA/.qpkg/Optware/var/rsnapshot on /share/HDA_DATA/Public/Backup type none (ro,bind)

Removing files through SSH with "admin" user under /share/Public/Backup/daily.0 doesn't work:

Code: Select all

[/share/Public/Backup/daily.0/localhost/share/Public/script] # rm jdn.sh
rm: remove `jdn.sh'? y
rm: unable to remove `jdn.sh': Read-only file system

But if I access through Samba (on a Windows machine) the Public folder and go into the subfolders Backup/daily.0/localhost/share/Public/script, even if I'm logged with the user 'web' (and not admin!) I can remove the files.

So it seems that the read-only "flag" doesn't apply to Samba (and that's the reason why I was able to delete the files before, I didn't try under SSH). Now it's becoming weird...
Unfortunately, I would like to have the folder visible under Samba (so that the other users can browse the backups without messing them).