Jeffrey J. Kosowsky wrote:
> 
>  > > Except that I have a lot of other stuff on my filesystem so I don't
>  > > want to image the whole filesystem.
>  > 
>  > That just takes some sensible planning...
> 
> Needs change, systems grow, systems added. Not all of us can afford to
> start with a lifetime of disk space... Not all of us have perfect
> foresight when we set up the system the first time...
> 
> Suppose I want to change filesystems (say move to ZFS), exactly how do
> I do that now other than to do a file copy operation including hard
> links that could take the better part of a day or more, assuming it
> doesn't crash or slow to a crawl due to memory constraints.

The easy way is to build a new one the way you want while keeping the 
old one around for as long as its history is relevant.  Or, if you have 
been making offsite copies and are prepared to access them, just use 
that for your history or emergencies while the new one fills in.

When I've done this sort of thing I've usually used rsync (-aH) to copy 
a few of the individual pc directories that are backed up over slow 
remote links and not worried about their pool entries since the new 
drive was large enough and I'm assuming that the pool will fill in and 
the old entries will expire in a few weeks.  The local machines can all 
complete full backups over a weekend so if I start on a Friday, 
everything is on the new drive by Monday.

>  > > I just want to image the
>  > > backups. Also, not all filesystems support efficient methods for
>  > > imaging a partially filled filesystem.
>  > 
>  > Why is it that you are concerned about efficiency here, but not in your 
>  > mythical database system?
> 
> I'm not talking about marginal efficiency. I'm talking about there not
> being a *practical* way to replicate a large Backuppc pool  in any
> reasonable amount of time given the number of hard links other than
> imaging the entire filesystem.

But what's the objection to imaging the filesystem?  It works.  And 
anything up to 2TB can be imaged to a single disk that you can toss in 
your briefcase, ready to go anywhere.

>  > Somehow I don't see how having to install, tune, and maintain an 
>  > otherwise unneeded database fits into the concept of abstracting away 
>  > functionality.  You have to live with filesystems anyway so you might as 
>  > well learn how to manage them.
> 
> I don't see the any major requirement for tuning and maintaining a
> metadata database unless you are doing huge enterprise size backups.

But I don't need a database at all - or to deal with any of the things 
that can go wrong with one.  It's a lot more complexity than just 
mounting a partition in the right place.

-- 
    Les Mikesell
      lesmikesell AT gmail DOT com

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
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/