HCL have, for the first time, introduced Domino-native backup and restore tasks in v12 which you can configure in Domino and run via the Domino console. I can backup to a file system but I can also configure the tasks to integrate with a 3rd party solution if I have one in place already. It’s a very unexpected and welcome feature especially for smaller companies or administrators who want to do ad hoc backups and restores of individual databases without co-ordinating with the backup team.
There’s a lot of optional and incredibly advanced settings (full documentation of all that is here) but let’s start by doing a simple backup and restore of a single database so you can see how easy it is. A lot of screenshots follow because I want to step you through the process but you’ll see there’s very little setup for you to do.
The configuration is all done through a new database called dominobackup.nsf which is automatically created on a server when you type “Load Backup” on the console (if it doesn’t already exist). Once done you can open dominobackup.nsf on the server. There is nothing special about this database other than its name so you can replicate it to other servers once it’s set up and if you want the same configuration.
Let’s start with checking the Global Settings by clicking on “Edit Global Settings”
The above is a default Global Configuration document in a new database. The Admin and Template server fields are currently ignored in Domino and unused in code.
- Backup database and Restore database refer to where activity is logged, not where the actual databases are located.
- Restore folder is a folder under the Domino data directory where databases are restored to. Later when we do the restore we will see the option to maintain subdirectory hierarchy under that.
- Default restore retention days refers to how long a restored database will stay on the file system before Domino will remove it with a prune command
- Default restore Notes folder refers to a Notes database folder (as opposed to a file systen folder) where documents can be restored to if you were doing a restore of specific documents from a backup into a production database.
Remember this is a Global configuration document so the settings here will apply to any server this database is sat on.
Now let’s set up a backup configuration. In the configuration view you will see two default documents, one for Linux and one for Windows. You can use these configuration documents and amend them as needed but I made a new config for the server “Clouds” as I wanted to configure its settings differently from the default ones. You don’t have to create server-specific configurations if you are happy for all servers with a replica of this database to use the same configurations.
Let’s take a look at the configuration. We’re not going through every field in this blog (there’s a lot), but the ones I think are important to doing our simple backup of a database. The settings below were used to backup and restore databases to the file system on a Linux operating system although a similar configuration could be used on Windows, with obviously different paths.
- Config Type can be either “Server” or “default”.
- Server name becomes “Platform” if you choose “default” for config type. You can only enter a single server name here
- Node name defaults to that of the server and will be used in creating the filepath for the backups. You can change the Node name if for example your server name is long / has spaces / is unsuitable for filepaths
- Excluded databases use wildcards and file extensions or directories to tell the backup to ignore certain databases. The default is to back up all NSF and NTF files (but not NLOs – more on that later). This field is multi-value so you can enter (for example) *.NTF; Mail\restore\*.nsf; log.nsf
- Backup retention days is taken from the Global Configuration document we set up earlier but can be changed here. Once a backed up database goes past this age Domino can/will delete it
- Backup DB & translog command. We have a choice of “File” ; “Cmd Formula” ; “Agent” and “Cmd”. All but file refer to integration with 3rd party backup systems so for our purposes we are choosing “File”
- Leave Backup disable direct apply unchecked
- Backup log file – when performing a backup Domino can create a log document in the dominobackup.nsf database and/or create log files on the file system. By selecting Disk&Attachment I am asking it to do both so both network administrators and Domino administrators can easily read the logs
- No other settings are needed.
After filling in this tab and saving the document I ran a test by typing “load backup” on the console of the server called Clouds. When the backup completed the Directory Inventory view showed a list of all the backed up databases.
I looked at my file system to find Discussion.nsf and this is what was returned – the original database is in /data/notesdata/UX/Discussion.nsf and the backed up instance with a date/time stamp under the directory structure we set on the basics tab.
So now I want to restore this backed up database. Don’t worry, it won’t overwrite the one that’s there and you don’t need to delete the one that’s there unless you want to. This is a simple file system restore, so there are few settings for us to update.
- Restore Db / translog command. We again have a choice of “File” ; “Cmd Formula” ; “Agent” and “Cmd”. All but file refer to integration with 3rd party backup systems so as we did for the backup, for our purposes we are choosing “File”
- Restore snapshot command is also related to integration with backup solutions that support snapshotting
- Restore DAOS command and the other DAOS options require you to be using a 3rd party backup solution to handle your NLO backups. For our purposes here we aren’t doing that.
So now everything is configured I just need to tell the server what databases I want to restore. Again we go to the Database Inventory view to select a database that has been backed up (I can only restore what I have managed to backup). Find the database you want to restore and select it in the view then click the “Restore” button at the top of the screen.
That will open the Restore Job document (you can also select multiple databases and choose “Multi DB Restore” but we’re not doing that here). There are a lot of fields and we’re going to ignore 80% of them, take the prefilled defaults and fill in only ONE field
- Status creates as draft and changes to “Submitted” when the job is submitted but you can open an existing Restore Job and change its status and resubmit it at any time.
- Server Name and Database Name are prefilled for me when the job is created so I won’t change those
- The restore path comes from the Global Configuration document we set up earlier but can be changed here. It’s important to note this path is relative to the Domino data directory so the actual restore path will be (for me) /data/notesdata/restore. I don’t change it.
- The only setting I have to choose is which backup I want to restore from, as the system assumes there are multiple backups taken over a period of time. There are two ways of selecting a backup either by a date range in which case the newest backup within that range is restored, or by bringing up the dialog for the field “Selected Backup which will give me the option to restore any backups available for the database that dominobackup.nsf knows about. In this instance there is only one so I select that.
- Disable Replication is checked by default so that the restored database arrives with replication disabled and there is no risk of it replicating with any production versions on any servers (don’t forget that our restore directory is under the Domino data directory so accidental replication is a real risk otherwise).
I click the “Submit Restore” button at the top of the Restore Job page and my restore job is now queued. I can now type “Load Restore” on the Domino console. It will take a few seconds, or maybe minutes if the db is multi-Gb large, and then the Restore Jobs view will update to show the restores have completed.
Now if I search my file system for Discussion.nsf I find the original database in /data/notesdata/UX, the backup copy in /local/backup/nsf and the restored copy (replica) in /data/notesdata/restore
An Important Note About DAOS and NLOs
The Backup task does not support backing up NLOs. HCL specifically require you to use a 3rd party backup system to back those up. NLOs are write-once files, they never change once created, and are just removed (pruned) when no longer needed, so it’s important to have a separate backup strategy for NLOs. Whatever backup tool you are using to back up your NLOs should be able to integrate with the Domino backup task which is why there are several fields asking about NLOs. However, consider that the default prune setting for NLOs is 30 days so a NLO will not be removed from the Domino file system until 30 days after the last instance of a document containing that attachment is deleted.