Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
The number of backup for the database repository is limited! You can't store more than around 150-200 backups (depending on the path len of the databases). The prune of the backup is designed to be in-line with the backup data.
If you are below 150 backups in total, you can configure the prune operations to not prune the backups from dominobackup.nsf today.
It is designed for flexibility. But you still need a restore logic, which takes into account the other data store. where you store the backups for a longer time.
This is still a logic you can implement today leveraging the existing functionality in backup. In case you need a higher number of backups than 150, you can keep the backup log files with the backup and import them from the log to the dominobackup.nsf for a restore when needed.
This option is actually included for disaster recovery where you dominobackup.nsf is not available. Also Domino backup/restore configuration is dumped to a DXL, and can be imported by the way.
There is a HCL GitHub open source project to discuss those type of integrations.
https://github.com/HCL-TECH-SOFTWARE/domino-backup
I am happy to help with some additional information in the community project.
[ Daniel Nashed / HCL Lifetime Ambassador ]