Backup
Doc
Full Backup
Full backup is the
starting point for all other backups, and contains all the data in
the folders and files that are selected to be backed up. Because full
backup stores all files and folders, frequent full backups result in
faster and simpler restore operations. Remember that when you choose
other backup types, restore jobs may take longer.
Incremental
Backup
Incremental
backup means backing up everything that has changed since last full
backup.
Differential seems to
be another name for incremental.differential backup offers a middle
ground by backing up all the files that have changed since the last
full backup
What to
backup?
If there is room on
the backup media, and time limits permit running backups long enough,
it probably is wisest to back up everything. You may skip /tmp or
other places where it is known there are only temporary files that
nobody wants to backup.
If space or time
limits place restrictions, consider not backing up the following
Files that come
directly from a CD or other removable media. It may even be faster to
copy them again from CD than restoring from backup media.
Files that can be
regenerated easily. For example, object files that can be made with
make. Just make sure all the source files and compilers are backed
up.
If the Internet
connection is fast, it may be easy enough to download files again.
Just keep a list of the files and where to download them from.
Backup
devices and media
You need some media to store the backups. It is preferable to use removable media, to store the backups away from the computer and to get “unlimited” storage for backups.
If the backups are on-line, they can be wiped out by mistake. If the backups are on the same disk as the original data, they do not help at all if the disk fails and is not readable anymore. If the backup media is cheap, it is possible to take a backup every day and store them indefinitely.
Floppy,Disk,Tapes,CD-R and CD-RW are the medias available for backup
Planning
a Backup
Before doing a backup,
plan it carefully. Consider
Which files are
irreplaceable without a back up. Irreplaceable files probably include
those in users’ home directories (including /root), and
configuration files, such as those in the /etc/ directory.
Which
files are on removable drives, such as cd s or floppies. Since you
probably do not need to back up removable drives, you might unmount
them before doing a complete system
backup.
Which files can be
easily replaced by installing a package or doing a selective install
or upgrade of the operating system. You can save time and storage
space by not including these files in a backup.
Which files are
unnecessary or dangerous to backup. For example, files in /tmp are
probably unnecessary, while restoring some files that are in the
/proc directory could crash the system.
Whether to compress
files using gzip or bzip2 . Compressing saves space, but adds another
step to the backup. Also, while compression is generally reliable, it
creates another stage at which the process can fail.
Whether users are
responsible for backing up their own files. Since only the root user
has full permissions for all files on the system, usually backups are
best done by the root user. However, if users back up their own
files, you might omit backing up the home directory, or at least not
back it up regularly.
Backup Locations for your Linux, Application, Database, Config Files
1. Backups on the same server
This
is probably the straight forward approach. Taking the backup of your
critical information (applications, databases, configuration files,
etc.,) and storing it on a disk on the same server. If you’ve
mounted a remote dedicated backup filesystem using NFS on the local
server, I still consider that as storing the backup on the same
server. The disadvantage of this method is that when the whole system
crashes, or if by mistake you do a rm -rf /, and erased everything on
the system, you’ve lost your backup.
Taking
a backup and storing it on the same server is a good staring point.
In addition to this,
you should consider storing your backups in one of the following
locations.
2. Backups on a different server
Once
you’ve taken the backup on the local server, copy the backup to a
remote server. If you have a qa-server, take a backup of your
production, and restore it on qa-server. Probably you should assign a
dedicated server with lot of space to store backups. When you have a
dedicated server for backup, you can even initiate the backup from
the dedicated remote server, and don’t have to store a copy of the
backup on the local server.
For
database backups, I prefer to take the backup on the local server,
and copy the backup to a remote server. This way, the database backup
copy is located at two different locations. If you lose one backup,
you still have the other one. Also, when the database crashes on the
local server, it is quick and easy to restore it from the backup
located on the same server, instead of copying the backup from the
remote server to the local server and restoring it.
3. Tape backup
If
you don’t have a dedicated backup server to store copy of all your
backups, implement a tape backup solution and store all your backups
on tape. Tape backups are slow. So, take a backup on the local server
first and copy the backup to tape during off peak hours or weekends.
The advantage of tape backup is that the backups are easily portable,
where you can move around the backup anywhere you want.
4. Backup at an Off-site
You
can do all of the above and still get into trouble, when disaster
strikes. If the local server, backup server, and tape backup are all
located at the same physical location, in a diaster situation, you
might lose all the data. So, it is important that you store your
backups at an off-site.
You
can either have a redundant datacenter, where all your critical
applications in the primary datacenter are synced with the disaster
datacenter (or) at a bare minimum, keep a copy of the backup tape at
an off-site location. Don’t physically rotate the tapes and keep it
at the same datacenter, which is useless during a disaster recovery
scenario.
Choosing
a Backup Tool
dump
/ restore :
Old
tools that work with filesystems, rather than files, and can back up
unmounted devices. Although you can easyly control what is backed up
with dump by editing a single column in the /etc/fstab file, for some
reason these utilities have fallen into disuse. Today, many
distributions of Linux, including Debian, do not even include them by
default. If you want to use dump and restore , you must install them
yourself.
tar :
A
standard backup tool, and by far the easiest to use. It is especially
useful for backing up over multiple removable devices using the -M
option.
cpio :
A
very flexible command, but one that is hard to use because of the
unusual way in which the command must be entered.
The dd command is one
of the original Unix utilities and should be in everyone’s tool
box. It can strip headers, extract parts of binary files and write
into the middle of floppy disks; it is used by the Linux kernel
Makefiles to make boot images.
Mondo :
Mondo is
reliable. It backs up your GNU/Linux server or workstation to tape,
CD-R, CD-RW, DVD-R[W], DVD+R[W], NFS or hard disk partition. In the
event of catastrophic data loss, you will be able to restore all of
your data [or as much as you want], from bare metal if necessary.
Mondo is in use by Lockheed-Martin, Nortel Networks, Siemens, HP,
IBM, NASA’s JPL, the US Dept of Agriculture, dozens of smaller
companies, and tens of thousands of users.
Dar:
dar
is a shell command that backs up directory trees and files. It has
been tested under Linux, Windows, Solaris, FreeBSD, NetBSD, MacOS X
and several other systems
Many commercial or free software back up tools are also available.
No comments:
Post a Comment