Backing up Vault indexes using indexbackup.adm

There is no automated process for backing up indexes at any specific point, but it is easily achieved by using the indexbackup.adm process (covered in the Customizing Guide document provided with product):
1.  Do not backup the <vault_install_path>\server\index folder manually.  This is because backups can take a long time, and if ingestion is happening during that time, the beginning of the file(s) might not match content at the end of the file(s).  Such an index, if restored, would not be internally consistent, and may therefore be corrupt, sometimes catastrophically so.  Instead, instruct the e2loaderd to make a copy of the index to a separate location.  Since this process is handled by e2loaderd, you can be assured that no ingestion was happening simultaneously. Then, make a backup of the backed-up files, which will be an internally consistent representation of the index as-of that time and date.
a.  Create a file called indexbackup.adm (this file must have some size, meaning it cannot be 0 bytes), and place this in the <vault_install_path>\server\process folder
b.  The file will moved to <vault_install_path>\server\work while activity is occurring
c.  On completion, the file will be removed from <vault_install_path>\server\work and a semaphore file called indexbackup.done will be created in the <vault_install_path>\server\backup folder
d. The index backup will be in <vault_install_path>\server\backup folder, which can be copied to another (safe) location if required
e. The default location for the backup folder is <vault_install_path>\server\backup but the user can override the backup path by changing this in the [Paths] section in server.ini for example BackupPath=x:\soandso\
f.  Restoring is very easy. 
                                                   i.  Stop Vault safely - see article
                                                  ii.  Rename <vault_install_path>\server\index to index.bad
                                                  iii. Rename copied <vault_install_path>\server\backup folder to  <vault_install_path>\server\index
                                                  iv. Restart Vault.
2.      When backing up the PageData and DocData folders, or the Storage path (if StorageModel is enabled), make very certain that the backup tool does not lock files and/or use a ‘deny read’ mode.
a.      If this happens, then the Vault will not be able to retrieve documents from a given file, if that file is being backed up.
b.      This becomes most noticeable when the backup reaches the last month’s worth of .DRP and .DRD files – because those are most likely to be actively retrieved by users
3.      Incremental backup is very suitable for DRD, DRP, JRN files, because these files are not typically altered post-ingestion.
4.      Make sure that Backups are configured to be ‘ionice’ on UNIX, or use similar reduced-prioritization within the backup tool itself.  Several customers have had production emergencies because the backup process has overloaded the Disk I/O subsystem, and interfered with document retrieval.

If restoring from an old backup, all files loaded since the backup was taken will need to be reingested.
UPDATED:  November 9, 2018