Search Engine

Loading

Sallar

Sallar
RedhatEnterpriseLinux Blog

Techniques for Backup and Recovery

When hardware components or security measures fail, every administrator must be prepared to recover a system as quickly and efficiently as possible. Preparing for a disaster means having a solid backup procedure and a well- tested recovery process.
Because you can’t always detect when a failure will occur, it is important to create backups on a regular basis depending on how often the data changes and how much time it takes to complete the backup. All the files on the system.

Don’t have to be included in every backup. Consider how often the files change. For example, operating system files such as files in /bin/ and “virtual” files in /proc/ and /dev/ do not need to be backed up because they can easily be reinstalled; this also ensures they have not be compromised if you are restoring after a security breach.
For home directories that constantly change, daily or even hourly backups might be necessary. For the payroll database or LDAP server, weekly backups might be sufficient.
Ultimately, it is up to the system administrator or the system administration team to decide. Each organization has a different set of systems, custom configurations, and a required length of time in which the system must be restored.
What Data to Back Up
Deciding what data to back up is nontrivial and might vary for each system. Here is a list of data to consider:
. Home directories
. Email spools and IMAP directories
. /etc/ directory for various configuration files
. Shared directories
. Database files
. Cron scripts
. Content management directories such as CVS or Subversion

Other thoughts to consider when devising a backup plan:

. Does your backup plan include backups on an offsite server in case of natural disaster or physical damage to the office building or server room?
. Is redundant hardware part of your plan in case of unrecoverable hardware failure?
. Is the total recovery time from backup acceptable for the needs of the company?
. Are you alerted when a system failure occurs?
. Are you alerted when a failure occurs during the backup procedure?
. What is the initial cost of equipment and software?
. What is the total annual cost of the backup media? Does it fit in your allotted budget?
. Does the plan scale if additional systems need to be added?
. Do multiple administrators have the knowledge to recover each system in case of Personnel changes or vacation times?
. Are the processes well-documented so they can be easily accessed and reviewed on a regular basis?

Incremental versus Full Backups
If your organization is large or modifies the same subset of data frequently, you might want to consider incremental backups. You start off with a full backup and then only back up the data that has changed since the last backup. This often saves disk space on the backup servers and shortens the time it takes to perform backups.
Even if you implement incremental backups, it is a good idea to perform a full backup less frequently (for example, every one or two months if the incremental backups are performed weekly). Each time you perform a full backup, the subsequent incremental backups are based on the last full backup. When you do have to recover the system, the restoration process begins with the last full backup and then all the incremental backups are applied. The time it takes to recover will depend on how many incremental backups you must apply.

0 comments:

Post a Comment

Powered by Blogger.

Ads

 
Copyright © Redhat Enterprise linux. Original Concept and Design by My Blogger Themes
My name is Abdul Razaq but people call me Raziq. Here is my home page: www.redhatenterpriselinux.blogspot.com I live in Quetta, Pakistan and work as an IT-Engineer.