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