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.
Refer to the following guidelines and suggestions for bare metal backup and restore setup with 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)"
Select the 'Include all critical volumes' option for the backup client application to automatically select all critical 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 different restrictions imposed by Microsoft on the storage location for the MS Windows System backup module and the System State backup module. System State and System backup temporary storage restrictions - 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 system image 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
Consider keeping an uncompressed version of the system image in the dedicated volume for storage as local copy. In the backup software de-select the option 'Remove temporary files after backup'.
- 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}. - Caution on recovery to dis-similar hardware
This recovery method requires the restore target system to have similar hardware and the exact same boot type as the source system from which the backup was taken. Disk adapters are especially sensitive. If dis-similar hardware is used, the restored system might not be boot.
- If the system backup image was taken from a BIOS-based system, the recovery environment must be booted in BIOS mode, and the restore done withing this BIOS mode.
- If the backup was taken from an EFI-enabled system, the recovery environment must be booted in EFI-enabled mode, and the restore done from withing this EFI mode.
BIOS \ EFI boot mode selections are done in the system BIOS (refer to the computer mftr documentation for specific instructions). - 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.
