Over on the backuppc-users list, there has been a lively discussion on a query I made on how backuppc could be ehanced to store metadata in a database, in addition to using features like hardlinks; the idea being that one could then back up the pool and the database, but not the hardlinks, which would allow backuppc to backup other backuppc servers using standard technologies. I suggested that the database could at first supplement, and eventually obsolete the requirements for the file system to have hardlink support, which would enable 'cloud' storage to be used for backups, among other things. It turned out that Jeffrey Kosowsky, and other contributors, had previously suggested something along those lines. In particular, Jeffrey Kosowsky said:
> On the other hand as I and others have mentioned before moving to a > database would add the following advantages: > > 1. Platform and filesystem independence -- BackupPC would no longer > depend on the specific hard link behaviors of linux and associated > filesytems. > > 2. It would be easier to extend the attrib notion to store extended > attributes whether for Linux (e.g., selinux attributes), Windows > (e.g., ACL attributes) or any other OS. > > 3. The pool could be split among multiple disks and filesystems since > it would no longer depend on hard-link behavior > > 4. Backing up BackupPC backups would be much easier and faster since > you no longer would have hard links to worry about -- just backup > the database and any portion of the pool that you want to. > > 5. The whole system would be more elegant and extensible since all > types of metadata could be stored in the database rather than being > stored in various files in the BackupPC tree. For example, > - You wouldn't need the kludge of file mangling > - Checksums could be stored in the database rather than being > appended in a non-standard way to the end of the file > - File level encryption could easily be added > - Alternative file-level compression schemes could easily be > supported. > - The host-specific config data (and maybe even all the config > data) could be stored in tables rather than in individual > config files > - The 'backups' file could also be stored as a table > > 6. Presumably a database architecture would also make it easier to > have more granular control over user access and permissions at the > feature and file level. This is just a summary of the proposals. Les Mikesell has been eloquent in his defense of the way backuppc operates now. 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. 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. What do the developers on this list, particularly Craig, think of this proposal? Peter ------------------------------------------------------------------------------ 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 BackupPC-devel@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
