BackupPC-users

Re: [BackupPC-users] Problems with hardlink-based backups...

2009-08-30 23:09:26
Subject: Re: [BackupPC-users] Problems with hardlink-based backups...
From: Les Mikesell <lesmikesell AT gmail DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Sun, 30 Aug 2009 22:06:19 -0500
Jim Leonard wrote:
> dan wrote:
>> One of the biggest concerns with backuppc that is constantly discussed 
>> on this list is syncing the backup data between two or more servers.  
>> Simply reducing the file count by eliminating the hardlinks would allow 
>> rsync to be used reliably and effectively.  
> 
> It's almost as if you guys haven't heard of filesystem-specific dump 
> utilities.  For such utils (vxdump, ufsdump, zfs send/receive, etc.) the 
> number of hardlinks isn't a problem.  You can do both full and 
> incremental dumps, even across separate machines.  This isn't a problem 
> that needs solving.

Time it before saying that.  Zfs send/receive might be usable since it works 
strictly at the block level even in incremental mode.  I believe the other 
tools 
all have to map old/new inodes in a way that will take days to complete a 
restore of anything resembling a typical backuppc archive.

> I feel like the whole "we need an SQL/hybrid" solution discussion is 
> happening because you aren't aware of better ways to do things.  Just 
> because a filesystem is a database doesn't mean it would be "better" to 
> replace it with a "better" database.

While I'm not convinced that sql is the answer, there is a problem when you try 
to replicate a heavily hardlinked filesystem.  Filesystems are optimized for 
looking up filenames, and some optimize content access by directory.  They 
don't 
provide a good way to track 'other' links so you can duplicate the structure.

> For anyone thinking that working with giant multi-gigabyte BLOBs in a 
> database is the right way to go, I suggest you actually attempt it 
> yourself and see what happens.  I'm backing up my HD video production 
> rig with BackupPC, and although such a machine (Windows, 16T of storage, 
> most video files are at least 50G in size) is outside of the intent of 
> BackupPC, it actually works.  If BackupPC were to rely on an SQL 
> database, it would greatly shrink the potential userbase.

A few big files aren't nearly the same problem as millions of tiny files in 
terms of tracking links.  Think about a bunch of users with large maildir 
mailboxes, for example.  Backuppc handles this pretty well itself, but it 
presents a big problem if you try to copy its filesystem with something that 
needs to keep a complete table of filenames and inode numbers to track and 
duplicate the links.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>