newsqlpupougroup.weebly.comnewsqlpupougroup.weebly.com/.../database_issues._ba… · Web viewPOLYTECHNIC UNIVERSITY OF THE PHILIPPINES. OPEN UNIVERSITY SYSTEM . MIT 620 ADVANCE

POLYTECHNIC UNIVERSITY OF THE PHILIPPINESOPEN 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 off-

site 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.

INIT NOINIT

SKIP If the volume contains a valid1 media

header, verify the media password

and 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.

If the volume contains a valid

media header, verify the media

password and append the backup

set, preserving all existing backup

sets.

If the volume does not contain a

valid media header, an error occurs.

NOSKIP If the volume contains a valid media

header, perform the following

checks:

Verify the media password.2

If MEDIANAME was

specified, verify that the given

media name matches the

media header's media name.

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

If the volume contains a valid

media header, verify the media

password* and verify that the

media name matches the given

MEDIANAME, if any. If it

matches, append the backup set,

preserving all existing backup sets.

If the volume does not contain a

valid media header, an error occurs.

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 systems, 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 access controls for achieving secrecy. Discretionary access controls

cannot cope with Tro jan Horse attacks. It is therefore important to ensure that only high quality

software 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-by-

page 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 codesThe following warning codes may be returned by SQL Backup.

Warning code

Description

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



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.


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


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.


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.


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.


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.


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.


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.


445 Local data store error: <value>


and restore processes.


450 Local data store SQL error: <value>


and restore processes. There was an error preparing the SQL command used to write the data.


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.


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 codesThe following error codes may be returned by SQL Backup.

Error code

Description

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.



610 Error creating file handle for file: <value>



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 [email protected] and tell us you are evaluating SQL Backup.

668 64-bit servers require Professional license.

Please contact [email protected] 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.red-gate.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 {40700425-

0080-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, hardware-

related 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.

http://searchstorage.techtarget.com/definition/array

http://searchstorage.techtarget.com/definition/Serial-ATA

http://searchstorage.techtarget.com/definition/tape

http://searchstorage.techtarget.com/definition/restore

http://searchstorage.techtarget.com/definition/backup

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

http://en.wikipedia.org/wiki/Cryptographic_software

http://en.wikipedia.org/wiki/Digital_signature

http://en.wikipedia.org/wiki/Message_authentication_code

http://en.wikipedia.org/wiki/Wikipedia:Citation_needed

http://en.wikipedia.org/wiki/Encryption#cite_note-4

http://en.wikipedia.org/wiki/Automatic_teller_machine

http://en.wikipedia.org/wiki/Bluetooth

http://en.wikipedia.org/wiki/Wireless_intercom

http://en.wikipedia.org/wiki/Wireless_intercom

http://en.wikipedia.org/wiki/Wireless_microphone

http://en.wikipedia.org/wiki/Mobile_telephone

http://en.wikipedia.org/wiki/E-commerce

http://en.wikipedia.org/wiki/Internet

http://en.wikipedia.org/wiki/Computer_network


http://en.wikipedia.org/wiki/Copy_protection

http://en.wikipedia.org/wiki/Reverse_engineering

http://en.wikipedia.org/wiki/Digital_rights_management

http://en.wikipedia.org/wiki/USB_flash_drives

http://en.wikipedia.org/wiki/Computers

http://searchstorage.techtarget.com/definition/storage-area-network-SAN

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

https://discussions.apple.com/message/21388401#21388401

https://discussions.apple.com/message/21390417#21390417

http://en.wikipedia.org/wiki/Encryption#cite_note-5

http://en.wikipedia.org/wiki/Symantec

http://en.wikipedia.org/wiki/Phil_Zimmermann

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

http://en.wikipedia.org/wiki/Public_key_encryption


http://en.wikipedia.org/wiki/Trojan_horse_(computing)

http://en.wikipedia.org/wiki/TEMPEST

http://en.wikipedia.org/wiki/Traffic_analysis

http://en.wikipedia.org/wiki/Cryptographic_software

[and less frequently than incremental/differential log backup]. Configuring a synthetic full

backup scheduling is optional.


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.





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.






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. REFERENCES

[1] www.simple-talk.com/sql/database-administration/sql-server-backup, 25 September

2013

http://www.simple-talk.com/sql/database-administration/sql-server-backup

[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

http://i.cmpnet.com/v2.gocsi.com/pdf/CSIsurvey2008.pdf

https://discussions.apple.com/thread/

http://www.ontrackdatarecovery.ie/common-tape-problems/

http://www.cpd.iit.edu/

http://technet.microsoft.com/en-us/library/aa225964(v=SQL.80).aspx

Documents

newsqlpupougroup.weebly.comnewsqlpupougroup.weebly.com/.../database_issues._ba… · Web viewPOLYTECHNIC UNIVERSITY OF THE PHILIPPINES. OPEN UNIVERSITY SYSTEM . MIT 620 ADVANCE