Topic: Support extensions to backup restore_list

[pkn]

Support for server modification and third-party development could be improved if an administrator or application developer could define additional files and directories to be included in an SME Server backup (via db tuning).   Currently that list is defined in the system file /usr/lib/perl5/site_perl/esmith/Backup.pm.

[gordonr]

Support for server modification and third-party development could be improved if an administrator or application developer could define additional files and directories to be included in an SME Server backup (via db tuning).   Currently that list is defined in the system file /usr/lib/perl5/site_perl/esmith/Backup.pm.

Why not just copy the files into /home/e-smith/<something> in the 'pre-backup' event, and do whatever you need to do in the 'post-upgrade' event, which is called after a restore?

Or better, store the relevant files under the existing trees.

There is a very real chicken and egg problem here. If files have to be restored from "other" places, how do you know which other places they are until you've restored the dbs?

[pkn]

Why not just copy the files into /home/e-smith/<something> in the 'pre-backup' event, and do whatever you need to do in the 'post-upgrade' event, which is called after a restore?

Writing event actions to copy/backup/delete is more work than would be the case if we could simply specify additional files/directories for inclusion in an SMe Server backup.  And it may require considerably more disk space.

Or better, store the relevant files under the existing trees.

In some cases it will be hard convincing application designers to place stuff in /home/e-smith/ rather than something more generic, like /opt/app/.  

There is a very real chicken and egg problem here. If files have to be restored from "other" places, how do you know which other places they are until you've restored the dbs?

It doesn't appear to be an issue in desktop backup because we're simply restoring the contents of the backup, we're not referring to a defined list of directories and files.   I can see this being a problem for tape.

Can the restore process not refer to some config db within the restore itself for that user-extensible list?

[gordonr]

It doesn't appear to be an issue in desktop backup because we're simply restoring the contents of the backup, we're not referring to a defined list of directories and files.   I can see this being a problem for tape.

Can the restore process not refer to some config db within the restore itself for that user-extensible list?

No - that's the chicken and egg issue. We restore the config dbs from tape/desktop backup, so we may lose the config values you need.

And if we did read them out of the backup, we'd need to read the backup twice, which we can't do as we read it as a stream. To read it twice, we'd need to copy it to the server before restoring, which would further limit the size of the backup file.

There is also a security issue of an extensible restore list. We intentionally do not restore any directories which might contain executable code.

I think one of the options I outlined will provide what you need. Have a look at the MySQL db dump/restore as an example. We dump a text copy of the db so that we can restore it later.