Difference between revisions of "Backup and Restore"
[unchecked revision] | [unchecked revision] |
Line 63: | Line 63: | ||
If the instance configuration has been deleted from the management database, proceed as follows to restore an instance: | If the instance configuration has been deleted from the management database, proceed as follows to restore an instance: | ||
− | # Create a new instance as described in [[ | + | # Create a new instance as described in [[Instance_Management#Creating Instances|Creating Instances]]. Its name does not necessarily need to match the previous name. |
# Open Windows Explorer and navigate to the base directory of the newly created instance. | # Open Windows Explorer and navigate to the base directory of the newly created instance. | ||
# Delete all files and directories from the base directory. | # Delete all files and directories from the base directory. | ||
# Now restore the data into the base directory of the newly created instance. | # Now restore the data into the base directory of the newly created instance. | ||
# Finally start the instance. | # Finally start the instance. |
Revision as of 15:28, 16 March 2017
Creating Backups
The management database as well as your branding data is stored in the config sub directory right below the program files directory of the MailStore Service Provider Edition (default: C:\Program Files\MailStore Infrastructure) on the Management Server. To be able to fully restore a MailStore Service Provider Edition installation, it is highly recommended to create regular backups of that config directory.
Even more important than the backup of the management database and branding are consistent backups of the MailStore Instances. These instances store their data in at least one directory on the disk, which is the base directory specified during initial creation of the instance. By default, automatically created archive stores are located in sub directories of the base directory, making it sufficient in most cases to only back up the content of the instance's base directory and all sub directories.
When the auto-create settings of archive stores have been modified, additional storage locations must be backed up along with the base directory.
Hint: The base directory contains a link Debug Log which points to %PROGRAMDATA%\MailStore Infrastructure\Debug Log\<instanceID>. It is usually not necessary to follow that link and backup the debug logs if any.
Depending on the environment, backup capacity, backup locations or the backup software in use, different methods might be available for backing up MailStore Instances. The following provides an overview of the most commonly used backup methods and how they cope with the requirement of creating consistent backups.
File Based Backups
While file based backups solutions are good for backing up independent files, they are usually not suitable for creating consistent backups of MailStore Instances as their data is spread across multiple rapidly changing files.
In order to create consistent backups with file based backup tools, it is required to either freeze and thaw (see #Prepare Instance For Snapshot via API Commands or shutdown and restart each instance that is to be backed up. As the instances must remain shut down for the time of the backup, this typically results in long downtimes during which the instances are neither able to archive new email nor provide end user access to the archived data.
Storage Snapshots
When using Volume Shadow Services (VSS) or other methods of creating snapshots on storage level, it is necessary to ensure that all files used by the instances are closed before the snapshot is created. This can either be achieved by enabling VSS support in the instances themselves or by sending the appropriate API command prior to creating snapshots.
Enabling and Testing VSS Support
Each MailStore Instance provides a so-called Volume Shadow Service Writer (VSS Writer) for external backup software that uses the Microsoft Volume Shadow Service. The external backup software can use it to create consistent backups of the MailStore Instance's database and all archive stores. Whether this method succeeds, however, largely depends on the backup software which is used.
Before MailStore Instances react on VSS events, such support must be enabled in their advanced configuration first. Follow the steps below to enable VSS support for an instance and verify the result.
- Log on to the Management Console.
- Click on General > Instances.
- Select the instance to modify.
- Click on Stop if the instance is running.
- Click on Configure....
- Open the Advanced Configuration tab.
- Check the Enable VSS Writer option.
- Click OK to save the changes.
Now start your VSS based backup and wait until it has finished. To verify that the appropriate VSS events were initiated in MailStore during the backup, open the Windows System Protocol in the event viewer on the Instance Host where the instance was previously backed up and search for the following events:
- A backup session has been started.
- The archive has been frozen as a reaction on the OnPrepareSnapshot event.
- The archive has been thawn as a reaction on the OnThaw event.
- The backup session has been shut down.
If these events cannot be found in the Windows System Protocol, no consistent backup using Volume Shadow Service was performed and your backup software obviously does not support the MailStore VSS writer. In that case try the API based method below.
Prepare Instance For Snapshot via API Commands
MailStore Instances can be frozen and thawed similar to using VSS by executing the corresponding API commands FreezeInstances and ThawInstances. The easiest way of executing API commands from other applications such as backup software is by using MailStoreManagementCmd.exe.
To learn how to execute commands before and after performing snapshots, please consult your backup software's documentation.
Full Virtual Machine Snapshots
Some backup solutions are highly integrated into virtualization solutions and allow to create and backup/replicate full snapshots of virtual machines. These type of snapshots not only contain the current state of the hard disks but also of the current main memory. Thus full virtual machine snapshots can be considered as consistent.
Other Backup or Replication Methods
For questions regarding any other type of backup solutions such as block level replication, continuous backup, etc. please contact the vendor's support to find out whether their software is able to create consistent backups of whole directory structures.
Restoring Backups
Restoring Management Database and Branding
To restore the management database and branding data make sure that none of the MailStore Service Provider Edition roles (Management Server, Instance Host and Client Access Server) are running. Then restore the content of the config directory back into its original location (default: C:\Program Files\MailStore Infrastructure) and finally start the Management Server role again followed by the Instance Hosts and Client Access Server role.
Restoring Instances
As long as the instance configuration still exists in the management database on the Management Server, the restored data should be placed in the previous location which usually means in the base directory of the instance. Afterwards the instance can be started from the Management Console again.
If the instance configuration has been deleted from the management database, proceed as follows to restore an instance:
- Create a new instance as described in Creating Instances. Its name does not necessarily need to match the previous name.
- Open Windows Explorer and navigate to the base directory of the newly created instance.
- Delete all files and directories from the base directory.
- Now restore the data into the base directory of the newly created instance.
- Finally start the instance.