dbmail-incremental-export-import tool
Short
Export DBMail in a way suitable for incremental backup by standard backup tools, also simplify RDBMBS and DBMail flavours migrarting
Terminology
EEM - everything except emails.
Use RDBMS buitin incremental backup support
Pros: no development is needed
Cons: not all RDBMS support this; backup is RDBMS- and DBMail- dependent, so this will not always work with RDBMS and DBMail upgrade, will not help with RDBMS migrating
Another Approach
We can split the problem into 2 parts:
Export EEM using standard database export tools
Subsequent calls will overwrite EEM. Since the size of EEM is relatively small, should be perfectly O.K.
Pros: no special development needed
Cons: backup is RDBMS- and DBMail- dependent, so this will not always work with RDBMS and DBMail upgrade, will not help with RDBMS migrating
Export EEM using special (possibly XML-based) format
Subsequent calls will overwrite EEM. Since the size of EEM is relatively small, should be perfectly O.K.
Pros: backup is RDBMS-independent, so it makes possible to use it for RDBMS migration, RDBMS upgrade, DBMail upgrade and so on
Cons: import-export utilities must be created and maintained
Export emails to Maildir format
Important thing here is not to export the whole Maildir again and again, but only update it, deleting files with old mails and creating files with the new one. Here we can split export into two independent tasks again:
Pros: incremental backup will just work
Cons: requires huge amount of inodes
Export emails to Mailbox format
Optimization here should be the same as with Maildir - only new mails should be added, deleting of the old emails can be done more rare than injecting new emails.
Pros: less inodes comparing to the Maildir
Cons: performance sucks, adding one single email to the maibox will trigger backup of the whole Mailbox file
Export DBMail in a way suitable for incremental backup by standard backup tools, also simplify RDBMBS and DBMail flavours migrarting
Terminology
EEM - everything except emails.
Use RDBMS buitin incremental backup support
Pros: no development is needed
Cons: not all RDBMS support this; backup is RDBMS- and DBMail- dependent, so this will not always work with RDBMS and DBMail upgrade, will not help with RDBMS migrating
Another Approach
We can split the problem into 2 parts:
- Exporting EEM
- Exporting emails
Export EEM using standard database export tools
Subsequent calls will overwrite EEM. Since the size of EEM is relatively small, should be perfectly O.K.
Pros: no special development needed
Cons: backup is RDBMS- and DBMail- dependent, so this will not always work with RDBMS and DBMail upgrade, will not help with RDBMS migrating
Export EEM using special (possibly XML-based) format
Subsequent calls will overwrite EEM. Since the size of EEM is relatively small, should be perfectly O.K.
Pros: backup is RDBMS-independent, so it makes possible to use it for RDBMS migration, RDBMS upgrade, DBMail upgrade and so on
Cons: import-export utilities must be created and maintained
Export emails to Maildir format
Important thing here is not to export the whole Maildir again and again, but only update it, deleting files with old mails and creating files with the new one. Here we can split export into two independent tasks again:
- Exporting new emails
- Deleting emails which were deleted in DBMail database
Pros: incremental backup will just work
Cons: requires huge amount of inodes
Export emails to Mailbox format
Optimization here should be the same as with Maildir - only new mails should be added, deleting of the old emails can be done more rare than injecting new emails.
Pros: less inodes comparing to the Maildir
Cons: performance sucks, adding one single email to the maibox will trigger backup of the whole Mailbox file
Labels: backup, dbmail, development, free software, software

0 Comments:
Post a Comment
<< Home