BackupPC-users

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

2009-08-31 16:44:44
Subject: Re: [BackupPC-users] Problems with hardlink-based backups...
From: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Mon, 31 Aug 2009 16:41:41 -0400
Les Mikesell wrote at about 15:08:24 -0500 on Monday, August 31, 2009:
 > Jeffrey J. Kosowsky wrote:
 > > 
 > > This still is not a solution for all of us. First, I store the backups
 > > on a consumer-level NAS device that does not easily facilitate adding
 > > partitions without additional hacking and risks to data integrity.
 > 
 > OK, but when drives are available for around $100/TB these days, how 
 > much is it worth to deal with the limitations of some inflexible device? 
 >   And even the consumer-level devices should permit a disk replacement 
 > with mirror rebuild.
 > 
 > > I really fail to understand the dogged resistance to finding a viable
 > > solution to a well-known and repeated issue with BackupPC that does
 > > not rely on filesystem level kludges.
 > 
 > It isn't a matter of resistance.  It is just that no one has shown that 
 > any other scheme will work any better.  What you have to do is reduce 
 > the head motion necessary to access each file.  One pass across the raw 
 > device clearly does that.  A mix of sql and files might or might not. 
 > Throw in the need to verify/fix out of sync tables and I'd guess not - 
 > but I'd be happy to be proven wrong.
 > 
 > > I could see if this were given
 > > as a temporary workaround but why should we continue to see this as
 > > the ideal solution rather than trying to work on a more robust and
 > > comprehensive solution even if it falls to a long-term roadmap item.
 > 
 > Pushing the de-duping into the block level filesystem so the app doesn't 
 > have to do anything special is probably the next step but unless that 
 > filesystem also provides an incremental block-level backup method (like 
 > zfs send/receive) you still aren't going to like what has to happen in a 
 > file-oriented copy of what will appear to be 10x the size.  Or maybe 
 > solid state devices will become cheap enough soon so we won't have to 
 > think about seek times any more.

Copying/moving/resizing the Backup database is not my only or even
most important reason for advocating a real database solution. I think
I once gave a list of about 10 advantages of a database
solution. Also, I am not looking for the *fastest* way to backup/move/resize a
BackupPC system but rather a feasible way that works in cases where
you don't have a dedicated filesystem. If you are worried about speed,
you can always do a low level block copy in any implementation.

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