Re: NFR: store backuppc attributes in a database

Filipe Brandenburger <[email protected]>
Newsgroups gmane.comp.sysutils.backup.backuppc.devel
Message-ID <[email protected]>
Hi,

On Tue, Jun 2, 2009 at 17:03, Peter Walter <[email protected]> wrote:
> This is just a summary of the proposals. Les Mikesell has been
> eloquent in his defense of the way backuppc operates now.

+1 on keeping things as they are.

I am currently migrating my backups from Bacula to BackupPC, my main
motivation for doing it is the fact that BackupPC does not use a
database backend for metadata.

> To clarify, what we are talking about here is not storing the backed-up
> files themselves in the database, but only the metadata, such as the
> hardlink information and other attributes, in the database. In addition,
> I see this functionality as an extension and addition to the current approach.

Storing metadata on a database is a problem when you have millions of
small files. This is my current situation. On Bacula, even to restore
one file, I have to wait for it to scan all the backup images and load
them from the database, only for it to be able to show me a directory
tree... It's silly, considering that you could "just" use a directory
tree to show the user a directory tree.

I used to use Symantec NetBackup in another company, and it had the
same problem, it took ages to browse backup images containing millions
of small files. Not to mention that more than one time I had problems
with corruption of the metadata database and it was a pain to fix
them...

And, in a disaster scenario, where your BackupPC is no longer working
(doubtful that it will happen if you don't have a database), if you
have all the files in a filesystem, you can always use BackupPC_zcat
and script it so that you can recover the contents of files.

> I would ask anybody interested to review the discussion thread
> for "Backing up a BackupPC server" on the backuppc-users
> list that was started today.

I didn't receive any e-mails on that thread... I will review my
subscription options to see if something is wrong with them.

In any case, I am currently using BackupPC to back files up directly
to USB attached external drives that I send off-site. Every week I
rotate the disks.

I just bought some big disks to a spare server I have, I plan to
create a local RAID5 volume to use as the BackupPC main repository and
leave BackupPC working there on the local disks. To do my off-sites, I
plan to use rsync -aH to duplicate that data into the external USB
disks. If I need to do disaster recovery, I can just install BackupPC
on a machine, then point the repository to the USB disks and restore
directly from there. Simple & easy, failproof.

If you really want to go on with this idea of changing things to add a
database, I suggest a fork of the project that would explore this idea
while the original product evolves in its original path. That way, if
you can really prove that you can come up with a database design that
will not kill the performance of restores, and in a way that I don't
need to worry about database backups, and if I lose the database I can
still restore everything, I might consider switching. Good luck with
that, though...

Cheers,
Filipe

------------------------------------------------------------------------------
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-devel mailing list
[email protected]
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-devel
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.