Step 2 - Developing a Backup Schedule
Now that we have determined what needs to be backed up and why it is so
important to do so, it is time to design a strategy for how we back up our data.
The first step in this process is developing a schedule. To do so we must answer
a few questions.
How often should my files be backed up?
Very few offices are suffering from backing up too often and most don't back up
often enough. As a rule, files should be backed up whenever they change. This
way, whenever recovery is necessary, no important data is lost due to a gap in
the backup schedule. So the question really is . . . how often does my data
change. Lets look at our list again and ad another column that contains this
information.
Here's our sample company. We are adding one more file type to illustrate a
point.
-
Quickbooks Files - Daily
-
Sales Database - Daily
-
Active Directory - Monthly
-
Customer Data - Weekly
-
Personal Documents - Weekly
-
Emails - Daily
-
IE Favorites - Every minute when I first discovered how useful it was but
now . . . not at all.
Now, that is a pretty useful list, but we are going to attach one more piece of
information to help us decide our backup frequency. Using the same list we are
going to add a column that tells us how often a given file needs to be
recovered. We will rate them as rarely (only in the case of a drive failure),
occasionally (human error sometimes requires a return to an earlier version) or
often (heavily used files that need regular recovery due to human error).
Sample company . . . show us how its done.
-
Quickbooks Files - occasionally
-
Active Directory - rarely
-
Sales Database - often
-
Customer Data - occasionally
-
Personal Documents - occasionally
-
Emails - rarely
-
IE Favorites - rarely
Alright, now we should have enough information to decide on a backup frequency.
For most users the first list probably gives you a good idea of how often
certain files should be backed up. For example, Quickbooks files should probably
be backed up every day while the active directory might only need backing up
once a month.
The second list comes into play when we see the word "often" show up next to a
file type. In our sample company the sales database has "often" next to it. This
may be because the company has a few sales people that are good at selling but
bad with computers. As a result they are constantly making mistakes that require
file recovery to correct. So, our sample company might decide that, while daily
backup might technically be sufficient for the sales database, two or even three
times a day will provide them with more restorable versions and result in less
manual repair in the wake of the blundering sales team.
So, our sample company's backup frequency will look something like this.
-
Quickbooks Files - once a day
-
Active Directory - once a month
-
Sales Database - twice a day
-
Customer Data - once a week
-
Personal Documents - once a week
-
Emails - daily
-
IE Favorites - once a month
So now we know how frequently we have to back up each of our important file
types. Let's move on.
When should these backup jobs take place?
Backing up large files takes resources. Your server, like yourself, can only
process so much information at once. In the same way that it is usually ill
advised for a student to study for a test while attending a lecture on a
completely different subject, your server will probably back up your information
better if it isn't otherwise occupied.
Backing up can also take a significant amount of time if we are dealing with
large files (or a large number of small ones). Backup Jobs should be set up to
account for these time requirements. If you hire an exterminator to fumigate
your house while your on vacation you probably want to schedule a long enough
trip to allow the toxins to dissipate. The same goes for your backup. Give your
program plenty of time to do its work.
With those two things in mind, let's look at our sample company and see how they
might decide to schedule their backup jobs around their other server uses. To do
this we have to answer a few more questions.
What are the company's hours of
operation?
Our sample company works 9-5 (I know, who does that anymore, but bear with me .
. . its a sample). This means that ideally backups will take place between 5 p.m
and 9 a.m. The earlier our sample company can start these backups, taking into
account all those great employees who want to stay a little late, the better.
This will give the job time to complete before those same employees decide to
come in a little early.
But wait, exclaim the very attentive among you, what about that one job that the
sample company wants to run twice a day? That is, of course a tougher question.
This job would need to run during the day to serve its purpose (making sure that
the maximum lost data is a half a day), but the program is in use during the day
and that usage makes the backup less reliable. To solve this we must ask another
question.
Can a time be scheduled during the day when the
program is not in use?
Fortunately for our sample company the answer is yes. By requiring all the sales
staff to take the same lunch break they are able to automatically back up the
sales database during the lunch hour. In this way the mornings data is secured
and work is not severely interrupted.
Those unable to set a schedule like that may need to simply institute a short,
set, down time to back up the changed files from the morning. This 10-15 minute
period of inactivity will probably pay for itself in shortened file recovery
times. If it doesn't, you probably don't need to schedule a backup during the
day.
How long should file versions be stored?
Alright, so we have these backups of our files. A new version is created each
time we back up, but now, what do we do with them? How long do we keep them
around?
Ideally, you should keep your files forever, or at least until you are
absolutely sure you don't need them any more. Hard drive space is becoming a
less and less expensive commodity as drives get bigger and costs come down. The
amount of money spent to purchase one or several 500GB drives can easily be
justified by the potential savings if a restore is needed in the future.
If you can save all your files indefinitely, you can easily revisit a version
saved a year ago and restore it. And they say you can't go back in time to fix
your mistakes.
Companies subject to HIPPA or other regulatory requirements should review those
carefully to assure compliance with their backup file storage and purging (file
deletion) plans.
Finalizing our backup schedule.
There are several different types of backup which we will describe in more
detail later. For now it is enough to understand that a full backup saves copies
of every piece of data in the folders you have set to be backed up. The
differential backup, on the other hand, only backs up those files that have
changed since the last backup job. Again, don't worry, all will be explained in
Step 3 in the
What type of backup should I use? section. This
little bit of information is simply so we can look at our sample company's
backup schedule.
Sample Company Backup Schedule:
Full Backup runs once a month.
Nightly Differential
-
Quickbooks Files
-
Sales Database
- Emails
Mid-day Differential
Weekly Differential
-
Personal Documents
-
Customer Data
-
Active Directory
-
IE Favorites
As you can see our sample company has four different scheduled backup jobs
(full, nightly, mid-day and weekly). Those items that only need a monthly backup
are still backed up weekly because our sample company is unconcerned about
weekend downtime. The goal is to back up everything as often as you can without
interrupting important computer usage. The sample company accomplishes this goal
through four jobs, but you could possibly do it in as few as two. Ideally a
company with a reasonably small amount of changing data could run a full backup
once a month and a differential for all their files once a day. However, larger
files and/or many changing files might make such a plan unfeasible.