Re: [BackupPC-users] Problems with hardlink-based backups...

/// > > But a program should not be dependent on volume management. Volume

> > management is a general tool that can be helpful but should not be
> > required.
>
/ > 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.

There would be no need to rsync SQL databases, simply replicate. And I agree that a database file is drastically easier to migrate than a filesystem with millions of files.

>
> Your reply is probably "but I can add more filesystems to work with the
> database method" -- but I can simply add more volumes to my existing
> filesystem. It's the same operation in both cases, with the same
> complexity, yet in your scenario, now I need yet another component to
> maintain that can fail (a database).

Adding more filesystems to your system requires volume management and is hardware to maintain than a database. You are forced to add drives in pairs for redundancy or not have redundancy or use some other non-trivial method of handling redundancy in a filesystem. With a database you can put each individual table on a different filesystem and use a simple softlink to access it. Additionally, if you were just using the database for metadata then you would likely never grow it enough to need to expand the storage the database sits on. Because you can easily store file paths in the database adding storage can be done very easily as a single like in the config could say to save new files to the new filesystem and without hardlinks there is no concern about where the file sits as it could easily be on a completely different server. Because the database would handle the IO and it would be mostly cached, the IO of the storage would cease to be a major bottleneck.

> > In fact, personally, I have never seen a non-enterprise
> > piece of software that so clearly required it's own dedicated
> > filesystem along with volume management.

look harder. exchange and active directory are tied very tightly to NTFS. Many AIX apps are tied to the filesystem. Digital unix(tru64) apps are tied to Advfs and specific attributes. Solaris is moving towards a total reliance on ZFS.

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)?

Cant or shouldnt? How about a Windows server? it is technically possible but not ideal to backup at the file level. Can <> Should.

Keep in mind that the whole idea around backuppc is de-duplication which is not easy to do at the filesystem level. The use of hardlinks is one method. Alternatively you could do it with a special filesystem on block devices. You could do it in fuse if you so desired but performance would likely be pretty bad. I think that the 2 best solutions are the hardlink method that is in place down or the hybrid database/filesystem solution that is floating around.

------------------------------------------------------------------------------
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 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/