12.2 Backups

   

12.2 Backups

A common mistake made by administrators is to assume that installing RAID controllers on a server is the same as backing up data. It is not. The purpose of RAID is to provide failover in the event of a hard drive failure. Backing up data involves making a copy of existing information on a separate device. Backups are especially important in a server environment, as the purpose of a server is to store information.

Data backups are an inherent part of good network security. If a server, or another network device, is compromised, restoring proper data quickly is just as important as responding to an attack.

There are three different types of backups:

  1. Full

  2. Partial

  3. Image

Full and partial backup combinations are the most popular. Initially a full backup of a system is created. Subsequent backups only copy files that have changed. If there is no change, the file does not need to be copied . Periodically, usually once every week or two weeks, a full backup is again completed, and the cycle restarts. A disk image is a sector-by-sector duplication of a disk that is stored as an image. The image can then be transferred to other media, or restored at a later date.

Backed -up data can be stored in several different ways. It can be stored to tape, or on multiple tapes using a tape jukebox, or data can be stored within a Storage Area Network (SAN). The two methods of storage are not mutually exclusive; tape servers can be included as part of a SAN, and, in fact, this is very common.

Using a SAN is the recommended method of performing backups. A SAN is a network of mass-storage devices that is isolated on a private network, segmenting SAN traffic from the rest of the network. Because SANs involve a lot of data, high-speed connections are used to connect devices on the network. Usually, this involves fiber optic connections between the devices.

The private network, combined with the fast connectivity between devices, has quickly catapulted SAN as the preferred backup technology, which makes sense, because backups are useless if they have been corrupted. So, it is important to secure backup data, just as you would any other communication.

Obviously, backup security would be enhanced if the data were encrypted, but the load on the network and the servers would be too great for a midsized network. Instead, by isolating the traffic, at least some level of security is achieved.

The backup process starts with the frequency and times of backup. Server backups should be performed on a daily basis, unless the information on the server does not change often, in which case every few days may be acceptable. No server should go more than a week without being backed up. Router, switch, and firewall configurations should also be backed up on a daily basis, or at least several times a week.

If an organization is run in a traditional manner, where employees access servers between 9:00 A.M. and 5:00 P.M., then anytime overnight is fine to perform backups. As more organizations more toward a 24x7 operation, it becomes increasingly difficult to set a time to do backups. In cases like this, it is important to monitor server and network traffic to determine the best time to perform backups. There is no rule that says all backups have to be performed at the same time; in fact, in many cases it helps to spread out the backups throughout the day.

Backups to a tape, or writable CD-ROM, are preferred as it is more difficult to write over, or corrupt, those mediums than it is a hard drive sitting on a server. In addition, whenever possible, backups should be encrypted. The backup process does not have to be carried out over an encrypted connection. Once the data is backed up it should be encrypted; this helps to prevent an attacker from tampering with data that should be safe.

Backups should be tested on a regular basis. Not only should they be tested to ensure that the data was successfully backed up, but restores should be tested as well. Backup software will sometimes report corrupted data as a successful backup, so everything looks fine in the log file, but the data is actually worthless. This is especially common when a bad tape or CD-ROM is used. Taking a few minutes a week to spot check backups by attempting to restore a file, or directory, is a good practice and may provide warning signs that a failure is about to occur.

Test restores of data can also help server administrators determine how long a restore will take. The most commonly asked question when a server fails is when it will be back online. The better answer administrators can provide to that question the happier network users will be. Practicing helps to ensure that the data will be restored in a timely manner.

Backup mediums should also be rotated to offsite facilities. Companies such as Archive Away, StorNet, and Storage Networks offer organizations ways to store backups in a separate facility, away from the corporate network. Data can either be transferred to these facilities across the WAN, using a private VPN, or even physically sent to the location.

A good rule of thumb is to keep two weeks of backup on site, and at least two or three months of backups at a remote location. In some instances, especially where financial or legal records are involved, this length of time may not be adequate. If this is the case, local or federal laws may govern the length of time the backups have to be stored.

12.2.1 Disaster Recovery

Offsite backups are a critical part of a disaster recovery plan. Disaster recovery is the ability of an organization to recover and continue doing business, with minimal interruption, in the face of a catastrophic disaster.

As awareness of security network problems has increased so has the interest in disaster recovery. To address the problems associated with a catastrophic failure, a disaster recovery plan should be developed within an organization.

Such a plan outlines the steps necessary to bring an organization to a fully operational status in the event a disaster occurs. Disasters generally fall into one of four categories:

  1. Accidental

  2. Internal

  3. Natural

  4. Terrorism/Civil unrest

These categories are intentionally broad. Similar to a security plan, it is up to each individual organization to determine what constitutes a disaster (what would cause a business interruption) and what steps need to be taken to restore business operations.

While the categories have some leeway in terms of interpretation, there are guidelines as to what makes up each. An accidental disaster is a complete loss of power, a train derailment or other transportation accident , or an employee who accidentally destroys valuable corporate data.

Internal disasters include things like employee sabotage , theft, or even work-place violence. The difference between accidental disasters that involve employees and internal disasters is that with an internal disaster the action is intentional. Natural disasters include floods, hurricanes, heavy rain, blizzards, and other catastrophes initiated without human intervention.

Many offsite storage organizations also offer disaster recovery solutions. These solutions are mirrors of existing data that are activated in the event of a complete network failure at the primary location. If that is not an option, then determining the fastest way to recover data from an offsite location should be considered as part of a disaster recovery plan.

Disaster recovery is not inexpensive. In fact it can often seem to be excessively priced. However, the cost pales in comparison to the cost of hours, or days, of downtime, which is why many organizations opt to participate in some form of disaster recovery.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net