rdiff-backup-users
[Top][All Lists]
Advanced

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

[rdiff-backup-users] Some thoughts and questions for a "large" rdiff-bac


From: Erik Forsberg
Subject: [rdiff-backup-users] Some thoughts and questions for a "large" rdiff-backup setup.
Date: Thu, 14 Aug 2003 19:49:49 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux)

Hi!

I'm thinking about using rdiff-backup to implement a backup solution
for the Academic Computer Society I'm a member of. We're talking 500+
members, each with their own home directory, a mailserver with
mailspool, web server with webdisk and a bunch of other disks that
needs backup. All members have Unix shell access on a variety of
Hardware/Operating system combinations (Solaris, Linux, AIX, HP-UX,
Tru64, UNICOS, you name it :)  ).

Finding the hardware to store the data on is no problem. 3ware
HardwareRAID for SATA-disks or even software RAID under Linux can
solve that problem.

I'm having more questions about the actual setup of
rdiff-backup. I want the users to be able to read their backups
themselves, including increments. This means I can't just do 

rdiff-backup /home backupserver:/home

since the rdiff-backup-data directory by default is readable only by
root. Also, I probably don't want one user to be able to read the
backup directory of another user, since if one user finds he/she has
the wrong permissions on a file (readably by all, for example), it
should not be possible to read that file from the backup directory
until the next backup.

My workaround here could be to run rdiff-backup once for each user,
backing to a directory where only the user can read. Comments on this?
I have to admit I'm not *that* happy about having to run 500+
rdiff-backups each night, each as it's own user. Trying to parallelize
it could be a nightmare. Better ideas?

On a different side, wouldn't it be nice if rdiff-backup could
auto-clean it's destination directory when it's getting full. That is,
it would be nice if you could specify to rdiff-backup that it should
use up to a specific amount of diskspace in the destination directory,
and if a new backup doesn't fit in, it should try cleaning one day of
backups. 

I guess this isn't that easy to implement, especially since you don't
know how much space a new backup will occupy. Ideas on solving this
problem?

Another feature that would be really nice on this system would be to
have .nsr-lookalike-files. For those of you not familiar with
Networker, .nsr files are a way to specify how to handle a specific
file, a specific directory or a specific directory and all its
subdirectories. By putting a file named .nsr in a directory, you can
for example say that the subdirectory 'trash' never should be copied
to the backup, or that a specific logfile should be ignored. Are there
any plans for such functionality in rdiff-backup? How hard would it be
to implement? (We might be able to help, we love Python :)  ).

Another idea I had for this setup was to set a quota on the amount of
backup space a specific user could use, and then let the user
him/herself choose how many days he/she wants the backup to cover by
adapting what directories should be copied (using a mechanism such as
the one above, the .nsr-file-lookalike one).

Any thoughts and comments on this? Are there any installations like
this running?

\EF
-- 
Erik Forsberg                 http://www.lysator.liu.se/~forsberg/
GPG/PGP Key: 1024D/0BAC89D9




reply via email to

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