- Product Version:
ServosityPro: 5.5.8.X+
OS: Windows
- Description:
Outlined below are some best practice guidelines for MS Windows system backup with ServosityPro's MS Windows SystemBackup module.
- Content:
Bare metal backup or restore can be challenging at times. However, a little planning ahead can save you a lot of trouble when performing a system recovery. Please refer to the following guidelines and suggestions for bare metal backup and restore setup with ServosityPro's MS Windows System backup module:
- Select all critical volume as backup source
For mission critical server such as MS Exchange server or MS SQL server, the bare metal backup must include all critical volumes for future recovery to function properly.
Note:
According to Microsoft - "A volume is a critical volume if it contains system state information (system-critical components)"
Starting from ServosityPro version 5.5.8.0, a new option 'Include all critical volumes' is introduced to allow easily selection of all critical volume.
Figure 1.0 - ServosityPro user interface
Simply select the 'Include all critical volumes' option and ServosityPro would automatically select the corresponding volume(s) during backup (dynamically).
It is strongly recommended that the 'Include all critical volumes' option be selected.
- System backup is not a replacement for file backup
Bare metal Backups should never be considered a replacement for a nightly data backup plan. Firstly, bare metal backups do not lend themselves easily to recovery of a single file. The nature of bare metal backups requires a complete restore of the system image file, even if you only want to recover a single file.
- Reduce the backup frequency
The best practices for scheduling bare metal backups is simple, perform a MS Windows system backup when the server is updated, or when new application is installed on the server.
In most organizations, server application changes infrequently. Most changes are the result of hotfixes, service packs and security updates. Thus, we recommend a monthly, or at maximum a weekly MS Windows system backup be performed.
In most organizations, the backup schedule should look like:
| Daily |
- |
File backup, database backup |
| Monthly or weekly |
- |
MS Windows system backup |
- Restriction on the temporary storage location for the system image file
There are a few different restrictions imposed by Microsoft on the storage location for the MS Windows System backupmodule and the System State backup module.
For a system backup (MS Windows System backup module):
- The temp directory can be a local, USB or network volume
- The temp directory must be a non-critical volume, there is no workaround for this
A summary of the restrictions:
| Backup Type |
Critical Volume |
Non-critical Volume |
USB Volume |
Network Volume |
| System Backup (MS Windows Systembackup module) |
No |
Yes |
Yes |
Yes |
| System State Backup (System Statebackup module) |
Yes 1 |
Yes |
Yes |
No |
1 For system state backup to spool to a critical volume, you need to add a registry entry to allow spooling to any volume:http://support.microsoft.com/kb/944530
For best performance, we strongly recommend using a local dedicated volume for storage for the system image.
- Have a dedicated volume for storage for the system image as local copy
For fast system recovery, we recommend that the system to be backed up have a dedicated volume for storage for the systemimage files. In the following example, the system consist of 2 volumes:
| Volume C |
- |
System volume |
| Volume E |
- |
Dedicated volume for storage of the system image file |
Figure 2.0 - Windows Explorer
Consider keeping an uncompressed version of the system image in the dedicated volume for storage as local copy. In ServosityPro, de-select the option 'Remove temporary files after backup'.
Figure 2.1 - ServosityPro user interface
- Enable Microsoft's BitLocker on dedicated volume for storage of system image file
Provided that you have chosen to keep an uncompressed version of the system image in the dedicated volume for storage aslocal copy. For security concern on stolen or lost computer, you can consider encrypting the dedicated volume for storage with Microsoft's BitLocker Drive Encryption.
Notes:
If you choose to use BitLocker Drive Encryption for the dedicated volume for storage, the recovery key is required if the encrypted drive is moved to another computer (e.g. for system restore). This recovery key is unique to the particular drive, and cannot be used to recover encrypted data from any other BitLocker-protected drive.
It is highly recommended to make additional copies of the key and store the key in safe places so that it is readily available when needed to recover access to the drive.
If you lose the recovery password, the data is irretrievable.
- Have the required hardware driver extracted and ready
For bare-metal recovery, in many instances you will need to provide extracted driver installation media. Your drivers must be fully unpacked and include the .inf files. Many installers that come in the form of a setup.exe file can be extracted from a command line to a destination folder without actually running the setup and installing the drivers. This makes it easy to assemble the collected drivers.
Note:
For example, most Intel drivers can be extracted from the setup.exe by the command line, {$Setup-File-Name} /e /f {$Destination-Path}.
- Have a system recovery plan ready, and perform routine recovery test
Consider performing routine system recovery test to ensure your system backup is setup and performed properly. Performing system recovery test can also help identify potential issues or gaps in your system recovery plan.
For best result, it is recommended that you keep the test as close as possible to a real situation. Often times when a recovery test is to take place, administrators will plan for the test (e.g. reconfigure the test environments, restoring certain data in advance). For real recovery situation, you will not get a chance to do that.
It's important that you do not try to make the test easier, as the objective of a successful test is not to demonstrate that everything is flawless. There might be flaws identified in the plan throughout the test and it is important to identify those flaws.
|
