Hi,
All good points below, thanks!
We use UW-Imapd with mbx mailboxes. That means a user's inbox is 1 file.
Users can also store other mail folders on the server, but it's not like
maildir where every message is a new file. This can lead to problems when
a file changes while it's being backed up, but that happens in our current
backup environment also.
We currently use Legato and do only full backups. That's because, due to
the way the mail is stored, a lot of files change every day. Incrementals
were using 70% of the storage, and taking longer than fulls because of the
extra processing time. I see rdiff-backup as a way to cut down
significantly on the amount of space being used for incrementals. I'll
have to weigh the pros and cons.
--
Thanks,
Michael
On Sat, 11 Nov 2006, roland wrote:
Hi !
how many files ?
what type of files? (many small ones, some large ones like database backing
store...)
what backup stragegy? (1xfull, 6xincremental in a week? )
could you perhaps describe your current backup strategy ?
it´s important to put backups with mission critical data to offline media.
harddisks and a "write backup to harddisk"-tool alone may be not safe enough.
also important is to do recover tests at some interval.
furthermore, you have no guaranteed support with rdiff-backup, i.e. if you
get a real problem, there is no warranty that you get proper help.
unfortunately the main developer is quite inactive and i have seen the one or
other questions/problems on this list being unresolved due to lack of people
helping or lack of knowledge about rdiff-backup internals.
the positive thing is:
rdiff-backup and especially the backup format is "understandable" - i.e. you
can investigate into it yourself if you have some programming skills.
the latest backup is always a 1:1 copy of your original data (like rsync),
which can be recovered without rdiff-backup working at all.
furthermore, you can restore older files without rdiff-backup if you have
understood how files being stored (reverse diffs) , so you can recover single
files from the backup repository with nothing more than rdiff utility.
rdiff-backup is great, no question, but you should think twice and do lot`s
of testing before, especially run-time tests.
rdiff-backup's "processing overhead" for each file is significant, so you may
get into "timeslot trouble" if you have millions of small files.....
regards
roland
----- Original Message ----- From: "Michael Simms"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, November 10, 2006 10:53 PM
Subject: [rdiff-backup-users] rdiff-backup for email
Hello,
I'm new to the list, and to rdiff-backup. We're looking at alternatives for
backing up email. It's currently 3TB, and growing quickly. Is anyone out
there backing up email, or other 'mission critical' data with rdiff-backup?
--
Thanks,
Michael Simms
Computing and Networking Services
University of Toronto
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
--
Michael
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
