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 questions.


From: Dominic Raferd
Subject: Re: [rdiff-backup-users] New user questions.
Date: Fri, 08 Feb 2013 10:53:39 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

Hello Jason and welcome to rdiff-backup!

On 06/02/2013 20:07, Jason Sauders wrote:
Hello! I'm a new user to rdiff-backup and have been experimenting with it for the better part of two days now. It was recommended to me by another user who wondered why I was using rsync exclusively for backing my systems up. Considering rdiff-backup seems to keep an rsync-esque mirror of current data + old version archives it stands for good reason as to why this user questioned my current backup procedures.

I've since done a lot of reading on rdiff-backup, and so far I like what I see. On the main page here I see that there's a notation saying: A remote incremental backup of all your files could be as easy as
"rdiff-backup / host.net::/target-dir"

This is interesting, to say the least. I do have to wonder, even when you take into account what the disclaimer says about recommended excludes, is it actually "safe" to run rdiff-backup against a currently running root file system? Is it accurate to say that I can SSH into my Ubuntu Server 12.04.1 install and as root run rdiff-backup --exclude /media / /media/external_hdd and presto, my root drive is backed up (while ignoring media) and I can run rdiff-backup -r on a totally different HDD and bingo - I can be up and running? I just want to make sure I understand the context before I try something that might be detrimental.

I have never tried that, I have always used rdiff-backup for data backup, not for systems. The versioning that rdiff-backup offers is particularly valuable for data files that change over time. I kinda doubt it would work 'out of the box', too.


Question 2... rdiff-backup has to be installed on both the client and the server... I get that... but is it important that they be the same identical version? Will I run into issues if I'm trying to rdiff-backup an Ubuntu 12.10 systems to an Ubuntu 12.04 server?

It is advisable to have the same version, in practice you should use 1.2.8 (as I do) or 1.3.3. I am not sure if they will work together but why make it difficult by trying?


Question 3... I see that there hasn't been much development on rdiff-backup for a few years now. Is that due to the 70 updated releases fixing all of the bugs? Is that to say that the current version is rock solid stable? The fact that there's an experimental version that is seemingly untouched is food for thought to contradict that, though...

Development of rdiff-backup is dead because the previous maintainer went away and no one took over. Both 1.2.8 (stable) and 1.3.3 (unstable) are in practice stable and effective in many scenarios. There are situations where problems can arise, many of them involving a Windows destination, which are best avoided (you can backup data *from* Windows).


Last question - With my backup procedure, I only wanted to back up Documents and Pictures to my server. Since rdiff-backup includes everything by default, it appears as if the only way to make it work was to run --exclude '**' as part of the command. Is that exclude entry essentially telling the command "Exclude everything.... EXCEPT these two includes Documents + Pictures"? Or am I misunderstanding it? I just didn't see too much highlighted info about --exclude '**' so I wanted to run that by this list and see what you folks thought.

I'm not clear whether you mean you want to back up everything in your Documents and Pictures folders, or just some particular file types (docx, jpg etc)? If you just want to backup particular folders I suggest you create separate repositories for each folder. The --exclude-globbing-filelist option might help you too.

--
TimeDicer: Free File Recovery from Whenever

reply via email to

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