> 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. The
> device also does not support LVM. I do not want to have copy a whole
> 1TB partition just to copy over a few hundred GB of backuppc
> data. Second, at some point, I may want to move the pool to another
> drive or server and I don't want to have to fiddle with low level block
> copy and partition resizing in the hope that I can get it right
> without making mistakes in either the partition itself, the underlying
> LVM setup, or the further underlying (software) RAID setup -- I have
> done this manually before and it takes real care to get the sequence
> right and not do something stupid.

While I'm not sure I'd go so far as to call a consumer NAS a fringe case,
it's certainly limits your options.  I suspect that the majority of
BackupPC users put their backups on a file system with some measure of
redundancy and leave it at that, rather than take the additional step of
copying the backup elsewhere, and those who do have no doubt architected
their hardware and software to handle this extra step.

In other words, I'd suggest that working around the limitations of your
consumer-grade NAS is probably beyond the scope of any backup system.

> Finally, at a minimum, the installation document for BackupPC should
> clearly warn users to use a dedicated partition with LVM for TopDir if
> they want to have any hope of practically backing up, transferring, or
> expanding their backup directory in the future.

I call shenanigans.  I'd suggest that it's beyond the scope of the
documentation of a backup solution to provide a basic education on LVM,
nor, frankly, is LVM the only solution, nor is it available on every
platform on which BackupPC runs.

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

I'm going to have to object to your use of the term "kludge" here.  If
you're referring to hardlinks, they're a basic feature of file systems,
and I don't think actually using them for their intended purpose (i.e.,
pointing alternative directory entries at identical files) can be fairly
characterized as a kludge.



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