Hi,
first of all, could you all please write just a little bit slower? :)
Les Mikesell wrote on 2009-06-02 16:10:41 -0500 [Re: [BackupPC-users] Backing
up a BackupPC server]:
> Peter Walter wrote:
> > Les has been a strong advocate for his position. However, backuppc as it
> > is currently designed does not meet my need to remotely backup all kinds
> > of computers, including other backuppc servers.
I honestly doubt that a BackupPC pool is something you would want to backup
with BackupPC just like any other set of files. For one, you're compressing
already compressed content. Then, you are pooling that with normal content
(which is unlikely to give any hits). Finally, you can do practically nothing
sensible except restore the complete thing. Do you really want a backup
history of a BackupPC pool? Would you not prefer the ability to access
individual files *within* the pool? You *might* want to restore the complete
pool if something goes wrong, but you might just as well (need to) start off
fresh in such a case and just want to keep the history (meaning *one history*,
not a history of histories).
> > I think the
> > enhancements Jeffrey Kosowsky and I have outlined in this discussion
> > would solve my problem, as well as a number of other problems, would
> > significantly extend the functionality of backuppc, and also make it
> > compatible with other platforms.
The one basic issue that everyone has so far been ignoring is that you would
need an atomic operation spanning database and file system. The link(2) and
unlink(2) system calls are atomic for free. I'm sure there are ways to emulate
such an operation, but I somehow doubt that is going to improve performance,
reliability and complexity.
Somehow I feel much better about many hardlinks pointing to one piece of
content than only one, to which only the database knows what it represents.
Just imagine what human or software failure (including the file system!) can
do with a couple of unlink(2) system calls in either case - not to mention
what happens if you clobber your database. Sure, you can
"cat /vmlinuz > /dev/hda1" just as well, but you at least need to be root for
that, which the BackupPC software is not.
Aside from that, you can't check the consistency of (database + FS) without a
special tool just for this purpose, because there is no innate relationship
between database content and FS content.
> > I am therefore going to take this
> > discussion over to the backuppc-devel and ask Craig what he and others
> > over there think.
Do you think that will differ from what they think over here?
The issue Jeffrey has been adressing - attrib files - is, in my opinion, just
one little (and maybe unimportant) part of the story. I don't see much
difference between implementing this as it is or with a database. If you're so
concerned about performance here (and not about storage requirements), store
attrib files uncompressed and unpooled. You'll waste space, but so will a
database. Why introduce a single point of failure?
The important step is reference counting, and that doesn't happen in attrib
files.
Regards,
Holger
P.S.: I don't really see why you would need to access several *attrib files*
for creating a view of one directory. The files are spread out, that
much is true, but shouldn't a single attrib file give you the whole
picture?
------------------------------------------------------------------------------
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/
|
