On 29/10/2007 Sam Stainsby wrote:
To quote Andreas Jung:
"An inconsistent copy of the Data.fs is not the problem since invalid transaction entries will be discarded by the ZODB."
That's the theory. But why trust a higher risk strategy, when there is a perfectly good tool for doing full and incremental backup that produces a compact and timestamped backup files as a coherent set of files in a backup repository? Not using it is just laziness. What happens, for instance, if by coincidence the database is being packed by some automated script at the same time as your automated backup occurs?
You're right. I just have to find a way to implement it in the backuppc backups. It would be awefull if the 'restore' function from backuppc would still work for Data.fs directly, but that's only possible if the backupped Data.fs from repozo.py is stored as instance/<name>/var/Data.fs in backuppc. I doubt that this is possible in an easy way. I'll see. But for sure something has to be changed ;-) ... jonas