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

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

Re: [rdiff-backup-users] New User Seeking Some Clarification


From: Alan
Subject: Re: [rdiff-backup-users] New User Seeking Some Clarification
Date: Fri, 9 Jan 2004 13:35:37 -0800
User-agent: Mutt/1.5.5.1+cvs20040105i

On Fri, Jan 09, 2004 at 12:15:28PM -0500, Chris Young wrote:
> I am a new user and have a couple of questions I hope someone will be
> willing to take the time to answer.
>  
> I have read all the documentation I can find but I want to be sure I
> understand how rdiff-backup works.
>  
> As I understand it, rdiff creates a mirror directory which is not
> compressed or altered in any way from the source with the exception of
> adding the incremental information in sub-directories.
>  
> Then as I subsequently run rdiff it automatically updates the main file
> list with the latest files and then moves or copies previous versions of
> those files to the sub-directories containing the incremental data which
> is compressed.
>  
> And then I have the option of telling rdiff to go and delete incremental
> data from a certain point in time if I choose.

Yup, that's pretty much exactly how it works :)

I'm just a user, but I'll try to help out with your questions as best I
can.

> 2. Can you restore to the file level or just the directory level? And
> can you backup to the file level or just the directory level?

Yup, you can back up a directory, file, or a selection thereof, same as
with restore.  See the FILE SELECTION section in the man page for
details about how to include/exclude files or directories or dir trees.
This is probably the hardest part of setting up your backups IMHO, but
it's not *that* hard.

> 3. It seems that rdiff doesn't need any special runtime parameters to do
> an incremental backup. It seems automatic. Is that correct? I just
> backup from the same source to the same target as my first backup?

Exactly.  Rdiff-backup will read the rdiff-backup-data directory and see
when the last snapshot was and go from here.  

> 4. I am backing up web servers to a remote backup server with this so I
> need daily backups with at least a week worth of incrementals. This
> seems to easy. Does anyone have any practical advice for this type of
> scenario? Anything I need to take precaution of or anything special I
> should do. I am worried that until I have a fatal crash I won't really
> know how good or bad my backup solution is.

I'm sure there are books written on this subject, but my backup script
looks something like this:

rdiff-backup $INCLUDES --exclude / / address@hidden::/backups/server
rdiff-backup --remove-older-than 7D --force address@hidden::/backups/server

First backup specific files ($INCLUDES) from the root of the filesystem
(/) but not all of / (exclude /) to the backupserver.  Then remove any
backups older than 7 days.  

Obviously some things have been snipped out, but after watching it for a
couple of days to make sure it was doing what I wanted, it just keeps on
going and doing what I want :)

When I have had a crash I cheat a bit and just copy the entire directory
(excluding the rdiff-backup-data) directory back onto the server and I'm
back in business (I actually have a local backup and a remote back up so
I didn't have to scp all the files back).

> 5. I have Plesk (a web server administration software package) installed
> if anyone knows what that is. It has a dump utility with it but I would
> have to come up with my own rotation scheme to work out incremental
> backups. Anyone have any experience comparing dumps with rdiff.
>  

What data is dumped?  Rdiff-backup can do diffs of binary or text files,
so it'd be able to diff the dumps fine. 

However, I found a bit of a gotcha.  When I moved from tar/scp to
rdiff-backup I was dumping my database everynight to a .sql file and
then bziping it and including that in my nightly tar.  When I moved to
rdiff-backup I left it like that until I realized that because of the
bzip the .sql file was completely different each time, so the entire
file was transfered as an increment.  When I removed the bzip part of
the process the base file was larger, but the increments were much
smaller because they were simply text diffs of new/changed data, not a
binary diff of an entirely changed file.  Something to think about
anyway.

alan

-- 
Alan <address@hidden> - http://arcterex.net
--------------------------------------------------------------------
"There are only 3 real sports: bull-fighting, car racing and mountain 
climbing. All the others are mere games."                -- Hemingway




reply via email to

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