[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Post-setup questions

From: Maarten Bezemer
Subject: Re: [rdiff-backup-users] Post-setup questions
Date: Sun, 14 Aug 2011 22:54:18 +0200 (CEST)

On Sun, 14 Aug 2011, Grant wrote:

My laptop is one of the systems I want to back up and when I travel it
ends up behind a router I have no control over.  Because of this, my
systems push to the backup server instead of the backup server pulling
from them.

Based on the 'security' classification you gave to this question, I assume you're not entirely happy with the laptop pushing. I wouldn't be happy with that either ;-) Since you can't do much anything about those third party routers, I'd say you should look for other ways do get it working in a way that does make you happy.

So, try to find some more info about openvpn. If the routers allow ssh connections to your backup server, they will most likely also allow an openvpn "tunnel". Using that tunnel, you can instruct the backup server to run rdiff-backup against your laptop. That way, your backup server will be pulling data and your laptop only needs to contain the openvpn key. I guess you could also configure openvpn in such a way that it would require user input to start the connection.

I'm using openvpn myself for similar tasks, and once setup properly, it makes life so much easier ;-) (interconnecting distant private networks, where each location is connected using isp-provided NAT-ing ADSL modems that don't allow the users to change most of the settings)


If I deleted a file from one of my systems 61 days ago and today I run
--remove-older-than 60D, will the original file be deleted from the
backup or only the increments?

If you remove all historic data from 60 days back and before, any trace of the file deleted 61 days ago will be gone. Since you deleted the file 61 days ago, the file was already deleted from the backup and is only kept as a (snapshot) increment. (That is: inside the rdiff-backup-data directory, which is usually considered to not be part of "the backup".)

I'm backing up to a 1TB USB hard drive dedicated to backups.  How low
should I set the super-user space reservation on that drive?

Any percentage you like..
If you run your backups under a normal user account on the backup server (strongly suggested to do that!) the operating system will honour the space reservation percentage. Otherwise, it will not.

Side note: file permissions and ownership is preserved in the metadata files inside the rdiff-backup-data directory at the backup server. No need to have them synchronized by using the root account on the backup server to preserve this info. In fact, if your backup server has other username<->uid mapping than the machines you are backing up, things would get unexpectedly different anyway. Restoring a backup (using the root account at the device that is being restored to!) will automagically restore permissions and ownership.

I'd like to store an additional copy of the backups on a remote
system.  Would it be best to rsync between the USB hard drive and the
remote system?

What happens if a file changes while rdiff-backup is reading it?

You could indeed rsync from USB hard drive containing rdiff-backup backup tree to the remote system. Just make sure you either run rdiff-backup or rsync at the same time. Running rsync from USB drive to the extra remote system will not interfere with a running rdiff-backup session, but the copy on the extra remote system will be uselessly out of sync and not usable to restore using rdiff-backup.

If a file changes while rdiff-backup is reading it (on the server/laptop being backed up, naturally), it will detect this when doing the final checksum, emit a warning, and skip that file. Effectively it will be treated as unchanged.

This is somethat different from rsync, which will try to recover and retry to sync the file, but will eventually fail to sync the file if it keeps changing. Both approaches make sense, it's just a matter of taste ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]