Here is an important point.  Using SQL to store metadata opens up the platforms backuppc can run on.  Considering that no filesystem is ideal for backuppc because of the mix of I/O intensity, hardlinking needs, and operating system support) it would be very nice to de-couple backuppc from the filesystem.  If an effort was made to put metadata on an SQL database, you could even pick and choose your database based on preference and performance.  You could pick a filesystem that was best suited to the data you planned to backup. 
 

how about small but incredibly fast I/O SSD drives for the database!  SSD are just too expensive to use with backuppc right now unless you can use ZFS and use them for cache drives(which is extremely playform limited)
 

How about much much easier PHP work getting backup info and a faster backuppc interface only having to hit the database for all its info and not having to touch the filesystem.   I would say that a lot of the security bonuses CAN be done now but in a much more complicated way.  I want to be carefull not to make this a backuppc bash session because it is a great utility.

One of the biggest concerns with backuppc that is constantly discussed on this list is syncing the backup data between two or more servers.  Simply reducing the file count by eliminating the hardlinks would allow rsync to be used reliably and effectively.  SQL replication can keep metadata updated constantly and a watchdog that monitors the SQL for changes could keep the filesystems that store data synced easily as well.  Once the metadata and config moves to a database, so many things become very easy.  A single backuppc server could handle many more concurrent backups because multple data storage devices can seperate IO and relieve the pressure on the IO system of the OS.


I think if we can get enough support for a hybrid solution we may be able to get developer support for this in backuppc4.