Jeffrey J. Kosowsky wrote:
> > BackupPC isn't "dependent" on volume management more than any other
> > program. Volume management is simply one way to get around the
> > limitations of storing more data than a single device will allow. Do
> > you think that expanding an SQL database would be different?
>
> It would be *very* different since you can easily copy a SQL database to
> another disk while due to the large number of hard-links, copying pool
> data is not practical except at the block filesystem level. In fact,
> rsync works very well with SQL databases.
If you're using rsync to copy database files while they're still open,
you've completely invalidated your argument.
> > Then I would suggest you haven't seen enough software. Backup systems
> > are not trivial systems, and it should be implied that you would never
> > set them up without consulting their operation and requirements.
>
> OK since you are such a software expert, name 5 common pieces of
> non-enterprise, user-space software that can't be backed up at the file
> level and instead needs to be backed up at the block level (which
> in turn pretty much implies the need for a dedicated filesystem for
> that data only)?
Now it is you who is using the straw-man argument, because backuppc
*can* easily be backed up at the file level. You just don't like how
long it takes and/or that it doesn't work quickly with your favorite
utility. I have already mentioned that your filesystem's "dump" utility
works perfectly well for copying your filesystem, hardlinks and all,
ACLs and all, to another filesystem/file/tape/whatever. I think you
should actually sit down and use it before making claims that backuppc's
pool isn't copyable using normal methods.
Here's a handy tip that doesn't even require temp space:
dump 0f - /pool | (cd /newpool; restore f - )
Oh, wait, you want to restore to a completely different machine? Over
the public internet? Using compression and encryption? Here you go:
dump 0f - /pool | ssh -C u...@remotemachine "cd /newpool; restore f -"
And if you don't want to do a full dump ("0") then just use an
incremental value (1, 2, etc.).
Now we can get off of the silly hardlinks suck/can't-be-backed-up
argument and return to whether or not attrib should be turned into a
database.
--
Jim Leonard (trix...@oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
