Re: Recommended Linux Backup
Paul E Condon wrote:
> On 20091030_010001, lrhorer wrote:
>> Alex Samad wrote:
>>
>> > On Fri, Oct 30, 2009 at 01:37:51AM +0000, Paulo A.B. wrote:
>> >> It's based on Rsync, but has a different flavor.
>> >>
>> >> Try ribs <http://www.rustyparts.com/ribs.php>.
>> >
>> > Or have a look at rdiff-backup
>> This doesn't sound to me as if it fits the bill, either. It sounds
>> closer than rsync, but I didn't read anything about changing drives
>> or
>> maintaining an index. Rather, it sounds to me as if it merely
>> creates
>> directories with diff files on them on a single remote target. This
>> strategy won't work when one's targets are much smaller than the
>> array
>> being backed up. I haven't seen any 20 TB drives for sale, so this
>> backup and restore has to span multiple target drives, all but one of
>> which are offline at any given time.
>>
>
> I can't remember the details of your original post, but I remember
> reading it.
Then please go back and read it.
> Given your responses to several suggestions, I suggest
> that you should reconsider rsync, but not in the way that you seem to
> have been doing. I use rsync as for the core functionality of a backup
> system that I have implemented with a few dozens lines of bash
> scripts. My backup system is very compact and does exactly what I want
> for a cluster of four hosts. I didn't offer it, because it doesn't do
> what you want, and, frankly, I remembered your specifications as being
> poorly thought out.
They are not poorly thought out. Rsync simply will not work, period:
1. When the device to which rsync is writing is full, rsync does not
pause and ask the user to mount a new device. This could be worked
around by using a script to break up the backup into chunks smaller
than the physical size of each drive, but that would defeat the whole
purpose of using rsync. It also destroys the ability to perform
incremental backups.
2. In order to create the list of files to be archived, rsync compares
the list of files in the source medium with the list of files in the
target medium, copying any missing files to the target. Since in this
case the mounted target will never contain more than 2TB or at most 3TB
of files, rsync will inevitably try to copy the other 20 or 30 TB of
files every time. It has no way to look up the contents of the 10 or
15 offline hard drives.
> I think there are a lot of different ideas as to what a backup system
> should do. It was a useful learning experience for me to write my own.
> My reading of your responses is that it might also be a useful
> learning experience for you to write your own. If you embark on such a
> project, I think you should not start from scratch with a C++
> compiler, only. Rather you should take rsync as a functioning,
> debugged module that you can incorporate into your system to handle
> the great bulk of the low level detail work. But I would fault rdiff
> or tar, or some other well known software as a starting point.
I do nothave the time, resources, or inclination to undertake such a
project. I have thought about it, but at this juncture it is just not
practical.
Reply to: