Confirm the Backup Schedule Meets Organisational …



Ensure backup to organisational schedule

[pic]

Inside this reading:

Backup schedules and media 2

Backup media 2

Backup and restore processes 4

Backup practice using Windows XP 4

Performing a restore for checking 7

Documenting the backup 9

Off-site backup storage 10

Documenting system restores 10

Summary 11

Backup schedules and media

Schedules for data backup should be set down in organisational guidelines and will usually have been developed from a disaster recovery plan (DRP) or contingency plan.

It is important to follow these schedules exactly. Those responsible for the backup of data needs to remember that somebody has likely spent many hours developing and testing schedules to ensure that data is protected.

Infrequent backup of changing data can undermine data quality or make backed-up data irrelevant. Backing up data more often than necessary may place a processing load on the network and burden storage space.

Backup media

The media used by an organisation for backup will usually have been decided in the design of a system, and an organisation’s disaster recovery plan may also identify particular media for a particular backup processes.

Whatever backup media chosen needs to be identified, usually by labels, and it is often good practice to have another staff member check that all backup media is correctly labelled.

Where there are a variety of devices available to perform a backup, the likely locations of a restoration of this backup need to be considered and the most appropriate media for the process chosen.

Broadly, backup options can include hard drives (portable and fixed), portable media and removable magnetic media, such as CDs, DVDs, USB memory devices, specialised high-speed data storage and storage across local area and wide area networks.

Table 1 on the next page explains the benefits and limits of some of the most common media and devices.

Table 1: Back up devices and media

|Device or media |Benefits and limits |

|Hard drives |Backup to hard drives is fast, especially with USB and firewire connections, and |

| |large volumes of data can be stored, the capacities of devices available range from |

| |40 to 400GB. External hard drives, being portable can also be stored off-site. |

|Recordable compact disc |Recordable media is write once, read many (worm). This means that the data once |

|(CD) |written is not removable. The integrity of the data is quite robust as long as the |

| |disks are stored correctly. When backup to a CD is performed it is possible to use |

| |the CD in a ‘session’. This means that data can still to written to the disk up to |

| |the capacity of the disk, but it appends to the existing data and does not overwrite |

| |it. |

|Rewriteable CD |This media is erasable and writeable in a way similar to a hard disk. The potential |

| |threat to data is that the disk must be formatted to a file system, such as universal|

| |disk format (UDF) and data is not always recoverable unless the PC being used can |

| |work with the format. CDs can hold between 650 and 800MB. |

|Digital video disk (DVD) |Digital video disks, also called digital versatile disks, hold large amounts of data.|

|recordable and rewriteable|The two recording standards and two structural forms of DVD for write-once standards |

| |are DVD+R and DVD–R. The rewriteable formats (which work as with CDs above) are |

| |DVD+RW (with the ability to erase and rewrite), DVD–RW (which can be rewritten about |

| |1,000 times) and DVD–RAM (more closely related to hard disk technology and unlike |

| |the other formats above, special DVD burning software is not required to write or |

| |read them). Single layer standard DVDs hold 4.7Gb data. Double layer DVDs can hold |

| |9.4GB. |

|Removable magnetic media |Removable magnetic media include mini tape (on 10 and 18mm tape), larger tape (on |

| |60mm and 100mm tape) and USB devices, often called memory sticks. Devices must be |

| |specific for each of these different media and thus are not interchangeable. |

| |The major disadvantage of magnetic media, tapes and USB devices, is that data can be |

| |corrupted by electro-magnetic interference (EMI) and magnetic data is generally short|

| |lived; typically less than five years unless stored in a secure and ideal |

| |environment. |

| |USB devices can store up to 1GB of data. |

| |Tapes can store large amounts of data (up to 350 GB) but the data is accessed |

| |sequentially, meaning it is ordered from the beginning to the end of the tape. (Think|

| |about trying to play the last song on a cassette tape, you have to fast forward to |

| |the song before you can play it!). The media therefore lends itself better to batch |

| |processing or total restoration of a file system. |

|Specialised high-speed |The devices used here consist of stacks of hard drives or DVDs in an array and can |

|data storage systems |hold up to terabytes (109) of data, ideally set up for multiple backup processes. The|

| |devices are often connected into a communication rack at a storage site within an |

| |organisation, the storage site being considered safe and secure. |

Backup and restore processes

You need to ensure that system backups are completed according to organisational, scheduling and system requirements.

On computer systems, most backup applications have a functional and easily-understood command set to allow various options in performing backups. Choosing the correct backup method (either full-, incremental- or differential backup) will help refine and speed the process, while you should first see if a particular backup process is prescribed in the disaster recovery or contingency plan.

It is standard IT practice to make copies of a backup. If a local copy is destroyed by a disaster, such as by fire, an off-site copy can be used to restore data. The disaster recovery plan should specify how many copies and where copies should be stored. Often three copies are created:

• One copy is stored in a convenient location onsite for the network or systems administrator to access

• A second copy is stored in a secure fire resistant cabinet onsite

• A third copy located off-site, such as in a bank or data warehouse.

Having reviewed the backup plan, chosen the right media and decided what must be backed-up, you can then perform the backup by selecting the available options within the backup application.

Backup practice using Windows XP

The steps to follow here are those you would take to perform a backup using Windows XP. Note that if you are using one of the major Windows Server systems such as Windows 2000 or Windows 2003 then the interface and the steps are basically the same.

1 Create two folders on your computer called ‘Backup Files’ and ‘Backed_up Files’.

[pic] [pic]

Figure 1: Create two folders as illustrated

2 Copy files from your hard drive into the ‘Backup Files’ folder. (For the exercise, you could use some text files from the Windows Folder.)

|3 Open the backup program on your computer (Start > |[pic] |

|Programs > Accessories > System Tools > Backup). |Figure 2: System’s backup program |

4 If the program starts with the ‘Backup Wizard’ option, clear the tick box, close the program and the restart it.

5 Click the Backup tab and then expand and navigate to the drive and folder (‘Backup Files’) created in Step 1.

Click the box beside the folder name. This will place a small tick in the box. This is the folder to be backed up.

|6 Also note that at the bottom of the backup screen |[pic] |

|there is an option for a ‘System State’ backup. This |Figure 3: System State |

|option will backup up various system items including | |

|user information, shares, etc. | |

|7 At the Browse prompt (at the bottom of the window) |[pic] |

|navigate to and select the ‘Backed_Up’ folder. Also, |Figure 4: Naming the backup file |

|give your backup file a name of Test_Backup. | |

Note the .bkf extension. This represents a Microsoft Windows Backup file. (Files backed up using the Microsoft Backup program are compressed and then saved into one file only.)

8 The screen for Backup Job Information appears (as in Figure 5 on the next page). Note some of the options that could be selected, such as:

• Scheduling (for example, to perform the task later on)

• Advanced—to perform a full, incremental or differential backup

• Appending or replacing an existing backup file

• Labelling and description of the media.

For the purpose of the exercise leave all the defaults and click Start Backup.

[pic]

Figure 5: Backup Job Information options

9 The backup will start, go through the process and then finish. Limited information is given on the screen at this point (see Figure 6).

[pic]

Figure 6: Backup progress

|10 Click on the Report button and check the |[pic] |

|contents of the text file. In a ‘live’ |Figure 7: A report file that you would save in a real situation |

|situation, you’d save this file for reference. | |

|11 Close the text file and then check the | |

|contents of the Backed_up_files folder. You | |

|should notice a file in there called | |

|Test_Backup.bkf. This is the file created by | |

|the backup process. | |

Checking the validity of the backup

Have you by now performed a successful backup? It is now time to check that the backup is valid.

You need to check that the media is in fact the backup you have just performed. If it overwrote a previous backup, which would be normal using the principle of child, parent, grandparent, you need to identify the name of the backup file that was overwritten to verify this is no longer the current back file.

It is standard IT practice to have the grandparent overwritten to become the new child (this grandparent data is then destroyed), the old parent becomes the new grandparent and the old child becomes the new parent. This scheme is simply a serial rotation that ensures a defined history of backups is saved while utilising old media. Remember, the occasion may arise when a user requires a particular date/time version of a file for restoration, hence the need to have a history of backups. The business operations will define how far back this history of backups should go; bearing in mind that all this media (history) will need to be stored somewhere.

Performing a restore for checking

To ensure the backup has been successful you will have to perform a restoration on a test system to check that the backup is functioning properly. You would then need to open every program and test all data on the restoration. This is time-consuming and because of the possibility of human error, not all that reliable. Another more reliable way to verify the backup is to run a third party application that does a checksum on both the data being backed up and the backup file. Lone Star Software Corporation, for example, has bit-level backup verification software that does this (See Resources for the link).

A checksum is the addition of all the data bits being backed up as if they were binary numbers. If this is done for the data being backed up as well as the data in the backup set, then both checksums should generate the same result. The extent of verification you would need to perform should be given in the disaster recovery plan documentation.

For the following exercise, restore the files that were backed up in the previous activity.

1 Delete the files that you previously saved in the ‘Backup Files’ folder.

2 Run the Windows backup program and click the Restore and Manage Media tab. The previous backups that have been performed should be in the Window.

3 Expand the items on the left of the screen by clicking the small + signs until it cannot be expanded anymore. Click the small box beside the backup that you have just done in the previous exercise. You should be able to pick the correct backup from the date and time (see Figure 8.)

[pic]

Figure 8: Restore tab

|4 Ensure that the Restore files to: option |[pic] |

|shows ‘Original location’. To restore the files|Figure 9: Selecting the location to which files will be restored|

|elsewhere, you could navigate to the folder and| |

|select it. | |

5 Click the Start Restore button. You will be asked to confirm the restore. Note that you will also be presented with an Advanced button. This will allow you to restore items such as any security set on the folder or files when backed up (in NTFS only).

[pic]

Figure 10: Confirm the restore and check advanced options if needed

|6 The restore process will start. When it is |[pic] |

|finished, you will be presented with an |Figure 11: Advice that the restore is complete |

|option to view the report. Again, in a ‘live’| |

|environment, you would save this file for | |

|future reference. | |

|7 View the report and check the contents (in | |

|Figure 12). | |

|8 Close all the open windows including the backup |[pic] |

|program. Check the backup folder. The files that |Figure 12: Restore report |

|you deleted before should now be restored. | |

|Although the above exercises are relatively | |

|straightforward, they should give you an idea on | |

|how to backup and restore data on a computer | |

|system. It is very important that the data being | |

|backed up is checked for the restore process. | |

It’s no use saying ‘I thought it’d restore OK’ after the event. (Hopefully you checked the advanced options and found that there is an option to verify the backup and restore, so to determine that the process has written the data to the media and then checked that it matches the original data.)

Documenting the backup

The essential items that should be recorded within your backup documentation are listed in Table 2.

Table 2: Backup documentation checklist of items to be included

|The selected options during the backup configuration procedure | |

|The device that was backed up | |

|What file system/s was involved | |

|The name of the server or workstation | |

|Date and time (clearly identified) | |

|Who performed the backup | |

|Who verified the backup | |

|Whether the backup done was attended or unattended | |

|Whether the backup was scheduled and how it meets the organisational guidelines. | |

|If it was not scheduled, state why it was performed and how it conforms to the disaster recovery plan.| |

|Whether there was any unusual incident during the backup. For example, irregular electrical activity | |

|such as flickering overhead lights. Known irregularities with the network or backup may require the | |

|process to be stopped and restarted to ensure data integrity. | |

Off-site backup storage

When you have backed up your data, it is important the backup media be removed from the vicinity of the system backed up. The obvious reason for this is that if an incident like flood or fire were to happen, then the backup media would also be destroyed.

Organisations have different methods for storing backups off-site. The simplest way is to have an employee take the backup media to an off-site location such as the local bank, or the company’s external auditors (as specified in a disaster recovery plan—hopefully not an auditor’s office in the same building, or a bank on the same flood plain as the organisation).

Another option is to back-up the data to a remote location via a wide area or local area network. Advantages include no need of backup media, or to carry media offsite. One disadvantage is that a restore cannot be done before networking protocols are in place. Off-line backups to a wide area network can also be hosted by other companies, as a business, yet this can presents security risks in having other people able to access your backup files.

Documenting system restores

When a disaster does occur, data must be restored efficiently and without delay. The disaster recovery plan should specify actions and requirements. It is important that the person responsible for a restore records what is done. Items to be documented, listed in Table 3, are similar to those for backup.

Table 3: Restore documentation items to be included

|All selected options during the restore configuration procedure (for example, was the restore from a | |

|full backup or did it include differential or incremental restores?) | |

|The device restored | |

|The file system(s) involved | |

|Name of server or workstation restored | |

|Time and date | |

|Who performed the restore | |

|Who verified the restore | |

|Whether the restore was scheduled and how it meets the organisational guidelines | |

|If it was not scheduled why it was performed and how it conforms to the disaster recovery plan. | |

|Whether there was any unusual incident during the restore. For example, irregular electrical activity | |

|such as flickering overhead lights. Known irregularities with the network or restore process may | |

|require the process to be stopped and restarted to ensure data integrity. | |

Summary

In this reading you have considered the use of backup schedules and the benefits and limits of different media for backup. A discussion of backup processes included a guided activity using Windows XP to perform backups and performing a restore for checking to ensure validity. Off-site back up methods were outlined and items required for documentation were listed to document both backup and system restores.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download