Ok; I try a conclusion.
- At least for old versions of RelStorage, the "restore" (FileStorage --> RelStorage) is slow. Not necessarily as slow as in my case, but much slower than "saving" the RelStorage to FileStorage.
- This fact makes
zodbconvert
(for such cases) nearly useless as a backup method -- you'd rather not wait so long for the restore to complete. - Instead, the RelStorage database should be backed up and restored using the native database utilities.
That's a pity, because a zodbconvert
run could be integrated easily in the backup configuration (as a pre_command
) -- to feed the resulting export in the further backup -- but I couldn't find a way to integrate the backup of sql dumps there.
Nor to restore relational databases;
I still need my own home-brewed backup and restore to integrate this.
(Yes, I can integrate a script which creates the backups and copies them somewhere, but it won't be connected in any way to a certain dated recipe-created backup).
This makes me seriously consider to replace my current RelStorage setup by ZEO.
The reason I didn't do so in the first place:
- I inherited a non-ZEO setup
- which included a supporting PostgreSQL database already anyway,
- and the UnifiedInstaller creates such a very different structure for
zeo
than forstandalone
that I never really looked into converting.