Backup server data at the block level bypassing the file system and reading data directly from the disk or volume. Block-level backup provides advantages over traditional file backup technologies including the speed of completing a backup operation, a drastic reduction in disk and network I/O, the ability to perform backups as often as every 15 minutes and no performance penalty for servers having a large number of files.
SBAdmin provides the most flexible bare-metal recovery solution for Linux and Unix Systems.
- Bare-Metal System Recovery
- Clone/Provision Systems
- Physical to Virtual Migrations
- TSM Integration
- Storage and/or Hardware Migrations
- Backup Data Encryption
Bare-Metal Recovery for Linux, AIX, and Solaris
Server downtime can be caused by something as simple as a corrupt system file or major disaster such as a hurricane. Whatever the cause and scope of the disaster, the consequences are the same – you no longer have the system, losses are mounting, and productivity is suffering. During a datacenter crisis, how long it takes to get back online can make or break a business. Some items to consider are:
- Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption and includes all impact considerations.
- Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.
- Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage. Unlike RTO, RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process.
Barriers to a timely system recovery
Your bare-metal disaster recovery plan today may be to re-install the operating system from the original media or generic provisioning image, apply patches, install third-party applications, reconfigure applications, and then restore the system’s data. This can be very time consuming, inefficient, costly, and prone to error if you are unable to restore the system exactly as it was before. If your plan is a disk-image backup product, you are restricted to the using the exact same hardware during the recovery process. Often, a duplicate of the original hardware is not available when disaster strikes.
Solving the problem of lengthy downtime
SBAdmin is designed to provide bare-metal recovery for AIX, Linux, and Solaris systems in their entirety, quickly and reliably so that you are able to resume operations with minimal downtime and effort. SBAdmin will do so in such a manner that you may restore the system to the same, similar, or completely different hardware using what we call Adaptable System Recovery (ASR). With ASR, you do not need to worry about keeping identical hardware available in case of a disaster. Your offsite recovery plan can be simplified by restoring production systems onto whatever hardware (physical or virtual) is readily available.
Perform system recovery from local or remote devices:
- Tape (including autoloaders and libraries)
- Disk (including SAN devices)
- TSM Server