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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
