POLYTECHNIC UNIVERSITY OF THE PHILIPPINES
OPEN UNIVERSITY SYSTEM
MIT 620 ADVANCE ORGANIZATION OF DATABASE
Database Issue : INCOMPLETE BACKUP AND FAILURE TO ENCRYPT
BACKUP DATA
Assignment No. 1
Date Submitted:
October 6, 2013
Submitted By:
Sherlita B. Magpantay
Dr. Rosecar E. Escober
(Instructor – Advance Organization of Database)
I
DATABASE SECURITY ISSUE:
Incomplete Backup and Failure to Encrypt Backup data
II
ABSTRACT
The Database Environment Database servers are the most important systems in virtually
all organizations. They store critical information that supports business including the following:
Email, Financial Data, Sales Data, Personnel Data, Intellectual Property, Operation, and Security
Data, etc. Modern Databases are created using Structured Query Language (SQL) which is the
standard for database interoperability Relational Database Management System. This refers to
the software system that is used to create a database and they include well known products such
as Oracle, MS SQL and MS Access, IBM DB2 and Informix, Teradata (NCR), Sybase, Postgre
SQL, MySQL. I decided to tackle some of the harder, more interesting questions that we've
heard asked about SQL Server backup and restore.
I.
INTRODUCTION
[2] The Backup program helps you protect data from accidental loss due to hardware or storage
failure. Using Backup, you can create a duplicate copy of the data on your hard disk and archive
the data on another storage device such as a hard disk or a tape. You can back up data to a wide
variety of removable, high-density storage media. Also, Backup is integrated with Remote
Storage for archiving.
With Backup wizards you can:

Make an archived copy of selected files and folders on your hard disk.

Schedule regular backups to keep your archived data up-to-date.

Restore the archived files and folders to your hard disk or any other disk you can access.

Back up Active Directory. You can put a copy of Active Directory store on media for offsite storage.

Back up offline Remote Storage data, registry settings, and any other mount point data.
Database or log backups can be appended to any disk or tape device, allowing a database,
and its transaction logs, to be kept within one physical location. SQL Server uses an online
backup process to allow a database backup while the database is still in use. If a backup is started
when one of these operations is in progress, the backup ends. Cross-platform backup operations,
even between different processor types, can be performed as long as the collation of the database
is supported by the operating system.
SQL Server backups can coexist on tape media with Windows NT backups because the
SQL Server 2000 backup format conforms to Microsoft Tape Format (MTF); the same format
used by Windows NT tape backups. To ensure interoperability, the tape should be formatted by
NTBackup.
Use BACKUP to back up database files and filegroups instead of the full database when
time constraints make a full database backup impractical. To back up a file instead of the full
database, put procedures in place to ensure that all files in the database are backed up regularly.
Also, separate transaction log backups must be performed. After restoring a file backup, apply
the transaction log to roll the file contents forward to make it consistent with the rest of the
database. Backup devices used in a stripe set must always be used in a stripe set (unless
reinitialized at some point with FORMAT) with the same number of devices. After a backup
device is defined as part of a stripe set, it cannot be used for a single devicebackup unless
FORMAT is specified. Similarly, a backup device that contains nonstriped backups cannot be
used in a stripe set unless FORMAT is specified. Use FORMAT to split a striped backup set.
If neither MEDIANAME nor MEDIADESCRIPTION is specified when a media header is
written, the media header field corresponding to the blank item is empty.
BACKUP LOG cannot be used if the recovery model is SIMPLE. Use BACKUP DATABASE
instead.
Interaction of SKIP, NOSKIP, INIT, and NOINIT This table shows how the { INIT | NOINIT }
and { NOSKIP | SKIP } clauses interact.
Note: In all these interactions, if the tape media is empty or the disk backup file does not exist,
write a media header and proceed. If the media is not empty and does not contain a valid media
header, give feedback that this is not valid MTF media and abort the backup.
SKIP
INIT
NOINIT
If the volume contains a valid1 media
If the volume contains a valid
header, verify the media password
media header, verify the media
and overwrite any backup sets on the
password and append the backup
media, preserving only the media
set, preserving all existing backup
header.
sets.
If the volume does not contain a valid
If the volume does not contain a
media header, generate one with the
valid media header, an error occurs.
given MEDIANAME,
MEDIAPASSWORD, and
MEDIADESCRIPTION, if any.
NOSKIP
If the volume contains a valid media
If the volume contains a valid
header, perform the following
media header, verify the media
checks:
password* and verify that the
media name matches the given

Verify the media password.2

If MEDIANAME was

MEDIANAME, if any. If it
matches, append the backup set,
specified, verify that the given
preserving all existing backup sets.
media name matches the
If the volume does not contain a
media header's media name.
valid media header, an error occurs.
Verify that there are no
unexpired backup set(s)
already on the media.
If there are, abort the backup.
If these checks pass, overwrite any
backup sets on the media, preserving
only the media header.
If the volume does not contain a valid
media header, generate one with the
given MEDIANAME,
MEDIAPASSWORD, and
MEDIADESCRIPTION, if any.
1. Validity includes the MTF version number and other header information. If the version
specified is unsupported or an unexpected value, an error occurs.
2. The user must belong to the appropriate fixed database or server roles and provide the correct
media password to perform a backup operation.
In addition, the user may specify passwords for a media set, a backup set, or both. When
a password is defined on a media set, it is not enough that a user is a member of appropriate
fixed server and database roles to perform a backup. The user also must supply the media
password to perform these operations. Similarly, restore is not allowed unless the correct media
password and backup set password are specified in the restore command.
Defining passwords for backup sets and media sets is an optional feature in the BACKUP
statement. The passwords will prevent unauthorized restore operations and unauthorized appends
of backup sets to media using SQL Server 2000 tools, but passwords do not prevent overwrite of
media with the FORMAT option.
Thus, although the use of passwords can help protect the contents of media from unauthorized
access using SQL Server tools, passwords do not protect contents from being destroyed.
Passwords do not fully prevent unauthorized access to the contents of the media because the data
in the backup sets is not encrypted and could theoretically be examined by programs specifically
created for this purpose. For situations where security is crucial, it is important to prevent access
to the media by unauthorized individuals.
It is an error to specify a password for objects that were not created with associated passwords.
BACKUP creates the backup set with the backup set password supplied through the
PASSWORD option. In addition, BACKUP will normally verify the media password given by
the MEDIAPASSWORD option prior to writing to the media. The only time that BACKUP will
not verify the media password is when it formats the media, which overwrites the media header.
Ownership and permission problems on the backup device's physical file can interfere with a
backup operation. SQL Server must be able to read and write to the device; the account under
which the SQL Server service runs must have write permissions. However, sp_addumpdevice,
which adds an entry for a device in the system tables, does not check file access permissions.
Such problems on the backup device's physical file may not appear until the physical resource is
accessed when the backup or restore is attempted.
II.
BACKGROUND
The Backup utility in the Microsoft Windows Server 2003 operating systems helps you protect
your data if your hard disk fails or files are accidentally erased due to hardware or storage media
failure. By using Backup, you can create a duplicate copy of the data on your hard disk and then
archive it on another storage device, such as a hard disk or a tape. If the original data on your
hard disk is accidentally erased or overwritten, or becomes inaccessible because of a hard-disk
malfunction, you can easily restore it from the disk or archived copy. Backup uses the Volume
Shadow Copy service to create an accurate copy of the contents of your hard drive, including any
open files or files that are being used by the system.
Using Backup, you can:

Archive selected files and folders on your hard disk.

Restore the archived files and folders to your hard disk or any other disk you can access.

Make a copy of your computer’s System State data.

Use Automated System Recovery (ASR) to create a backup set that contains the System
State data, system services, and all disks associated with the operating system
components. ASR also creates a floppy boot disk that contains information about the
backup, the disk configurations (including basic and dynamic volumes), and how to
restore your system.

Make a copy of any Remote Storage data and any data stored in mounted drives.

Create a log of what files were backed up and when the backup was performed.

Make a copy of your computer’s system partition, boot partition, and the files needed to
start up your system in case of a computer or network failure.

Schedule regular backups to keep your archived data up-to-date.
Backup also performs simple media management functions such as formatting. You can perform
more advanced management tasks such as mounting and dismounting a tape or disk by using
Removable Storage, which is a feature in Windows Server 2003.
Types of Backup
Type
Description
Copy backup
Copies all the files that you select, but does not mark each file as having been
backed up (in other words, the archive attribute is not cleared). Copying is useful if
you want to back up files between normal and incremental backups because
copying does not affect these other backup operations.
Daily backup
Copies all the files that you select that have been modified on the day that the
daily backup is performed. The backed-up files are not marked as having been
backed up (in other words, the archive attribute is not cleared).
Differential
backup
Copies files that have been created or changed since the last normal or
incremental backup. It does not mark files as having been backed up (in other
words, the archive attribute is not cleared). If you are performing a combination of
normal and differential backups, you must have the last normal as well as the last
differential backup to restore files and folders.
Incremental
backup
Backs up only those files that have been created or changed since the last normal
or incremental backup. It marks files as having been backed up (in other words, the
archive attribute is cleared). If you use a combination of normal and incremental
backups, you will need to have the last normal backup set as well as all incremental
backup sets to restore your data.
Normal
backup
Copies all the files that you select and marks each file as having been backed up (in
other words, the archive attribute is cleared). With normal backups, you only need
the most recent copy of the backup file or tape to restore all of the files. You
usually perform a normal backup the first time you create a backup set.
If you want the quickest backup method that requires the least amount of storage space, you
should back up your data using a combination of normal backups and incremental backups.
However, recovering files from this combination of backups can be time-consuming and difficult
because the backup set might be stored on several disks or tapes. If you want to restore your data
more easily, you should back up your data using a combination of normal backups and
differential backups. This backup set is usually stored on only a few disks or tapes. However, this
combination of backups is more time-consuming.
In Backup, you can restore distributed services data that is part of the System State data, such as
the Active Directory database, using one of three restore methods:

Primary restore

Normal (nonauthoritative) restore

Authoritative restore
To understand how each restore method works, it is important to understand how the Backup
utility backs up data for distributed services. When you back up the System State data on a
domain controller, you are backing up all Active Directory data that exists on that server (along
with other system components such as the SYSVOL directory and the registry). To restore these
distributed services to that server, you must restore the System State data. However, the number
and configuration of domain controllers in your system will dictate the type of restore method
you choose.
For example, if you need to roll back replicated Active Directory changes, but have more than
one domain controller in your organization, you will need to perform an authoritative restore to
ensure that your restored data gets replicated to all of your servers. However, if you need to
restore Active Directory data on a stand-alone domain controller or on the first of several domain
controllers, you will need to perform a primary restore. If you need to restore Active Directory
data on just one domain controller in a system where Active Directory data is replicated across
several domain controllers, you can use a normal restore if your restored data does not have to be
replicated to all your servers.
Primary restore
Use this type of restore when the server you are trying to restore is the only running server of a
replicated data set (for example, the SYSVOL and File Replication service are replicated data
sets). Select primary restore only when restoring the first replica set to the network. Do not use a
primary restore if one or more replica sets have already been restored. Typically, perform a
primary restore only when all the domain controllers in the domain have failed, and you are
trying to rebuild the domain from backup.
Distributed Data
Reason for Using Primary Restore of System State Data
Active Directory
Restoring a stand-alone domain controller.
Restoring the first of several domain controllers.
SYSVOL
Restoring a stand-alone domain controller.
Restoring the first of several domain controllers
Replica sets
Restoring the first replica set.
Normal restore
During a normal restore operation, Backup operates in nonauthoritative restore mode. That is,
any data that you restore, including Active Directory objects, will have their original update
sequence number. The Active Directory replication system uses this number to detect and
propagate Active Directory changes among the servers in your organization. Because of this, any
data that is restored nonauthoritatively will appear to the Active Directory replication system as
though it is old, which means the data will never get replicated to your other servers. Instead, if
newer data is available from your other servers, the Active Directory replication system will use
this to update the restored data. To replicate the restored data to the other servers, you must use
an authoritative restore. To authoritatively restore Active Directory data, you need to run the
Ntdsutil utility after you have restored the System State data but before you restart the server.
The Ntdsutil utility lets you mark Active Directory objects for authoritative restore. When an
object is marked for authoritative restore its update sequence number is changed so that it is
higher than any other update sequence number in the Active Directory replication system. This
will ensure that any replicated or distributed data that you restore is properly replicated or
distributed throughout your organization.
For example, if you inadvertently delete or modify objects stored in Active Directory, and
those objects are replicated or distributed to other servers, you will need to authoritatively restore
those objects so they are replicated or distributed to the other servers. If you do not
authoritatively restore the objects, they will never get replicated or distributed to your other
servers because they will appear to be older than the objects currently on your other servers.
Using the Ntdsutil utility to mark objects for authoritative restore ensures that the data you want
to restore gets replicated or distributed throughout your organization.
III.
STATEMENT OF THE PROBLEM
The problem of data security has three aspects: secrecy, integrity and availability. A complete
solution to the secrecy problem requires high-assurance multilevel sys- tems, which impose
mandatory controls and are known to be free of covert channels. Such systems are not currently
available in the market, and are at the research and development stage. In due course of time
products should become available. In the interim, security administrators must be aware of the
limitations of discretionary ac- cess controls for achieving secrecy. Discretionary access controls
cannot cope with Tro jan Horse attacks. It is therefore important to ensure that only high quality
soft- ware of known origin is used in the system. (This attitude also supports the integrity.
objectives.) Moreover, security administrators must appreciate that even the mandatory controls
of high-assurance multilevel systems do not directly prevent inference of secret information. The
integrity problem, somewhat paradoxically, is less well understood than secrecy but is better
supported in existing products. The basic foundation for integrity is to ensure that all updates are
carried out by well-formed transactions. This facility is reasonably well supported by current
products. On the other hand integrity principles such as least privilege, separation of duties and
delegation of authority are not so well supported. These are still in the domain of research and
development. The availability problem is very poorly understood, and therefore existing products
do not address it to any signicant degree.
1.
Can I restore a backup onto a different version of SQL Server? What snags might I
hit?
You can restore to a different version of SQL Server, but you can only restore upwards. In other
words, you can restore from 2000 to 2005 or from 2005 to 2008R2 or from 2008 to 2012, but
you can never restore in the reverse direction. Each version of SQL Server makes modifications
to the binary of the database and its storage. Microsoft doesn't go back in time and rewrite the
previous versions to support these changes. If you really need to restore downwards, you might
need to try scripting out the schema and data (see, for example, Downgrading from SQL 2008 to
2005 by Jonathan Kehayias).
In order to from which version of SQL Server a backup originated, you need to look at the
header of the backup file:
RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak';
This information returned includes details of the Major, Minor and Build versions of the SQL
Server instance for that backup, as shown in the screenshot below. This allows you to validate
that you are attempting to restore an appropriate version.
When restoring a database to a newer version of SQL Server, it is possible to hit incompatibilities
within the database. The safest approach is to run Microsoft's Upgrade Advisor (a free tool
available for each version of SQL Server) on the database you wish to migrate, in order to ensure
that it's ready, and then take a backup and restore it to the new instance (don't do it the other way
round i.e. attempt the restore then run the advisor).
After the restore, the database will be running in the compatibility mode that id had prior to
the upgrade. This means that it will be set to support the functionality of the version of SQL
Server from which you migrated. In order to take full advantage of the new version of SQL
Server, you will need to modify the compatibility level of your database. You can do this
through the GUI, or by running this T-SQL:
ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;
The different numbers represent different versions of SQL Server; 90 for 2005, 100 for 2008 and
2008R2 and 110 for 2012.
Finally, not all upgrades are possible. Microsoft only allows you to jump forward a maximum of
two versions. For example, you cannot restore a SQL Server 2000 database backup to a 2012
instance. You would first need to restore it to 2008, update the compatibility level, perform a
backup, and then restore that backup to 2012.
2.
Can I use a restore to copy a database? What could go wrong?
Yes, you can use a restore to copy a database. If you are restoring to a new server, you just need
to make sure that your drives are the same on that server or that you map the files of the database
to the appropriate drives on the new server using the WITH MOVE option of the RESTORE
DATABASE command:
RESTORE DATABASE NewDBName
FROM DISK = 'c:\bu\mm.bak'
WITH MOVE 'OldDB' TO 'c:\data\new_mm.mdf',
MOVE 'OldDB_Log' TO 'c:\data\new_mm_log.ldf';
Database files have a logical name and a physical file name. You just have to identify the logical
name of each file and assign it to a new location.
The main issues you might encounter are in the form of errors arising from insufficient space for
the restored database, in the new location, or because you forgot to supply a new name and
attempted to restore over the top of your existing database.
When restoring the database on a different instance of SQL Server you might hit problems with
'Orphaned Users', if the database user is mapped to a SID that is not present in the new server
instance. You would need to fix this.
3.
Why can't I just backup SQL Server's data files with my Windows backup tool? I
don't need up-to-the-minute backups.
SQL Server is not like a word processing application. It manages its own files internally in order
to guarantee the ACID (Atomic, Consistent, Isolated, Durable) properties of its databases. In a
nutshell, to ensure that a transaction completes successfully, SQL Server maintains very tight
access control over its files and it modifies theses files as it sees fit. If you simply copy the data
file, ignoring the locks and ignoring the transactions that may be currently in progress, it means
that when you attempt to attach that database later you will have a database file that is in an
inconsistent state. It will generate errors. Only if you are in a situation where the database is
completely unchanging, ever, could you reliably copy the file and attach it later. However, if
there is even a remote possibility of a transaction being open on the system when you copy the
file, you're extremely likely to have an unsuccessful backup. The only safe way to ensure no
transactions are running when you run your Windows backup tool would be to take the database
offline first.
It's is much safer and easier to use SQL Server backups in order to ensure that you have a safe
copy of your database that respects the ACID properties of the transactions within it. It is much
easier to do a normal database backup.
4. It is only a small database. Why can't I just write every table to disk to back it up?
Yes, you can use a tool like SQLCMD to write the tables to flat file but then, instead of a
straightforward, single statement to restore the database, you will need a whole series of
commands. First, you'll need to create an empty database. Then, you'll need a process to create
and load each table. If any of the tables has an IDENTITY column, you'll need to SET
IDENTITY_INSERT on for each of those tables. You'll also have to worry about the order in
which you load data into the tables, to take into account any relational integrity between them.
Even then, you'll have written each table to disk at a separate point in time, so if any data
modifications were in progress at the time, the data wouldn't necessarily be consistent between
related tables. If it isn't then you'll have to clean the data by hand afterwards before you can
enable constraints. You absolutely can do all that work. Alternatively, you can just run a backup
and then, when needed, a restore, which is the much smarter approach.
5. SQL Server has native backup. Why pay money for a tool to do it?
There are three primary reasons why you might want to purchase a tool to help with your
backups: guidance,automation and utility. If you are just getting started as a DBA, or, you're not
a DBA at all and but you're managing a database system as a secondary part of your job, you
may not know a lot about how, where and why to set up SQL Server backups. A good third party
product (e.g SQL Backup Pro) will provide you with exactly the kind of guidance you need to
help you get your databases protected through the backup process.
SQL Server backups work extremely well, but you're going to have to do some work to get them
set up and even more to get them automated. A good third party product will make this
automation process very simple. Further, you can get automation of other processes related to
backups such as mirroring/log shipping and backup verification.
Finally, while native SQL Server backups do what you need, they may not be doing so in a "best
of breed" fashion. For example, some tools more efficient at compressing backups, saving even
more disk space and time during your backup processes. They also add functionality such as
encryption of the backup files, something only possible natively through SQL Server if you've
also encrypted the database.
6. If I leave a backup on a network share, surely nobody can read it?
Unless you encrypt the backup file directly, then yes, that is a readable file. If someone got
access to the network share, he or she could read the backup file directly using a text editor, or
simply copy the file and run a restore on another instance of SQL Server.
It's even possible to extract the schema code or the data from the backup file without restoring
it. If you have SQL Data Compare, then the /Export command line parameter wil allow you to
read all the data out of the backup, in CSV format, by comparing the backup to a blank
database, without any password being required. Likewise, a similar process with SQL
Compare will allow you to create a compete script to recreate the database schema.
You must take steps to prevent unauthorized access of a backup file. First off, make sure the
network location where you're storing backups is only available to a select group of people.
Next, only keep the backups there that you actually need. Don't keep extra copies of a backup
locally unless you have to. Finally, if you're using a third party tool (e.g SQL Backup Pro),
you can encrypt the backup to ensure that even if someone inappropriate has access to the file,
he or she won't be able to read it.
With native backups, you'd have to first encrypt the actual data and log files, using
Transparent Data Encryption (TDE).
The very best solution for security involves defense in depth, meaning, do all of the above.
7. Can someone change the contents of a backup?
There is no direct way to modify the contents of a backup file. Since the backup is a page-bypage copy of the database, as it existed the moment you took the backup, a restored copy of
that database will be in exactly the same state as it was the moment you took the backup.
When SQL Server reads each page, during the restore, it will calculate a checksum, based on
its contents, and compare it to the value when it read the page during the backup (assuming
you enabled checksums during backup). If someone did manage to change the data within the
backup, these values won't match and SQL Server will flag the page as corrupt.
8. If I've set the verify flag when doing a backup, surely it can always be restored.
If by the verify flag, you mean that your backup process includes running a RESTORE
VERIFYONLY operation after the backup is complete, then no, you won't be assured that the
backup can be restored. The RESTORE VERIFYONLY operation can perform two sets of
checks.
Firstly, it reads the backup header to ensure that it is correct. If some corruption had affected
the header, this would prevent your restore from running correctly.
RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
A second check becomes possible only if you are also running BACKUP WITH
CHECKSUM for your backup operations. This means that during the backup SQL Server will
recalculate the checksums as it reads each page to back up. If it finds a page that fails this test,
the backup will fail. If it completes successfully, BACKUP WITH CHECKSUM computes a
checksum over the backup file.
Subsequently, we can use the RESTORE VERIFYONLY to re-validate the backup file
checksum to help ensure that nothing has corrupted the file during storage.
RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
WITH CHECKSUM
The problems come in two places. First, the header verification process of VERIFYONLY
doesn't check every single aspect of the header that could affect the restore process. This
means that you can pass the VERIFYONLY test, but still fail a restore.
Second, CHECKSUM cannot detect corruption that may have occurred in-memory. If a data
page cached in memory is updated, and then some in-memory corruption occurs before the
modified page is written back to disk (and subsequently to backup), then the checksums will
not catch this corruption.just validates that your backup wrote the pages that it read. If those
pages are corrupted internally in the database, CHECKSUM won't tell you and your restore
can fail.
The only way to know for sure that a backup will restore is to restore it and preferably run a
database consistency check on the restored copy.
9. Does a backup contain more than the data? Can someone read passwords from it?
A backup does contain more than just the data. It contains the entire structure of the database.
This includes all the data structures and data, of course, but it also includes all the procedures,
views, functions and any other code. It also contains the settings and definitions of the
database. Finally, it includes the users of the database. For a regular database, each user maps
to a login on the server. The passwords for those users would be stored with the login, not
with the user, so these passwords would not be available through the backup.
However, contained databases have a concept called USER WITH PASSWORD, since the
idea behind a contained database is to have a database that is divorced from relationships with
the server. In this case, the password will be stored with the backup, which does make it
subject to the possibility of hacking attempts. The passwords are not stored in plain text;
they're hashed the same way as the login passwords (which would be in the masterdatabase
and hence in the backups of master)
Microsoft discusses some of the security best practices within MSDN as they relate to
contained databases.
10. Do I have to backup indexes, statistics and other stuff that is easy to recreate? It
seems a waste.
On the contrary, I'd argue that it's a waste of time to try to split things out like this, and only
backup up some of it. Firstly, how would you do it? For example, how do you back up the
data without backing up the clustered indexes? You can't; those clustered indexes are the data
pages. To all intents and purposes, those are your tables, so now you have to include clustered
indexes. Possibly, you could split the non-clustered indexes into a separate filegroup that you
don't back up, but then during a restore, you're still going to have to bring that filegroup back
online and rebuild the indexes, so what have you gained?
Another problem comes from statistics on your indexes. SQL Server backs up these statistics
with a database (and they take up very little room, since the histogram that defines a set of
statistics is only 200 rows long), and restores them with the database. However, if you have to
recreate your indexes after a restore operation, because you opted not to back them up, then you
also have to recreate your statistics. This extends still further the time it takes to restore your
database, keeping the business offline longer.
Overall, I would challenge you to define "easy to recreate", because getting these things back
online in the event of an emergency could be a very complicated, multi-step process that will
inevitably leave the business people and customers dependent on your database waiting much
longer during disaster recovery.
The whole idea of having a backup is to be able to do a restore quickly and efficiently. The more
difficult you make the restore process, the more you lessen the utility of that backup. Yes, there is
some additional space needed to backup indexes, foreign key constraints, users and stored
procedures, but the increased speed you get from having everything in one place is well worth
that small increase.
11.
OMG! I've just deleted a table! I know it is in the log. How do I get it back?
Once as transaction is committed, there is no undo from SQL Server. A DELETE operation and
a TRUNCATEoperation remove data in slightly different ways. The DELETE removes the data
through a transaction that removes each row. The TRUNCATE simply de-allocates the page
storage of the data. Neither one can easily be recreated by going through the log manually.
Instead, you need to perform a process called a point in time recovery. You should immediately
take a log backup of your database in order to preserve the changes up to the moment when you
accidentally removed the data from the table. Then, you should follow the steps outlined in
Chapter 6 of SQL Backup and Restore to restore to a point in time.
Another option you have is to open up SQL Backup Pro, which has a built-in wizard that will run
you through anobject-level restore process. It will find all the appropriate backups to allow you
to retrieve your table and get it back online.
12.
I just want to extract a build script from a backup without restoring it…?
No native method will allow you to extract a build script from a backup, without running a
restore. However, a tool such as SQL Compare will allow you to generate a complete database
build script from a backup. Although it is easy to do it from the GUI, you can also do it from
PowerShell
& 'C:\Program Files (x86)\Red Gate\SQL Compare 8\SQLCompare.exe'
/Backup1:C:\MyBackups\MyBackupFile.bak /MakeScripts:"C:\MyScripts\MyBackupScript"
You can also do this if you look at SQL Virtual Restore. This tool allows you to mount a database
backup to your SQL Server system as if you were running a restore process, but without
requiring all the disk space that a restore would need. The mounted backup will look like and
perform like a database, as far as SQL Server is concerned. With the database mounted, you can
use any method you already use to generate a script, in just the same way you would with a real
database.
13. What are common problems possible to encounter with Tape and Backup Media?
According to Kroll Ontrack specialises in tape data recovery including overwtitten tape
and Exchange database corruption. We have developed, both in-house and in conjunction with
manufacturers, an unrivalled range of hardware and software tools to deal with almost every
situation. If your data is there, we will recover it. Some of the most common issues we encounter
are:

Damaged tape

Media error

Restore fails

Tape appears to be blank

Overwritten tape

Erased tape

Drive hangs

Exchange database corruption
Tape is a fragile medium and suffers It is not suited to random access operations but provides an
effective, high capacity and yet low-cost solution to the problems of securing your data.
Damaged Tape
Snapped or creased: Ontrack can recover any data from undamaged areas of tape, and often
even from areas where there is some apparent damage.
Fire or Flood: Any attempt to read the tape will probably result in further damage to both tape
and drive. Ontrack has extensive experience of these problems and can prepare your tape so
further data loss is prevented and an optimal recovery is achieved.
Fire or extreme heat will cause data loss and might result in a failure of the tape mechanism. Any
attempt to read from the tape will fail and might cause the tape to snap or become wound inside
the drive mechanism. Our painstaking approach and expertise have recovered data from tapes
damaged by even severe fires.
Media Error/Restore fails
Read error/ failure: At Ontrack we will read all unaffected areas of the tape and then, by using
our in-house software tools or by writing bespoke code, we will restore the files from your tape.
Tape appears to be blank
Blank tape: Your software tells you that the tape must be formatted or initialised before it can be
used. Ontrack's specialised hardware will bypass the problem to recover your data.
Overwritten Tape/Erased Tape
Overwritten data: You have just started a backup and then realised that you are overwriting the
only copy of your business-critical data. This becoming one of the most common issues we deal
with. Ontrack can access any unaffected area of tape and recover your data.
Drive Hangs
Tracking: You might have a serious media failure or a head alignment problem. Ontrack has an
unrivalled range of tools to compensate for the problem and recover your data.
Poor recording: Sometimes a recording flaw can be serious enough to cause the drive firmware
to crash and paralyse your entire system. Ontrack's recovery drives are designed to cope with
such a situation.
Incomplete recording: A hardware error during writing could have abnormally terminated a
backup session. Some backup utilities require access to an on-tape directory that is written once
the backup is complete. If the directory is incomplete or corrupt then the software could freeze or
fail.
14. How to protect the Password for Backup?
This option is to enable or disable encryption of the data that is being backed up. StoreGrid uses
a well known encryption algorithm, AES. If enabled, a password has to be specified which will
be used for generating the encryption key. Encrypting data ensures that it cannot be read in the
destination machine (backup server) where your backup is stored, and is especially relevant for
sensitive information.
Password Protection
This option is to enable System Generated Encryption Key or use a Customized Encryption key
for encrypting the backup data.
System Generated: The selected files and folders will be encrypted using AES algorithm with a
256 bit encryption key automatically generated by StoreGrid before been backed up. No
password will be required while restoring the data. Make sure you use this option only when the
backup server is setup such that the backup server requires the client machines to authenticate
before accepting the backup from the client.
Custom: This will enable the user to select the custom Encryption Technique, Encryption Key
Size and the Encryption Key that needs to be used for encrypting the selected files and folders.
Please don't lose the customized encryption key, as the backed up data cannot be restored without
this key.
Default Encryption Password: The selected files and folders will be encrypted with the Default
Encryption Password as provided in the "Settings -> Advanced Options -> Default Encryption
Password" page. Default Encryption Password is a convenient way to use the same password for
all the backup schedules created in this client machine. It saves you from having to remember a
different password for each backup set.
Encryption Technique
StoreGrid supports encryption using AES. The AES is a Cipher Block Chaining from the
Advanced Encryption Standard (AES) technique which provides encryption based on the size of
the encryption key length (128 bits and 256 bits). Higher the number of bits stronger is the
encryption.
Encryption Key Size
StoreGrid supports encryption using variable length (128 and 256 bits for AES) keys. The key is
generated using the password you provide.By default, 256 bits is chosen
Type Password
Provide a password here to generate the encryption key. If the password is forgotten the data can
never be recovered as the data cannot be decrypted without this password. So, please ensure that
you keep your password in a safe place.
Full Backup Scheduling (Decide When To Do Full Backup)
This step allows you to configure the frequency at which a full backup of the selected database
has to be done. A full backup is a complete backup of the selected databases and all necessary
log files. Once full backup completes, all log files older than the time when full backup started
would be purged. Since full backups take more time to complete than a differential or
incremental log backup, a full backup is typically configured to run weekly or monthly or much
less frequently than differential or an incremental backup. Configuring a full backup scheduling
is mandatory, i.e. this step cannot be skipped. StoreGrid will do a full backup dump of the
Exchange Server database(s) whenever the full backup is scheduled and back it up.
This step has the following options from which any one can be chosen.
Run Monthly At - Choose the time and day of the month the backup should run. StoreGrid will
run the backup every month on the particular day and time chosen. StoreGrid will run at the
stipulated time/day only.
Run Weekly - Choose the time and the day of the week the backup should run. StoreGrid will
execute the backup every week on the particular day and time chosen. Note that you can select
multiple days of the week if you wish to run the backup on multiple days of the week. StoreGrid
will run at the stipulated time/day only.
Run Daily - Choose the time at which the backup should run daily. This will execute the backup
everyday at the time you have provided. StoreGrid will run at the stipulated time only.
Run Every Few Hours - Choose the hours/minutes interval between each time StoreGrid must
run. If StoreGrid is restarted in the interim, the backup will run once StoreGrid starts.
Thereafter, StoreGrid automatically reschedules the next backup after the period you’ve set. For
example, if you created a backup schedule at 10 am and set it to run every 1 hour, StoreGrid will
first run the schedule at 10am and the next scheduled time will be 11am. However, if at
10.15am, StoreGrid is restarted, then the schedule will run once at 10.15am and the next
scheduled time will now be set to 11.15am.
Additionally, you can also select the days in which this schedule should run. For example, if you
do not want to run this backup schedule on Saturdays and Sundays, uncheck the checkbox
against these days.
SQL Backup warning codes
The following warning codes may be returned by SQL Backup.
Warning Description
code
110
Failed to save primary log file: <value>
The primary log file records details of backup and restore operations.
Check that the startup account for the SQL Backup Agent service has rights to create files in the reported
directory. Also check that the directory has sufficient free space. By default, the log files will be stored in
%ALLUSERSPROFILE%\Application Data\Red Gate\SQL Backup\Log\ on the machine on which the
SQL Backup server components are installed.
You can change the location of the log file using the file management options.
115
LOGTO error: Failed to save log file: <value>
This log file, specified by the LOGTO option, records details of backup and restore operations.
Check that the startup account for the SQL Backup Agent service has rights to create files in the listed
directory. Also check that the directory has sufficient free space.
120
LOGTO error: Folder does not exist: <value>
The LOGTO option specifies a log file for recording details of backup and restore operations. SQL
Backup couldn't create the directory for this log file.
Check that the startup account for the SQL Backup Agent service has rights to create the directory.
121
LOGTO error: Default log file folder does not exist: <value>. Log file will be saved in folder: <value>.
The LOGTO option specifies a log file for recording details of backup and restore operations. SQL
Backup couldn't create the log file in the default directory, but has successfully created the log file in the
reported directory.
Check that the startup account for the SQL Backup Agent service has rights to create files in the default
directory.
130
MOVETO error: Failed to move file: <value>
SQL Backup failed to move a file to the specified directory. Check the error message for the cause of the
failure.
In most cases, this problem occurs when the startup account for the SQL Backup Agent service does not
have appropriate rights. The startup account must be able to write to the specified directory, and delete
the source file.
If this error arises during log shipping, it is often because the MOVETO parameter is not moving files out
of the network share. Edit the Log Restore job so that the restored log files are moved to a different
folder. You will need to do this via a SQL application such as SSMS. See Configuring log shipping for
more information.
131
MOVETO error: Failed to execute MOVETO command.
SQL Backup failed to move the file as specified by the MOVETO command. Check the error message for
the cause of the failure.
132
MOVETO error: Folder does not exist: <value>
SQL Backup failed to move the file as specified by the MOVETO command, because the specified
directory does not exist.
133
MOVETO error: Folder does not exist: <value>
140
COPYTO error: Destination file already exists. Will not overwrite: <value>
SQL Backup failed to copy the file to the directory specified by the COPYTO command. The file already
exists in this directory.
To force the file to be overwritten, specify a FILEOPTIONS parameter that includes the bit-masked value
"4".
141
COPYTO error: Unable to copy <source> to <target>
SQL Backup failed to copy the file to the target directory specified by the COPYTO command.
In most cases, this problem occurs when the startup account for the SQL Backup Agent service does not
have appropriate rights. The startup account must be able to write to the target directory.
142
COPYTO error: Unable to copy <source> to <target>. Error message: <value>
SQL Backup failed to copy the file to the target directory specified by the COPYTO command. Check the
error message for the cause of the failure.
143
COPYTO error: Failed to copy file: <value>
SQL Backup could not process the files to be copied. Check the error message for the cause of the
failure.
145
COPYTO error: Failed to create folder: <value>
146
COPYTO error: Source file does not exist: <value>
147
COPYTO made multiple attempts to copy the file: <value>
SQL Backup made multiple attempts to copy the file specified by the COPYTO command.
The error message shows the number of copy attempts, and the reason why each copy attempt failed.
148
COPYTO error: failed to delete temporary file: <value>
149
COPYTO error: failed to rename temp file <source> to <target>
150
MAILTO error: SMTP host name not defined.
SQL Backup could not send an email notification because the SMTP host name was not defined.
To specify an SMTP host name for this SQL Server instance, use the SQL Backup GUI (Tools > Server
Options > Email Settings).
151
MAILTO error: Failed to send mail.
SQL Backup failed to send an email notification. Check the error message for the cause of the failure.
160
ERASEFILES error: Failed to delete file: <value>
SQL Backup could not delete the file that was marked for deletion.
161
ERASEFILES error: Failed to delete file: <value>. Error code: <value>
SQL Backup could not delete the file that was marked for deletion. Check the error message for the
cause of the failure.
162
Failed to delete log file: <value>. Error code: <value>
The log file records details of backup and restore operations.
SQL Backup could not delete the log file that was marked for deletion. Check the error message for the
cause of the failure.
164
Failed to delete backup entries in msdb tables: <value>
SQL Backup could not delete old backup and restore records from the msdb history tables. Check the
error message for the cause of the failure.
166
Failed to delete old entries in local history tables: <value>
SQL Backup could not delete backup and restore records from the local SQL Server Compact database.
Check the error message for the cause of the failure.
167
Failed to get database size from server.
While calculating the compression ratio for a database, SQL Backup could not retrieve the current
database size from SQL Server. Check the error message for the cause of the failure.
168
Failed to identify filestream files.
While calculating the current database size, SQL Backup could not retrieve the details of files used to
store filestream data. Check the error message for the cause of the failure.
170
Validation error when processing the list of transaction log backups.
SQL Backup could not process the list of transaction log backups required to restore a database. Check
the error message for further details.
If the error message reports that the log files are not in sequence, this may be because the Log
Sequence Numbers cannot be read or are missing from the header file. You can manually restore the log
files, specifying WITH NORECOVERY or WITH STANDBY, using the extended stored procedure.
See Using the extended store procedure and The RESTORE command for more information.
In a log shipping scenario, this error may be due to a large log backup taking a long time to copy to the
network share, allowing later (smaller) log files to be copied to the network share before it, and a restore
of these attempted. This problem should sort itself out over time. You can avoid the problem by
increasing the log restore job interval so that it is at least the transfer time of the largest backup.
175
Another process might be locking this file: <value> (attempt <value>) (<value>)
This is an informational message. The backup file was locked, preventing SQL Backup from updating the
file at the first attempt. SQL Backup succeeded in updating the file after further attempts.
Other applications may be accessing backup files. This may cause errors in the future if those
applications maintain locks on the backup files.
195
Failed to update backup history table (BACKUPMEDIAFAMILY).
SQL Backup could not update details of the backup process in the BACKUPMEDIAFAMILY table in the
msdb database. Check the error message for the cause of the failure.
200
Error creating backup file: <value>
SQL Backup could not create the backup file. Check the error message for the cause of the failure.
202
Multiple attempts were made to create the backup file.
This is an informational message. SQL Backup could not create the backup file at the first attempt, but
succeeded after further attempts.
This indicates potential problems with storing backup files at the specified locations.
204
Multiple attempts were made to restore from the backup file.
210
Error writing to backup file: <value>
This is an informational message. SQL Backup could not write backup data to disk at the first attempt,
but succeeded after further attempts.
This indicates potential problems with storing backup files at the specified locations.
213
Error setting file pointer position: <value>
This is an informational message. SQL Backup could not continue to write backup data to disk following a
previous failure, but succeeded after further attempts.
This indicates potential problems with storing backup files at the specified locations.
215
Error flushing buffer contents to file: <value>
218
Insufficient disk space <value>: required <value>; available <value>
There was insufficient disk space to create the backup file. Before attempting the backup process again,
create more free space on the disk, or back up to a different location.
220
No log files found to be restored.
SQL Backup could not find any relevant transaction log files to restore from the locations you specified.
Check that you have specified the files correctly (including any wild cards in file names).
Also check that the startup account for the SQL Backup Agent service has permission to read the
transaction log files.
225
Files missing from backup history.
One or more of the backup files required for the restore process is missing. Check the error message for
details of the missing files.
226
Files missing from search folder.
One or more of the backup files required for the restore process is missing. Check the error message for
details of the missing files.
280
Failed to open file.
300
Backup failed. Retry attempt: <value>
This is an informational message. SQL Backup could not back up the database at the first attempt, but
succeeded after further attempts.
Check the error message for information about why each attempt failed.
320
Validation failed.
330
Your license does not allow email notification to be performed.
The MAILTO, MAILTO_ONERROR, or MAILTO_ONERRORONLY keyword was specified, but has been
ignored due to licensing restrictions.
SQL Backup failed to send an email notification because you are using SQL Backup Lite edition, or a
read-only licensed edition of SQL Backup. To send email notifications, you must use the Pro edition of
SQL Backup.
Note that from version 6.5, SQL Backup is only available in the Pro edition. SQL Backup Lite has been
retired.
If you are currently using SQL Backup Lite and have not yet been contacted by Red Gate about a free
upgrade, please go to the SQL Backup product page and download it from there. You can use your
existing serial key to license the Pro version.
400
Failed to initialize local data store: <value>
SQL Backup could not initialize the SQL Server Compact database it uses to store details of backup and
restore processes. The SQL Server Compact database is created when the SQL Backup server
components are installed and is used to improve the performance of the GUI.
Check the error message for the cause of the failure.
If the error message reports that access to the database file is not allowed, you need to ensure that the
SQL Backup Agent Service startup account has permissions
402
Failed to open local data store: <value>
SQL Backup could not connect to the SQL Server Compact database it uses to store details of backup
and restore processes.
Check the error message for the cause of the failure.
405
Failed to acquire handle for local data store lock (<value>): <value>
410
Failed to start transaction on local data store: <value>
425
Folder does not exist: <folder name>.
Check that all the log file locations you have specified for your log shipping restore job are available.
If necessary, create the missing directories, or alter your log shipping restore job so that it refers to the
correct directories.
Also, check that the startup account for the SQL Backup Agent service has permission to read the
directories.
435
Get exclusive local data store access failed - timeout.
SQL Backup could not acquire a lock on the SQL Server Compact database it uses to store details of
backup and restore processes. Another process was accessing the database for more than 15 seconds.
The SQL Server Compact database may be too large. Review your backup history deletion policy (Tools
> Server Options > File Management > SQL Server backup history) and consider reducing the amount of
backup history you retain.
436
Get exclusive local data store access failed - abandoned.
SQL Backup could not acquire a lock on the SQL Server Compact database it uses to store details of
backup and restore processes. This was due to a termination request.
This usually happens because the SQL Backup Agent service is in the process of shutting down.
438
Get exclusive local data store access failed - invalid lock handle.
SQL Backup could not acquire a lock on the SQL Server Compact database it uses to store details of
backup and restore processes. This was probably caused by an internal error.
Try restarting the SQL Backup Agent service.
440
Invalid DB handle.
SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup
and restore processes. The database was not available.
Try restarting the SQL Backup Agent service.
442
Get exclusive local data store access failed - invalid lock handle.
SQL Backup could not release a lock on the SQL Server Compact database it uses to store details of
backup and restore processes. This was probably caused by an internal error.
Try restarting the SQL Backup Agent service.
445
Local data store error: <value>
SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup
and restore processes.
Check the error message for the cause of the failure.
450
Local data store SQL error: <value>
SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup
and restore processes. There was an error preparing the SQL command used to write the data.
Check the error message for the cause of the failure.
460
Encryption key size is specified, but password is empty.
The KEYSIZE keyword has been specified, but the PASSWORD keyword has not been specified, or it is
specified with a zero-length password.
462
Short passwords may not be secure.
The KEYSIZE keyword has been specified, but the supplied PASSWORD is seven characters or fewer.
470
Transaction log has already been restored.
This is an informational message. One or more transaction log backup files has already been restored,
and will not be restored again.
This may indicate that the MOVETO option is not moving restored transaction log files to the specified
directory.
Alternatively, another process may be copying old transaction log backup files to the directory SQL
Backup is using for newly created transaction log backup files.
471
Failed to run sp_change_users_login report while checking for orphaned users.
You used the ORPHAN_CHECK option, but SQL Backup could not run the sp_change_users_login
stored procedure.
Check the error message for the cause of the failure.
472
Orphaned users have been detected during a RESTORE operation. Check the log file for the list of
orphaned users and associated SIDs.
474
A full database backup was performed for the database <database name>.
This warning arises if WITH FULLIFREQUIRED is included in the BACKUP DATABASES or BACKUP
LOGS command and a full backup is taken. For more information, see The BACKUP command.
480
Failed to create output folder: <value>
481
The file name (<file name>) contains an invalid character (<invalid character>).
This warning arises if the <DATABASE> tag is used, either directly or via the <AUTO> tag, to generate a
backup file name from the database name, and the database name includes an invalid character. If no
backups are created, error code 505 is also returned.
For information on using tags to generate file names, see File location tags. For information on the
<AUTO> tag see File management options.
483
The FULLIFREQUIRED option is not available when taking differential|transaction log backups on SQL
Server 2005|2000. SQL Backup was unable to create any full database backups that may be required to
restore a differential|transaction log backup.
This warning arises when using WITH FULLIFREQUIRED to:
- take differential backups on SQL Server 2005, or
- take transaction log backups on SQL Server 2000 or 2005
and SQL Server has not returned SQL error 3035 or 4214 (current database backup does not exist).
In these cases, SQL Backup is unable to identify whether any full database backups should be taken
before taking differential or transaction log backups. The differential or transaction log backups are
created, but may not be usable.
For more information about the FULLIFREQUIRED option, see The BACKUP command.
485
File does not exist: <Filename .sqb>
This warning may arise during a restore operation. The Restore process will perform a check on the file
to enure it is accessible before the restore begins. If there is a temporary network interruption or a delay
in the initial response being received, this warning will occur, but the second attempt to check the file will
succeed. The warning can be ignored in these circumstances.
SQL Backup error codes
The following error codes may be returned by SQL Backup.
Error Description
code
500
General SQL Backup error.
505
No valid SQL Backup file name entered.
Check that the length of the path name does not exceed the number of characters for your operating system.
If you are generating a backup file name using the <DATABASE> or <AUTO> tags, check that the database
name does not contain invalid characters. See File location tags for more information.
If you are backing up directly to a network share (not recommended), ensure the network share already exists,
and that the startup user for the SQL Backup Agent Service has full permissions for the network share
(seeBacking up and restoring on a network share).
To check the SQL Backup Agent Service permissions, run the following command:
execute master..sqbutility 999, 'RWE', '\\testsrv\backup'
If the agent has read (R), write (W), and execute (E) permissions, the command returns 1; 0 indicates failure.
506
No valid backup sets found from backup history.
507
No valid backup sets found from provided folder(s).
508
No valid full backup sets found from provided folder(s) for latest differential backup.
510
Backup file exists. Will not overwrite. File name: <value>
Try specifying a file name format that does not result in identical file names. See File location tags and The
BACKUP command.
To overwrite existing backup files, use the INIT argument.
512
Backup file name (<value>) contains an invalid character (<value>)
515
Multi database backup file names must contain the <AUTO>, <DATABASE> or <DATETIME> tags.
If you are backing up multiple databases, the backup file names must be unique. Use the <AUTO>,
<DATABASE>, or <DATETIME> tags to achieve this. See File location tags and The BACKUP command.
516
Multi database operations cannot use MIRRORFILE option.
If you are backing up multiple databases, you cannot use the MIRRORFILE argument. See The BACKUP
command.
517
Cannot use MAXDATABLOCK parameter with local files.
518
File name exceeds limit of 259 characters: <value>
519
Multi-database undo file names must contain the <DATABASE> tag.
If you are backing up logs for multiple databases and have specified the STANDBY keyword, the undo file
names must be unique. You must use the <DATABASE> tag to do this. You can use other tags too, but the
<DATABASE> tag must be present.
See The BACKUP command and Syntax examples.
520
Output file exists. Will not overwrite. File name: <value>
When you use the CONVERT command, you must specify a unique file name for the destination file.
525
Folder does not exist. Folder name: <value>
526
Cannot find saved setting.
Check that the SQL Backup Agent Service startup user has read access to the following registry key and its
values: HKEY_LOCAL_MACHINE\Software\Red Gate\SQL Backup\BackupSettings
527
None of the specified folders exist.
Check the transaction log folder locations you have specified for this log shipping restore job.
530
Non-existent backup file.
Check the path of the backup file.
If you are restoring from a backup file on a network share, ensure the startup user for the SQL Backup Agent
Service has permissions for the network share.
540
No file name entered for the Microsoft Tape Format (MTF) file.
When you use the CONVERT command, you must specify the path for the SQL Backup files (.sqb) and the
path for the MTF file. See The CONVERT command and Syntax examples.
550
Cannot have the same file names for the SQL Backup file and the converted file.
560
File does not exist: <value>
Check the path of the backup file in the RESTORE SQBHEADERONLY command.
If the backup file is on a network share, ensure the startup user for the SQL Backup Agent Service has
permissions for the network share.
562
Object is a folder, not a file: <value>
564
Error reading file.
566
Error reading files not in SQB path.
570
File is not a SQL Backup file.
Check the file you are restoring from is not a log file or native backup file.
580
Failed to open file. Message: <value>
The file may be in use or there may be a permissions problem; ensure the startup user for the SQL Backup
Agent Service application has been granted the necessary permissions. See Security Model.
581
Failed to disconnect existing connections to database.
584
System databases must be restored with full recovery using the RECOVERY option.
585
Cannot use multiple file names with the THREADCOUNT option.
586
Failed to connect to SQL Server instance: <value>
587
Backup and restore operations are not allowed on database tempdb.
588
You can only perform a full backup of the master database.
Use BACKUP DATABASE to back up the entire master database.
589
Cannot back up the log of the master database.
Use BACKUP DATABASE to back up the entire master database.
590
Insufficient space to perform process. Space required: <value>
591
Cannot disconnect existing users from the model database.
592
The REPLACE option must be used when using the DISCONNECT_EXISTING option on an active database.
595
Failed to create MTF file: <value>
Ensure the startup user for the SQL Backup Agent Service application has been granted the necessary
permissions. See Security Model.
596
File is a native SQL Server backup file.
597
Failed to read MTF header data.
600
Multiple log file validation error for restore.
605
Error creating backup file(s). No files could be created.
Ensure the startup user for the SQL Backup Agent Service application has been granted the necessary
permissions. See Security Model.
610
Error creating file handle for file: <value>
Ensure the startup user for the SQL Backup Agent Service application has been granted the necessary
permissions. See Security Model.
612
Error reading file: unexpected end-of-file reached.
613
Compressed data block not found in file.
620
Error writing to backup file(s).
621
Error writing to backup file(s) due to insufficient disk space.
622
Error flushing contents of backup file(s).
623
Error setting file pointer position for backup file(s).
624
Error writing header (LSN data) to backup file (<value>): <value>.
625
Error writing header (backup size) to backup file (<value>): <value>.
627
Failed to set file pointer to beginning of file (<value>) to write backup size: <value>.
628
Failed to set file pointer to beginning of file (<value>) to read header data: <value>.
629
Failed to set file pointer to beginning of file (<value>) to write LSN data: <value>.
630
Cannot run a multi device backup with the MIRRORFILE option.
If you are backing up to multiple devices, you cannot use the MIRRORFILE argument. See The BACKUP
command.
632
Failed to set file pointer to current position of file.
636
BACKUP WITH CONTINUE_AFTER_ERROR successfully generated a backup of the damaged database.
637
RESTORE WITH CONTINUE_AFTER_ERROR was successful but some damage was encountered.
638
The backup was written with damaged data by a BACKUP WITH CONTINUE_AFTER_ERROR.
640
Cannot specify more than 32 devices.
You can specify up to 32 devices in a backup or restore operation. See The BACKUP command and The
RESTORE command.
660
VDI library not registered.
This may be because the VDI library has become unregistered when other SQL Server components have
been uninstalled. To register this library manually, first locate the sqlvdi.dll file (for 64-bit versions of SQL
Server, you need to locate the 32-bit version of the file). You can then use the regsvr32 command, for
example:
regsvr32 sqlvdi.dll
If you are using more than one version of SQL Server, locate the latest copy of the sqlvdi.dll file; later versions
of this file are compatible with earlier versions of SQL Server.
662
The version of the VDI library used does not match the version of SQL Server. Please install the correct
version of sqlvdi.dll on this server.
For example, this may occur if you have reinstalled SQL Server 2000, and you are attempting to back up a
SQL Server 2005 database.
665
Beta trial period has expired.
667
Trial period has expired.
Contact licensing@red-gate.com and tell us you are evaluating SQL Backup.
668
64-bit servers require Professional license.
Please contact sales@red-gate.com for more information.
680
The media set for database '<value>' has <value> family members but only <value> are provided. All
members must be provided.
The backup set that you are trying to restore is split across multiple files; the number of files you have
specified does not match the number of files in the backup set.
If this error occurs when restoring transaction log backups, it may be because SQL Backup cannot put the
files in the correct order because it cannot read the Log Sequence Numbers from the header files or the
information is not there. You can restore these files one at a time in date order, specifying either WITH
NORECOVERY or WITH STANDBY, using the extended stored procedure. This will negate the need for the
SQL Backup header. See also SQL Backup warning code 170.
Alternatively, the SQBHeaderFix utility can be used to repair the files by recreating the SQL Backup header
using information from the native SQL header. You can download the utility from: ftp://support.redgate.com/Patches/SQL_Backup/SQBHeaderFix.zip
700
No process type entered.
705
When using the FULLIFREQUIRED option, the backup file name(s) must contain the dynamic tags,
<DATABASE> and <TYPE>.
If you are using the FULLIFREQUIRED argument, the backup file name must include the <DATABASE> and
<TYPE> tags. The <AUTO> tag may be used if the file name format includes the <DATABASE> and <TYPE>
tags. See File locations tags and The BACKUP command.
710
Wrong password entered.
The RESTORE command contains an incorrect password, or if you are restoring from an encrypted backup
file, the PASSWORD argument is missing.
715
Backup file is not encrypted.
You do not need to specify the PASSWORD argument in the RESTORE command.
716
None of the backup files are encrypted.
You do not need to specify the PASSWORD argument in the RESTORE LOG command.
720
No database name entered.
740
Failed to get LSN data from server.
742
Failed to get LSN data from server (0 rows returned).
743
Failed to get file position value from server.
760
LSN data from server is blank.
765
Failed to read file header (<value>): <value>. Read <value> bytes.
775
Failed to open file to write LSN data. Another process might be locking this file: <value>
SQL Backup writes a header block to each backup file upon completion of the backup. In some cases,
antivirus applications may lock the backup file immediately after creation, denying SQL Backup access.
780
General conversion error.
782
Browse via SQL: registry value not set.
784
Browse via SQL: not sysadmin.
790
General thread error or SQL Server error.
Refer to your SQL Server documentation.
800
File requires SQL Backup version <value> or higher to restore. Current version is <value>.
810
Error retrieving SQL Server login name: <value>
Check that the SQL Backup Agent Service startup user has read access to the following registry key and its
values: HKEY_LOCAL_MACHINE\Software\Red Gate\SQL Backup\BackupSettings.
820
Validation of all backup files failed.
821
DBCC CHECKDB: Database integrity check completed with errors.
822
Encrypted files require a password to be successfully restored.
825
To run database consistency checks, the database must be restored using the STANDBY or RECOVERY
options. To recover the database after all checks have completed, include the RECOVERY parameter in the
VERIFY option.
826
To run database consistency checks where multiple backup sets may be restored, the database must be
restored using the STANDBY option. To recover the database after all checks have completed, include the
RECOVERY parameter in the VERIFY option.
828
Failed to recover database.
829
Failed to drop database.
830
Cannot disconnect existing users when the log is not backed up with the NORECOVERY or STANDBY
options.
840
File validation failed.
850
SQL Backup syntax error.
870
No command passed to SQL Backup.
The command is empty.
880
BACKUP DATABASE permission denied in database: <value>
Check that you have backup rights to the relevant database.
Check that the login account for the SQL Backup Agent Service is a Windows Authenticated account with
sysadmin privileges on the SQL Server. For more information see Security Model.
If the error persists, turn off the user rights checks by creating a registry key called SkipChecks:
Locate HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\BackupSettingsGlobal\(local) or
<instance name>
Create a new DWORD type registry key called SkipChecks and set the data value to 1.
Stop and restart the SQL Backup Agent Service.
To reinstate user rights checks, set the data value to 0 or delete the key.
890
RESTORE DATABASE permission denied for database: <value>
Check that you have the appropriate restore rights.
900
Failed to read backup file header (0 rows).
910
Failed to read file list details (0 rows).
915
Failed to update backup history table (BACKUPSET).
916
Failed to update restore history table (RESTOREHISTORY).
917
Failed to update backup history table (BACKUPSET). Media set ID is blank.
918
Failed to retrieve restore history id.
920
Failed to update backup history table (BACKUPMEDIAFAMILY).
930
File read error for compressed data. Backup file is incomplete or corrupted (FileBufferRemainingBytes:
<value>)
932
File read error for compressed data size. Backup file is incomplete or corrupted (CompressedDataSize:
<value>)
934
File read error for device index. Backup file is incomplete or corrupted (FileBufferRemainingBytes: <value>)
940
File read error for <value> bytes (balance <value> bytes). Backup file is incomplete or corrupted.
942
File read error for <value> padding bytes (balance <value> bytes). Backup file is incomplete.
950
Data decompression error: <value>
960
Failed to service command. Error code: <value>
970
Backup file does not exist. File name: <value> (for restores).
985
Error creating critical section: <value>.
990
Invalid number of virtual devices: <value>
995
Error creating event for virtual device: <value>
1000* Failed to create virtual device. Error code: <value>
If the secondary error code is -2139684857, ensure that the SQL Backup Agent Service startup user has read
access to the SQL Server service. You can do this using the sc sdset and sc sdshow commands, for example:
sc \\ServerName sdshow "sqlbackupagent"
For information about how to interpret the results, refer to your Windows® documentation.
1010* Failed to get configuration from server. Check that the SQL Server instance is running and that you have the
SQL Server System Administrator server role. Error code: <value>. [Also check that the database is not
currently in use.]
For certain timeout conditions, a more detailed description may be presented with this error code:
Failed to get the configuration from the server because the timeout interval has elapsed. Check that the SQL
Server instance is running, that you have the SQL Server System Administrator server role, and that no other
processes are blocking the backup or restore process. If the problem recurs, try increasing the value of the
VDITimeout registry setting in HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL
Backup\BackupSettingsGlobal\[InstanceName].
or,
Failed to get the configuration from the server because the timeout interval has elapsed. SQL Backup required
<bytes> bytes of free SQL Server memory, which was not available. You can reduce the memory
requirements by reducing the number of backup files/threads used in the backup.
To configure the VDITimeout registry key, open the registry editor, locate the SQL Backup entries for the
relevant SQL Server instance, and add a DWORD entry named "VDITimeout". Enter a duration that you feel is
adequate for SQL Server to respond. The duration must be entered in seconds (in hexadecimal).
For more information, see this knowledge base article.
1020* Failed to open virtual device. Error code: <value>
1030* Failed to create VirtualDeviceSet component. Error code: <value>
SQL Backup uses the SQL Virtual Device Interface library to perform backups and restores. This library is
contained in a file named sqlvdi.dll and is installed and registered when you install SQL Server. This error may
arise when backing up and restoring databases for two reasons:
1. The sqlvdi.dll file is missing or has been unregistered, or an incorrect version of SQL Server has been
installed. Check the version of the sqlvdi.dll file installed on your SQL Server.
Open Registry Editor and open HKEY_CLASSES_ROOT (32-bit edition of Windows) or
HKEY_CLASSES_ROOT\Wow6432Node\CLSID (64-bit editition of Windows). Locate the key {407004250080-11d2-851f-00c04fc21759}. The key's value InprocServer32 contains the path to sqlvdi.dll. Ensure
that the file exists and that the SQL Server startup account has access to it.
A 64-bit edition of SQL Server will have two copies of sqlvdi.dll, one for 32-bit installations and one for 64-bit
installations. Because SQL Backup is a 32-bit application, the 32-bit VDI will be used by SQL Backup while
SQL Server will use the 64-bit version. Therefore, it is important that the two copies of sqlvdi.dll are the same
version. Using the file locations indicated by the InprocServer32 key, examine the properties on both
sqlvdi.dll files to ensure the version numbers match.
2. A problem with permissions. The SQL Backup Agent Service startup account must be a member of the
SQL Server sysadmin role in order to access VDI libraries. See Security Model for more information.
1040* Process terminated unexpectedly.
1050 Failed to close VDI.
1100 SQL Server error.
Refer to your SQL Server documentation.
2010 Command exceeds permitted length.
5000 General inter-process communication (IPC) error.
5100 Error creating SQB service event: <value>
5102 Error creating SQB service event (already exists): <value>
5110 Error opening SQB service event: <value>
5120 Error setting SQB service event: <value>
5130 Error creating client event: <value>
5140 Error creating mutex: <value>
5142 Error creating mutex (already exists): <value>
5145 Failed to start SQL Backup Agent service.
5146 Inadequate rights to start SQL Backup Agent service. Please start the SQL Backup Agent service manually.
5148 SQL Backup cluster resource is stopped.
The SQL Backup Agent Service is stopped on the active node in the cluster. This may be because a failover is
in progress (in which case the service should restart automatically within a few minutes), or because the
service has failed, or has been deliberately stopped.
You can re-enable the service with the Windows Cluster Administrator tool (Windows Server 2003) or Failover
Cluster Management tool (Windows Server 2008).
5150 Error opening mutex: <value>
5160 Error acquiring mutex: <value>
A mutex is a communication channel between SQL Backup and the SQL Server processes. In certain
circumstances a mutex can become orphaned. When SQL Backup attempts to create a new mutex, the
request will be rejected by Windows because a mutex of the same name already exists.
Rebooting the operating system should resolve this problem. Alternatively, use Process Explorer to identify
the process which is causing the problem:
Download Process Explorer from http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx and run it.
On the Find menu click Find Handle or DLL to open the Process Explorer Search dialog box.
Type SQBMutex into the Handle or DLL substring box and click Search.
For a SQL Server instance that is functioning correctly, the
handles \BaseNamedObjects\SQBMutex_ and\BaseNamedObjects\SQBMutex_data_ will exist as part of the
process SQBCoreService.exe (the SQL Backup Agent). For instances other than the default, the instance
name will be appended to the handle (e.g.\BaseNamedObjects\SQBMutex_SQL2005).
Select the problematic instance from the list to highlight the entry in the Process Explorer main window.
Right click this entry and select Close Handle. repeat this for the corresponding data handle.
You should now be able to start the SQL Backup Agent and connect to the server.
15.
What are the major causes of tape backup failures?
There are a wide variety of reasons why data backup or recovery operations fail. Backup and
restore operations may fail due to people, hardware, software or media errors. There are
essentially six major causes of backup and restore failures:
1. Human errors
2. Software errors (device busy, in use or other error conditions that may be recoverable)
3. Resource contention (resources needed for backup in use such as an open application or file
data, I/O channels, or tape library, drive or media)
4. SAN or other connectivity problems
5. Tape drive or media error
6. Hardware errors (disk drives, processors, memory, I/O controllers, etc.)
The most common cause of backup and recovery problems are those caused by human errors.
Examples include running multiple jobs simultaneously, failure to change tapes, forgetting to
remove a cleaning tape or any one of a number of issues.
Next on the list are software errors, typically with scripts used to run backup operations, mount
media or other operations. Resource contention can occur due to unforeseen or unpredictable
events, or because of a lack of planning on the part of backup operators. Connectivity problems
may occur due to SAN zone changes or other issues effecting connectivity. Finally, hardwarerelated items are the least likely to cause problems, which include tape media, tape drives and
other hardware involved.
The perception portrayed by some vendors is that tape media is one of the most common causes
of backup problems. The reality is that tape drive and media issues are typically not the major
cause of failures. However, tape media failures do occur and can have a significant impact; in
some cases tape media errors aren't recoverable.
Applications and tape drives may be unable to recover from media errors, even though the actual
data loss is a small percentage of the tape. Thus, even small dropouts may result in loss of access
to a large amount of data on tape. Moving from tape- to disk-based backups can improve
reliability and eliminate this data loss. However, the other more common problems remain,
regardless of whether backups are going to disk or tape.
Addressing the causes of backup failures is prudent. But the issues should be addressed in the
order of frequency. Because human errors are the most likely cause for problems, automating
backup processes can reduce a large amount of errors. Ensuring well-proven software and scripts
are used to run backup operations is the next issue to address. Configuration management can
help ensure that resource contention and connectivity issues don't lead to data backup problems.
Only after the primary causes of backup have been solved does it make sense to address tape
media problems for backups.
IV.
LITERATURE SUMMARY
AUTHOR COMMENTS:
According to Rick Cook, Article Published: 27 Jul 2006 “Backup
failure: Five reasons backups fail and tips for
prevention”.
Backups are central to any data protection strategy, but by some estimates more than half of all
backups fail either in whole or in part. When you look at the reasons for why they are failing, the
same issues come up again and again. Below is a list of the common problems that cause backup
failure, in decreasing order of frequency.
1. Media failure
Media failure ranks at the top of nearly every list of reasons backups and restores fail. For
this reason, it's important to treat your backup media with respect and use it intelligently.
In the case of tape, this means making sure you follow the vendor's directions for handling
and storage, replacing the tapes regularly and cleaning the drives according to the
manufacturer's schedule. It also means discarding any suspicious tapes.
Don't assume disk-based backup protects you from media-related failures. While the
incidence of media-related failures is considerably lower with disk than tape, failures still
occur.
For example, SATA disk arrays are often used in backups because they cost less and backups
can usually get by with lower performance systems. However, it's a mistake to equate "lower
performance" with "lower reliability." Saving money by using backup arrays that don't have
features like redundant power supplies and hot spare disks leaves data at risk.
2. Human error
In spite of its No. 2 ranking, human error is probably the most prolific cause of backup
failures. For example, if tapes are improperly stored between uses, is the resulting failure a
media failure or a human error? Usually there's a significant component of human error in
any backup failure.
The best safeguard against human error in backups is to train those involved to follow best
practices. Make sure that the people performing backups and restores understand exactly
what they need to do -- and what not to do.
It is also a good idea to take the person out of the loop as much as possible. Ideally, backups
should not require any human action. Be especially cautious of situations where backup isn't
part of someone's main duties -- for instance, someone in a branch office who's been asked to
make a backup tape every night.
3. Software failure
Sometimes new software or new versions of software can cause backup failures. For
example, Service Pack 2 (SP2) for Windows XP turns on the firewall by default. When
Microsoft released SP2, a lot of network backups failed because the backup software wasn't
designed to work through a firewall.
More commonly, the problem is misconfiguration. Modern backup software is extremely
flexible; in other words, you have a lot of options to choose from and choosing the wrong
options can result in incomplete backups or backups that fail totally.
A related problem is that backup configurations are no more static than anything else in a
modern storage environment. As resources are added and shifted and priorities change, the
list of files to be backed up needs to change as well.
4. Hardware failure
Tape drives, libraries, disk arrays and other backup hardware can also fail. Most of the
causes and failure conditions for backup hardware are the same as for other kinds of
hardware, but there are a few conditions that are specific to backup systems.
For example, drift produces a particularly nasty kind of failure in tape drives. As the drive
ages, the heads slowly wander out of alignment. As a result, other drives can't read the tape -and the drive can't read a tape it wrote some time ago. The nasty part of this is that the drive
can almost always read a tape it just wrote, so the tape passes an immediate verification step
in the backup process without complaint.
5. Network failure
Backing up over a network increases efficiency by reducing the number of backup devices.
However, it also introduces another point of failure into the backup process. Everything from
a failed or flaky HBA to a misconfigured switch can cause a backup to fail.
This is a less prolific source of backup failures because the network, LAN or SAN, is used
for much more than just backup, so problems will tend to become obvious before they can
hurt your backups.
6. How to fix backup failures
Whatever the cause of failure, the best way to keep them from damaging your organization is
to verify your backups by performing regular test restores. Testing your backups regularly
won't prevent backup failures, but they can help in noticing the issue and this will allow you
to fix the problem before you really need those backups and you get a nasty surprise.
According to Robert Richardson, Encryption can be used to protect data "at rest", such as files
on computers and storage devices (e.g. USB flash drives). In recent years there have been
numerous reports of confidential data such as customers' personal records being exposed through
loss or theft of laptops or backup drives. Encrypting such files at rest helps protect them should
physical security measures fail. Digital rights management systems which prevent unauthorized
use or reproduction of copyrighted material and protect software against reverse engineering (see
also copy protection) is another somewhat different example of using encryption on data at
rest.[citation needed]
Encryption is also used to protect data in transit, for example data being transferred
via networks (e.g. the Internet, e-commerce), mobile telephones, wireless microphones,wireless
intercom systems, Bluetooth devices and bank automatic teller machines. There have been
numerous reports of data in transit being intercepted in recent years.[4]Encrypting data in transit
also helps to secure it as it is often difficult to physically secure all access to networks. [citation
needed]
Encryption, by itself, can protect the confidentiality of messages, but other techniques are still
needed to protect the integrity and authenticity of a message; for example, verification of
a message authentication code (MAC) or a digital signature. Standards and cryptographic
software and hardware to perform encryption are widely available, but successfully using
encryption to ensure security may be a challenging problem. A single slip-up in system design or
execution can allow successful attacks. Sometimes an adversary can obtain unencrypted
information without directly undoing the encryption. See, e.g., traffic analysis, TEMPEST,
or Trojan horse.[citation needed]
One of the earliest public key encryption applications was called Pretty Good Privacy (PGP). It
was written in 1991 by Phil Zimmermann and was purchased by Symantec in 2010.[5]
Digital signature and encryption must be applied at message creation time (i.e. on the same
device it has been composed) to avoid tampering. Otherwise any node between the sender and
the encryption agent could potentially tamper it. It should be noted that encrypting at the time of
creation only adds security if the encryption device itself has not been tampered with.
William McMullen wrote:
Re: RESTORE FROM BACKUP does NOT restore everything. WHY APPLE?
Mar 1, 2013 5:49 AM (in response to William McMullen)
Biggest issue for me here is that Apple has changed the behavior of the "back-up."
It used to behave like this:
IF you backed up your phone to iTunes via a cable, it would take a while, create a bit-by-bit
back up of your phone, and then finish. At this point, if you lost your phone, threw your phone
in a lake, or your phone was stolen, you could go get another iPhone and connect it, restore it,
and violá, your phone was magically exactly like it was before whatever mishap befell your
original phone.
V.
IMPLEMENTATION
This step allows you to configure the frequency at which a synthetic full backup of the selected
database has to be done. A synthetic full backup is a complete full [backup] dump of the selected
databases and all necessary log files but only the changed data with respect to the previous full
backup /synthetic full backup [whichever is recent] is uploaded to the backup server. Once
synthetic full backup completes, all log files older than the time when synthetic full backup
started would be purged. Since a synthetic full backup takes lesser time to complete than the full
backup, it is typically configured to run weekly or monthly or much frequently than full backup
[and less frequently than incremental/differential log backup]. Configuring a synthetic full
backup scheduling is optional.
This step has the following options from which any one can be chosen.
Run Monthly At - Choose the time and day of the month the backup should run. StoreGrid will
run the backup every month on the particular day and time chosen. StoreGrid will run at the
stipulated time/day only.
Run Weekly - Choose the time and the day of the week the backup should run. StoreGrid will
execute the backup every week on the particular day and time chosen. Note that you can select
multiple days of the week if you wish to run the backup on multiple days of the week. StoreGrid
will run at the stipulated time/day only.
Log Backup Scheduling (Optional Step)
Exchange Server Plugin users will have a drop-down box to optionally choose between
Incremental/Differential Log Backups. StoreGrid will do a Incremental/Differential log backup
dump of the database with respect to the previous full or synthetic full or incremental log backup
whenever this Incremental/Differential log backup is scheduled.
Incremental Log Backup : An incremental log backup backs up only the log files since the last
full or synthetic full or incremental backup. Once an incremental backup completes, all log files
older than the time when incremental backup started would be purged. You cannot perform an
incremental backup when circular logging is enabled in your exchange server settings. Since
only changes are backed up, incremental backups typically run faster than full and synthetic full
backups. Also, as only the log files since the last backup are backed up, incremental backups will
run faster than differential backups too. Hence incremental backups are always configured to be
scheduled more frequently than a full and synthetic full backup. Configuring incremental backup
scheduling is optional.
Differential Log Backup : A differential backup backs up only the log files since the last full
backup or synthetic full backup even when the last backup was a incremental backup. The logs
are not deleted after the differential backup completes. You cannot perform a differential backup
when circular logging is enabled in your exchange server settings. Since only changes are backed
up, differential log backups typically run faster than full and synthetic full backups. But, as all
the log files since the last full backup or synthetic full backup are backed up, differential backups
will take longer to finish than an incremental backup. Hence differential backups are configured
to be scheduled more frequently than a full and synthetic full backup. Configuring differential
backup scheduling is optional.
This step has the following options from which any one can be chosen.
Run Weekly - Choose the time and the day of the week the backup should run. StoreGrid will
execute the backup every week on the particular day and time chosen. Note that you can select
multiple days of the week if you wish to run the backup on multiple days of the week. StoreGrid
will run at the stipulated time/day only.
Run Daily - Choose the time at which the backup should run daily. This will execute the backup
everyday at the time you have provided. StoreGrid will run at the stipulated time only.
Run Every Few Hours - Choose the hours/minutes interval between each time StoreGrid must
run. If StoreGrid is restarted in the interim, the backup will run once StoreGrid starts.
Thereafter, StoreGrid automatically reschedules the next backup after the period you’ve set. For
example, if you created a backup schedule at 10 am and set it to run every 1 hour, StoreGrid will
first run the schedule at 10am and the next scheduled time will be 11am. However, if at
10.15am, StoreGrid is restarted, then the schedule will run once at 10.15am and the next
scheduled time will now be set to 11.15am. Additionally, you can also select the days in which
this schedule should run. For example, if you do not want to run this backup schedule on
Saturdays and Sundays, uncheck the checkbox against these days.

Advanced Settings (Optional)
If you want to configure some additional advanced options - like, CPU utilization, Compression
settings, etc. click on the Advanced Options button.
Advanced Backup Schedule Settings
There are some options here on how the backup should be scheduled.
Maximum Number Of Full Backups : You can specify the maximum number of full backups that
need to be stored in the server. For example if you configured a monthly full backup,
thenStoreGrid will take a full backup every month. After 6 months you will have 6 separate full
backups in the backup server along with differential or incremental logs under each of the 6 full
backups. If your policy is to retain only backup data for 6 months, then you can configure "Store
maximum of 6 full backups" here. On the 7th month, StoreGrid, after finishing the 7th full
backup, will delete the first full backup along with its differential or incremental log backups
thus retaining the last 6 months (full) backups.
Run this backup immediately after saving this configuration (thereafter, Backups will be
scheduled as per the schedule stipulated) : If you enable this option, then this backup schedule
will be executed once immediately after you save this backup schedule – even if its not yet ‘time’
as per the schedule. For example if you configure a daily backup at 10.00 AM but you
configured the backup at 8.00 AM, then the backup schedule will be run once immediately (8.00
AM) and then as per schedule (eg. daily at 10.00 AM).
Attempt to run this backup every 5 minutes in case of non completion because of a problem
(Network error etc.) : If enabled, the user can choose to reschedule this backup every
5/10/15/20/25/30 minutes, whenever an attempted backup is incomplete because of a network
error, server crash etc. The number of times the backup will be rescheduled (due to an error) can
be configured to be in between 1-5 or unlimited, with the default setting as 5. This is to ensure
that an incomplete backup is completed as soon as possible without waiting for the next actual
schedule time. Note that this option is enabled by default.
Data Integrity Check : StoreGrid supports data integrity check where the data sent from the client
machine is verified for integrity at the backup server. When a file's integrity check
fails,StoreGrid flags that file as skipped and the file is then again backed up during the next
backup schedule.
Other Backup Settings
Set CPU Utilization
For each backup schedule, you can also specify the CPU utilization level as Low, Medium or
High. When you set the CPU Utilization to high, the backup will be really fast - but the backup
process may affect the speed of other active applications. If CPU utilization is set to Low, the
backup will take longer but will be done in a non-intrusive manner allowing you to comfortably
work on the computer as the backup continues in the background. In general for a continuous
backup, it is best to set the CPU utilization to Medium or Low. For backups which are done
every day or every week in ‘off-hours’, the CPU utilization can be set to High. Actual
performance is obviously a function of your individual machine and your network. We
encourage you to experiment with different settings to figure what works best for you.
Set Compression
If compression is enabled, data will be compressed in the client before it is uploaded into the
backup server.
Enable - Compresses the data before backing it up. It might reduce the rate at which the client
can send data to the backup server but it might save significant bandwidth and time when the
data is backed up to a remote server over a WAN/Internet with limited bandwidth speed. Also,
this saves disk space in the backup server.
No Compression - This option is suitable (fastest) for backing up data within a local network
where bandwidth is not the limitation, but occupies more space on destination machine as no
compression is being done.
Saving the configured backup
Once all the Exchange Server Storage Group(s)/Database(s) to be backed up are chosen and the
configuration options are set, you simply need to click on the "Configure/Save Backup” button to
activate the backup as per the schedule- on to the configured backup servers.
VI.
CONCLUSION
AND
FUTURE
ENHANCEMENT
Because of a considerable overlap in technology, backups and backup systems are frequently
confused with archives and fault-tolerant systems. Backups differ from archives: archives are
the primary copy of historical data, usually retained for the long term, while backups are
a secondary copy of current data, kept on hand to replace the primary copy of that data. Backup
systems differ from fault-tolerant systems in the sense that backup systems assume that a
fault will cause a data loss event and fault-tolerant systems assure a fault will not.

The more important the data, the greater the need to back it up.

Backups are dependant on the restore strategy, which should be tested.

Storing the copy near the original is unwise, since many disasters such as fire, flood, theft,
and electrical surges may affect the backup at the same time, in which case both the original
and the backup medium would be lost.

Automated backup and scheduling should be considered, as manual backups can be affected
by human error.

Incremental backups should be considered to save the amount of storage space and to avoid
redundancy.

Backups can fail for a wide variety of reasons. A verification or monitoring strategy is an
important part of a successful backup plan.

Multiple backups on different media, stored in different locations, should be used for all
critical information.

Backed up archives should be stored in open and standard formats, especially when the goal
is long-term archiving. Recovery software and processes may have changed, and software
may not be available to restore data saved in proprietary formats.

System administrators and other IT professionals are often dismissed for failing to devise and
implement backup processes suitable to their organization.
VII.
[1]
REFERENCES
www.simple-talk.com/sql/database-administration/sql-server-backup, 25 September
2013
[2]
http://technet.microsoft.com/en-us/library/aa225964(v=SQL.80).aspx, 25 September
2013
[3] http://www.internetworldstats.com/stats.htm, 23 August 2013 http://www.cpd.iit.edu, “Security and
Control Issues within Relational Databases” David C. Ogbolumani, CISA, CISSP, CIA, CISM, 27 September
2013
[4}
C.J. Date. “An Introduction to Database Systems”, Volume I. Fifth edition, Addison-Wesley,
1990., 27 September 2013
[5]
H.F. Korth and A. Silberschatz. “Database System Concepts”. Second edition, McGraw-Hill,
1991., 27 September 2013
[6]
M. Gasser.” Building a Secure Computer System”. Van Nostrand Reinhold, 1988., 28 September
2013
[7]
C. Peeger. “Security in Computing”. Prentice-Hall, 1989., 28 September 2013
[8}
http://www.ontrackdatarecovery.ie/common-tape-problems/ 29 September 2013
[9]
https://discussions.apple.com/thread/, 29 September 2013
[10]
Robert Richardson, 2008 CSI Computer Crime and Security Survey at 19.i.cmpnet.com