On Tuesday 19 August 2008 20:46:33 David Boyes wrote: > One suggestion might be to implement a backup object versioning scheme. > In most cases, the most active data in the system is the current version > of a backup object. What if we retained the current table structure for > the most recent version of each object, and moved any previous version > to the per client tables Kern has suggested. > > This would allow most of the common scripts to continue to work as is > (most of them are really concerned with the most current versions of the > data), and a view could be defined to provide a similar structure for > scripts working on older versions of files w/o impacting the current > performance for real-time backup processing. > > This would clearly hit the expiration processing and restore processing > (in that both would have to become aware of versioning) , and expiration > would have to be aware of the difference between whether this was the > last copy of an object or not, but I think that would be overall > valuable as well as solving this particular problem.
I am not sure how this is different from what I am proposing other than I am suggesting to let the user define a new time period (or if you really want # of backups or versions) after which the File data will be moved into a less active "OldFiles" table. The exact details or methods chosen to move the records can certainly be discussed, and we may implement several. What I would like to make sure is that the concept is sound ... ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
