On Mon, Aug 31, 2009 at 3:23 PM, Jeffrey J.
Kosowsky<backuppc AT kosowsky DOT org> wrote:

>
> I really fail to understand the dogged resistance to finding a viable
> solution to a well-known and repeated issue with BackupPC that does
> not rely on filesystem level kludges. I could see if this were given
> as a temporary workaround but why should we continue to see this as
> the ideal solution rather than trying to work on a more robust and
> comprehensive solution even if it falls to a long-term roadmap item.
>

I don't know who started calling "hard links" a kludge, but I hardly
feel the characterization is accurate.  Use of hard links to reduce
disk usage dates back to the inception of hard links.  It's not a
kludge, its an established feature of unix based filesystems.  Saying
BackupPC's use of hard links is a kludge is like saying the use of
standard filesystems to store files is a kludge.  Try suggesting to
the Unix community that hard links need to be removed because their a
kludge and the response would look similar to a DDOS attack on your
email account.

The argument for a SQL based vs. flat file based meta data is
definitely a valid discussion and it has no answer until you come up
with a list of requirements for your meta data and match it to a
technology.  I feel use of DB Blobs to store file content would be a
tragedy.  If someone wants to argue this, then lets have that
argument.  SQL DB to store config information has potential merit, but
I think it could be argued multiple ways depending on what you value
as important (ease of configuration via "vi" vs ease of third party
tools to read, understand, modify config info).  SQL DB to store file
meta data has potential, but assuming it would be faster / more
flexible than other methods is to avoid the exercise of determining
what is important.

SQL is one of many storage solutions.  It has strengths and
weaknesses.  Lets make sure we understand all the options and match
technology strengths to the requirements.

Lastly, we wouldn't be having a discusion about replicating the
backuppc server if backuppc wasn't as stable and robust as it is.
BackupPC must first and foremost be a reliable and trustworthy
repository of backup data.  It having the ability to replicate itself
for "DR" purposes comes second.



-- 
Jonathan Craig

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