HCL Domino Ideas Portal
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
Just tested. You can open a DAOS enabled database locally.
I took a backup using Domino 12 Backup to get the NSF part backed up to have realistic scenario.
Then I took the database from the backup and opened it locally on a client.
I was able to open a test document with multiple attachments. Attachments stored in DAOS resulted in an error message. Attachments smaller enough to be in the NSF (below the DAOS threshold, just opened fine.
I don't see a problem here. But on the other side I would strongly recommend against restoring databases locally without DAOS. DOmino 12 Backup and Restore is designed to work on the server, restoring databases back to the server with replication disabled and also with agents disabled. You can also change the replica ID.
Domino Backup&Restore is designed having Domino in mind by HCL. Not by a backup vendor providing basic restore functionality.
I see no reason any more to not restore to a server directly.
Restoring to a server with replication disabled would only restore the NSF part. DAOS would be still available if the retention time of NLOs with no references has not reached.
Restoring to a client is not desirable. Databases restored belong to the Domino server.
But if you really want to, I see no reason why DAOS should prevent you.
Can you share your Notes & Domino version and also the error message you got?
Thanks
Daniel
The comment about agents is very valid and has stung me before
The main use case is where a developer is troubleshooting a bug in a workflow application. The developer benefits from understanding the document context before the bug so that they can recreate the issue. There is simply no need to deploy the application to a server.
Another use case is where there has been partial corruption ( bug, human error, etc ) and individual records need to be cherrypicked out of the backup.
Space on servers, and administrative access to servers, is often limited. We have also seen high workloads relating to large restored databases affecting production ( Views, FTI ).
If it is a production server there is also a fear of restoring an application with the same repid as a production application. This can be got around with the Turtle repid change utility ( or maybe the V12 backup ) but this probably means that the developer has had to pull the backup file down locally to do this.
We do not run Notes clients on servers.
Thomas, sometimes putting the restored database on the server would be dangerous. It might ruin replication. Agents would start without control. If you just need a couple of documents from the backup, it would be handy to be able to open it in the Notes client.
What is the main reason for not recovering the database to a server directly? Why does it have to be opened with a Notes client? Is the Notes client installed on the server?