Having backup of data is critical to prevent the loss of data from user error, equipment failure, ransomware, or disaster. Having backups can make a serious incident much less painful, but when the backups are not up to date or readable, even a minor problem can become a major crisis.
The traditional approach to backups was to take a full backup once a week and store it off site. These backups were often stored on magnetic tape, which is a relatively inexpensive way to store and transport data. These backups were often stored with a third party that operated a secure location and even arranged secure transport between the organization’s data processing facility and the off-site storage location. Because these tapes were in the possession of a third party, it was recommended to encrypt the backups using a symmetric algorithm such as Data Encryption Standard (DES) or Advanced Encryption Standard (AES). In the event the organization wanted to retrieve the data, there needed to be a way to ensure that only an authorized person could acquire the tapes and that the encryption keys were available.
Full backups copied everything from the target system, including the operating system, applications (including patches), transaction files, reports, access permissions, configuration files, and databases. This meant that a system could be completely restored from the backup. However, a full backup takes time and may impact production operations and performance while the backup is being created.
The frequency of doing backups depends on several factors, such as the volatility and value of the data. Data that is changing constantly requires more frequent backups than data that is fairly static and unchanging. Another factor is the value of data; some data has a short lifespan and relatively low value, such as weather data, while other data, such as trading data on a stock exchange, has tremendous value and volatility. A weekly backup of stock exchange data would likely not be acceptable.
Some of the options for data backups in between full backups include differential and incremental backups. A differential backup copies everything that has changed since the last full backup. In this case, if a full backup was done on a Saturday, then the differential backups each day would record all changes made since the Saturday backup. On Wednesday, for example, the differential would include all changes made on Sunday, Monday, Tuesday, and Wednesday. If there was an enterprise failure on Thursday, then the organization would need to use two backup sources—the Saturday full backup and the Wednesday differential—to retrieve the most current data.
An incremental backup copies any changes that have occurred since the last backup of any type. In this case, if the full backup was done on Saturday, then the incremental backup on Sunday would copy only the data changed since Saturday, and the incremental backup performed on Monday would record only the data changed on Monday. Each time a file is backed up, the archive bit would be set to show it has been backed up at a certain time.
If the system suffered a catastrophic failure on Thursday, then the administrator would need to restore each backup including the full backup from Saturday and each incremental backup from Sunday through Wednesday.
Many organizations will keep several generations of backups so that if one backup is corrupt, then there are still several other backups that could be used. The problem with this is that older backups will not contain some of the latest changes to data and may result in a higher amount of data loss. There might also be an issue with exceeding regulatory mandates for data retention/destruction.
Some backups may be kept on site. This means that they are readily available in case of a problem, such as accidental deletion, equipment failure, or malware; however, they would not be usable in case of a localized disaster, such as a fire or flood.
Another option is to keep backups nearby, perhaps in another building on the same property or campus. These backups would be good in case of fire but probably not in the event of a hurricane or tornado.
Keeping backups off site should mean that they are available regardless of the type of event that affects the primary data center. The security manager would want to ensure that the backups are stored in a secure location and that they would be available when required, providing 24-hour access and the ability to get to the site in times of crisis.
When a backup is created, it should be checked to validate its integrity. There are many historical examples of backup programs that indicated that backups were being taken but did not actually copy the data properly.
The use of disk drives for backups has greatly increased the value of backups as well as speeded the recovery time. Disk mirroring is when data is written simultaneously onto multiple drives. Ideally, this may also involve the use of multiple disk head controllers to avoid the controller being a single point of failure. This type of backup provides a complete copy of the data so that if one drive fails, the data is still available on the other drive, and there should not be any lost data.
Mirroring may also involve storing data on multiple servers at different geographic locations. In this case, the mirrored drives would still be available in the event of a fire or other catastrophe damaging the primary data center. However, connectivity to geographical disparate sites becomes a dependency for recovery during contingencies; the data may be safe, at a removed distance, but the ability to recover it could be limited by damage to the communications provider (such as during a disaster).
The use of multiple disks and some associated techniques for data recovery are codified by the industry under the term RAID. (RAID used to be an acronym for phrasing such as redundant array of inexpensive disks or redundant array of independent disks, but it is not solely a term for the mirroring/data protection practice itself.) The CISSP should be familiar with the following RAID types:
- RAID 0, block-level striping: Distributes the data across multiple drives. This increases the read and write speed (performance), but it also increases the risk of drive failure, since the loss of any one of the drives will make the data unusable.
- RAID 1, mirroring: Copies the data to two or more drives so that the loss of a single drive would not mean the loss of the data.
- RAID 2, bit-level striping: Manages bit-level striping with error This is not commercially viable because computational overhead exceeds performance benefits.
- RAID 3, byte-level striping with parity bits: Stripes data across multiple drives, and a parity bit is created that would allow the data to be rebuilt in the event of a single drive failure.
- RAID 4, block-level striping with parity bits: Stripes data at a block level, and a parity bit is created that would allow the data to be rebuilt in the event of a drive failure.
- RAID 5, block-level striping with interleaved parity: Stripes data at a block level, and a parity bit is created and distributed among all drives. This would allow the data to be rebuilt in the event of a drive failure.
- RAID 6, block-level striping with duplicate interleaved parity: Stripes data at a block level, and two parity bits are created that are distributed among all drives. This would allow the data to be rebuilt in the event multiple drives fail.
- RAID 1+0 and 0+1, a combination of mirroring and striping: Mirrors the stripes or stripes the mirrored data (the order of operations is different). These are the most expensive options, but the best for both performance and reliability.
Note It is essential that any data backup plan includes testing that involves an actual recovery of the data from the backup. This is the only method for absolutely ensuring that the backup method is operating successfully and that sufficient data is being captured. Recovery must be performed on a somewhat regular basis (many standards mandate annually) to maintain assurance in the backups.
