Interaction of SKIP, NOSKIP, INIT, and NOINIT



POLYTECHNIC UNIVERSITY OF THE PHILIPPINESOPEN UNIVERSITY SYSTEM MIT 620 ADVANCE ORGANIZATION OF DATABASEDatabase Issue : INCOMPLETE BACKUP AND FAILURE TO ENCRYPT BACKUP DATAAssignment No. 1Date Submitted:October 6, 2013Submitted By:Sherlita B. MagpantayDr. Rosecar E. Escober(Instructor – Advance Organization of Database)IDATABASE SECURITY ISSUE: Incomplete Backup and Failure to Encrypt Backup dataIIABSTRACTThe 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.? 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.?INITNOINITSKIPIf 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.NOSKIPIf the volume contains a valid media header, perform the following checks:Verify the media password.2If 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 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 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.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.BACKGROUNDThe 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?TypeDescriptionCopy backupCopies 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 backupCopies 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 backupCopies 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 backupBacks 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 backupCopies 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 restoreNormal (nonauthoritative) restoreAuthoritative restoreTo 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 restoreUse 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 DataReason for Using Primary Restore of System State DataActive DirectoryRestoring a stand-alone domain controller.Restoring the first of several domain controllers.SYSVOLRestoring a stand-alone domain controller.Restoring the first of several domain controllersReplica setsRestoring the first replica set.Normal restoreDuring 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.STATEMENT OF THE PROBLEMThe problem of data security has three aspects: secrecy, integrity and availability. A complete solution to the secrecy problem requires high-assurance multilevel sys- tems, which impose mandatory controls and are known to be free of covert channels. Such systems are not currently available in the market, and are at the research and development stage. In due course of time products should become available. In the interim, security administrators must be aware of the limitations of discretionary ac- cess controls for achieving secrecy. Discretionary access controls cannot cope with Tro jan Horse attacks. It is therefore important to ensure that only high quality soft- ware of known origin is used in the system. (This attitude also supports the integrity. objectives.) Moreover, security administrators must appreciate that even the mandatory controls of high-assurance multilevel systems do not directly prevent inference of secret information. The integrity problem, somewhat paradoxically, is less well understood than secrecy but is better supported in existing products. The basic foundation for integrity is to ensure that all updates are carried out by well-formed transactions. This facility is reasonably well supported by current products. On the other hand integrity principles such as least privilege, separation of duties and delegation of authority are not so well supported. These are still in the domain of research and development. The availability problem is very poorly understood, and therefore existing products do not address it to any signicant degree.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.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?NewDBNameFROM??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.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.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. 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.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.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.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?VERIFYONLYFROM 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?VERIFYONLYFROM DISK=?'<Backup_location>'WITH?CHECKSUMThe 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.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.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.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.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.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 failsTape appears to be blank?Overwritten tape?Erased tape?Drive hangs?Exchange database corruptionTape 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 TapeSnapped 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 failsRead 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 blankBlank 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 TapeOverwritten 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 HangsTracking: 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.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 ProtectionThis 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 TechniqueStoreGrid 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 SizeStoreGrid 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 chosenType PasswordProvide 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 codeDescription110Failed 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.115LOGTO 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.120LOGTO 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.121LOGTO 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.130MOVETO 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.131MOVETO 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.132MOVETO 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.133MOVETO error: Folder does not exist: <value>140COPYTO 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".141COPYTO 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.142COPYTO 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.143COPYTO 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.145COPYTO error: Failed to create folder: <value>146COPYTO error: Source file does not exist: <value>147COPYTO 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.148COPYTO error: failed to delete temporary file: <value>149COPYTO error: failed to rename temp file <source> to <target>150MAILTO 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).151MAILTO error: Failed to send mail.SQL Backup failed to send an email notification. Check the error message for the cause of the failure.160ERASEFILES error: Failed to delete file: <value>SQL Backup could not delete the file that was marked for deletion.161ERASEFILES 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.162Failed 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.164Failed 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.166Failed 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.167Failed 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.168Failed 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.170Validation 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.175Another 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.195Failed 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.200Error creating backup file: <value>SQL Backup could not create the backup file. Check the error message for the cause of the failure.202Multiple 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.204Multiple attempts were made to restore from the backup file.210Error writing to backup file: <value>This is an informational message. SQL Backup could not write backup data to disk at the first attempt, but succeeded after further attempts.This indicates potential problems with storing backup files at the specified locations.213Error setting file pointer position: <value>This is an informational message. SQL Backup could not continue to write backup data to disk following a previous failure, but succeeded after further attempts.This indicates potential problems with storing backup files at the specified locations.215Error flushing buffer contents to file: <value>218Insufficient 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.220No 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.225Files 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.226Files 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.280Failed to open file.300Backup failed. Retry attempt: <value>This is an informational message. SQL Backup could not back up the database at the first attempt, but succeeded after further attempts.Check the error message for information about why each attempt failed.320Validation failed.330Your 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.400Failed to initialize local data store: <value>SQL Backup could not initialize the SQL Server Compact database it uses to store details of backup and restore processes. The SQL Server Compact database is created when the SQL Backup server components are installed and is used to improve the performance of the GUI.Check the error message for the cause of the failure.If the error message reports that access to the database file is not allowed, you need to ensure that the SQL Backup Agent Service startup account has permissions402Failed to open local data store: <value>SQL Backup could not connect to the SQL Server Compact database it uses to store details of backup and restore processes.Check the error message for the cause of the failure.405Failed to acquire handle for local data store lock (<value>): <value>410Failed to start transaction on local data store: <value>425Folder 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.435Get 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.436Get exclusive local data store access failed - abandoned.SQL Backup could not acquire a lock on the SQL Server Compact database it uses to store details of backup and restore processes. This was due to a termination request.This usually happens because the SQL Backup Agent service is in the process of shutting down.438Get exclusive local data store access failed - invalid lock handle.SQL Backup could not acquire a lock on the SQL Server Compact database it uses to store details of backup and restore processes. This was probably caused by an internal error.Try restarting the SQL Backup Agent service.440Invalid DB handle.SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup and restore processes. The database was not available.Try restarting the SQL Backup Agent service.442Get exclusive local data store access failed - invalid lock handle.SQL Backup could not release a lock on the SQL Server Compact database it uses to store details of backup and restore processes. This was probably caused by an internal error.Try restarting the SQL Backup Agent service.445Local data store error: <value>SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup and restore processes.Check the error message for the cause of the failure.450Local data store SQL error: <value>SQL Backup could not write data to the SQL Server Compact database it uses to store details of backup and restore processes. There was an error preparing the SQL command used to write the data.Check the error message for the cause of the failure.460Encryption 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.462Short passwords may not be secure.The KEYSIZE keyword has been specified, but the supplied PASSWORD is seven characters or fewer.470Transaction 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.471Failed to run sp_change_users_login report while checking for orphaned users.You used the ORPHAN_CHECK option, but SQL Backup could not run the sp_change_users_login stored procedure.Check the error message for the cause of the failure.472Orphaned users have been detected during a RESTORE operation. Check the log file for the list of orphaned users and associated SIDs.474A 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.480Failed to create output folder: <value>481The 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.483The 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 2005and 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.485File 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 codeDescription500General SQL Backup error.505No 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.506No valid backup sets found from backup history.507No valid backup sets found from provided folder(s).508No valid full backup sets found from provided folder(s) for latest differential backup.510Backup 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.512Backup file name (<value>) contains an invalid character (<value>)515Multi 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.516Multi database operations cannot use MIRRORFILE option.If you are backing up multiple databases, you cannot use the MIRRORFILE argument. See?The BACKUP command.517Cannot use MAXDATABLOCK parameter with local files.518File name exceeds limit of 259 characters: <value>519Multi-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.520Output 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.525Folder does not exist. Folder name: <value>526Cannot 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\BackupSettings527None of the specified folders exist.Check the transaction log folder locations you have specified for this log shipping restore job.530Non-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.540No 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.550Cannot have the same file names for the SQL Backup file and the converted file.560File 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.562Object is a folder, not a file: <value>564Error reading file.566Error reading files not in SQB path.570File is not a SQL Backup file.Check the file you are restoring from is not a log file or native backup file.580Failed 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.581Failed to disconnect existing connections to database.584System databases must be restored with full recovery using the RECOVERY option.585Cannot use multiple file names with the THREADCOUNT option.586Failed to connect to SQL Server instance: <value>587Backup and restore operations are not allowed on database tempdb.588You can only perform a full backup of the master database.Use BACKUP DATABASE to back up the entire master database.589Cannot back up the log of the master database.Use BACKUP DATABASE to back up the entire master database.590Insufficient space to perform process. Space required: <value>591Cannot disconnect existing users from the model database.592The REPLACE option must be used when using the DISCONNECT_EXISTING option on an active database.595Failed 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.596File is a native SQL Server backup file.597Failed to read MTF header data.600Multiple log file validation error for restore.605Error creating backup file(s). No files could be created.Ensure the startup user for the SQL Backup Agent Service application has been granted the necessary permissions. See?Security Model.610Error creating file handle for file: <value>Ensure the startup user for the SQL Backup Agent Service application has been granted the necessary permissions. See?Security Model.612Error reading file: unexpected end-of-file reached.613Compressed data block not found in file.620Error writing to backup file(s).621Error writing to backup file(s) due to insufficient disk space.622Error flushing contents of backup file(s).623Error setting file pointer position for backup file(s).624Error writing header (LSN data) to backup file (<value>): <value>.625Error writing header (backup size) to backup file (<value>): <value>.627Failed to set file pointer to beginning of file (<value>) to write backup size: <value>.628Failed to set file pointer to beginning of file (<value>) to read header data: <value>.629Failed to set file pointer to beginning of file (<value>) to write LSN data: <value>.630Cannot 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.632Failed to set file pointer to current position of file.636BACKUP WITH CONTINUE_AFTER_ERROR successfully generated a backup of the damaged database.637RESTORE WITH CONTINUE_AFTER_ERROR was successful but some damage was encountered.638The backup was written with damaged data by a BACKUP WITH CONTINUE_AFTER_ERROR.640Cannot 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.660VDI 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.dllIf 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.662The 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.665Beta trial period has expired.667Trial period has expired.Contact?licensing@red-?and tell us you are evaluating SQL Backup.66864-bit servers require Professional license.Please contact?sales@red-?for more information.680The 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:? process type entered.705When 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.710Wrong password entered.The RESTORE command contains an incorrect password, or if you are restoring from an encrypted backup file, the PASSWORD argument is missing.715Backup file is not encrypted.You do not need to specify the PASSWORD argument in the RESTORE command.716None of the backup files are encrypted.You do not need to specify the PASSWORD argument in the RESTORE LOG command.720No database name entered.740Failed to get LSN data from server.742Failed to get LSN data from server (0 rows returned).743Failed to get file position value from server.760LSN data from server is blank.765Failed to read file header (<value>): <value>. Read <value> bytes.775Failed 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.780General conversion error.782Browse via SQL: registry value not set.784Browse via SQL: not sysadmin.790General thread error or SQL Server error.Refer to your?SQL Server documentation.800File requires SQL Backup version <value> or higher to restore. Current version is <value>.810Error 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.820Validation of all backup files failed.821DBCC CHECKDB: Database integrity check completed with errors.822Encrypted files require a password to be successfully restored.825To 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.826To 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.828Failed to recover database.829Failed to drop database.830Cannot disconnect existing users when the log is not backed up with the NORECOVERY or STANDBY options.840File validation failed.850SQL Backup syntax error.870No command passed to SQL Backup.The command is empty.880BACKUP 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.890RESTORE DATABASE permission denied for database: <value>Check that you have the appropriate restore rights.900Failed to read backup file header (0 rows).910Failed to read file list details (0 rows).915Failed to update backup history table (BACKUPSET).916Failed to update restore history table (RESTOREHISTORY).917Failed to update backup history table (BACKUPSET). Media set ID is blank.918Failed to retrieve restore history id.920Failed to update backup history table (BACKUPMEDIAFAMILY).930File read error for compressed data. Backup file is incomplete or corrupted (FileBufferRemainingBytes: <value>)932File read error for compressed data size. Backup file is incomplete or corrupted (CompressedDataSize: <value>)934File read error for device index. Backup file is incomplete or corrupted (FileBufferRemainingBytes: <value>)940File read error for <value> bytes (balance <value> bytes). Backup file is incomplete or corrupted.942File read error for <value> padding bytes (balance <value> bytes). Backup file is incomplete.950Data decompression error: <value>960Failed to service command. Error code: <value>970Backup file does not exist. File name: <value> (for restores).985Error creating critical section: <value>.990Invalid number of virtual devices: <value>995Error 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.1050Failed to close VDI.1100SQL Server error.Refer to your?SQL Server documentation.2010Command exceeds permitted length.5000General inter-process communication (IPC) error.5100Error creating SQB service event: <value>5102Error creating SQB service event (already exists): <value>5110Error opening SQB service event: <value>5120Error setting SQB service event: <value>5130Error creating client event: <value>5140Error creating mutex: <value>5142Error creating mutex (already exists): <value>5145Failed to start SQL Backup Agent service.5146Inadequate rights to start SQL Backup Agent service. Please start the SQL Backup Agent service manually.5148SQL 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).5150Error opening mutex: <value>5160Error 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? 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.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:Human errorsSoftware errors (device busy, in use or other error conditions that may be recoverable)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)SAN or other connectivity problemsTape drive or media errorHardware 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.LITERATURE SUMMARYAUTHOR 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.Media failureMedia 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.Human errorIn spite of its No. 2 ranking, human error is probably the most prolific cause of backup failures. For example, if tapes are improperly stored between uses, is the resulting failure a media failure or a human error? Usually there's a significant component of human error in any backup failure.The best safeguard against human error in backups is to train those involved to follow best practices. Make sure that the people performing backups and restores understand exactly what they need to do -- and what not to do.It is also a good idea to take the person out of the loop as much as possible. Ideally, backups should not require any human action. Be especially cautious of situations where backup isn't part of someone's main duties -- for instance, someone in a branch office who's been asked to make a backup tape every night.Software failureSometimes 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.Hardware failureTape 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 work failureBacking 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.How to fix backup failuresWhatever the cause of failure, the best way to keep them from damaging your organization is to verify your backups by performing regular test restores. Testing your backups regularly won't prevent backup failures, but they can help in noticing the issue and this will allow you to fix the problem before you really need those backups and you get a nasty surprise.According to Robert Richardson, Encryption can be used to protect data "at rest", such as files on?computers?and storage devices (e.g.?USB flash drives). In recent years there have been numerous reports of confidential data such as customers' personal records being exposed through loss or theft of laptops or backup drives. Encrypting such files at rest helps protect them should physical security measures fail.?Digital rights management?systems which prevent unauthorized use or reproduction of copyrighted material and protect software against?reverse engineering?(see also?copy protection) is another somewhat different example of using encryption on data at rest.[citation needed]Encryption is also used to protect data in transit, for example data being transferred via?networks?(e.g. the?Internet,?e-commerce),?mobile telephones,?wireless microphones,wireless intercom?systems,?Bluetooth?devices and bank?automatic teller machines. There have been numerous reports of data in transit being intercepted in recent years.[4]Encrypting data in transit also helps to secure it as it is often difficult to physically secure all access to networks.[citation needed]Encryption, by itself, can protect the confidentiality of messages, but other techniques are still needed to protect the integrity and authenticity of a message; for example, verification of a?message authentication code?(MAC) or a?digital signature. Standards and?cryptographic software?and hardware to perform encryption are widely available, but successfully using encryption to ensure security may be a challenging problem. A single slip-up in system design or execution can allow successful attacks. Sometimes an adversary can obtain unencrypted information without directly undoing the encryption. See, e.g.,?traffic analysis,?TEMPEST, or?Trojan horse.[ HYPERLINK "" \o "Wikipedia:Citation needed" 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.IMPLEMENTATION This step allows you to configure the frequency at which a synthetic full backup of the selected database has to be done. A synthetic full backup is a complete full [backup] dump of the selected databases and all necessary log files but only the changed data with respect to the previous full backup /synthetic full backup [whichever is recent] is uploaded to the backup server. Once synthetic full backup completes, all log files older than the time when synthetic full backup started would be purged. Since a synthetic full backup takes lesser time to complete than the full backup, it is typically configured to run weekly or monthly or much frequently than full backup [and less frequently than incremental/differential log backup]. Configuring a synthetic full backup scheduling is optional.This step has the following options from which any one can be chosen.Run Monthly At?- Choose the time and day of the month the backup should run.?StoreGrid will run the backup every month on the particular day and time chosen.?StoreGrid will run at the stipulated time/day only.Run Weekly?- Choose the time and the day of the week the backup should run.?StoreGrid will execute the backup every week on the particular day and time chosen. Note that you can select multiple days of the week if you wish to run the backup on multiple days of the week.?StoreGrid will run at the stipulated time/day only.Log Backup Scheduling (Optional Step)Exchange Server Plugin users will have a drop-down box to optionally choose between Incremental/Differential Log Backups.?StoreGrid will do a Incremental/Differential log backup dump of the database with respect to the previous full or synthetic full or incremental log backup whenever this Incremental/Differential log backup is scheduled.Incremental Log Backup :?An incremental log backup backs up only the log files since the last full or synthetic full or incremental backup. Once an incremental backup completes, all log files older than the time when incremental backup started would be purged. You cannot perform an incremental backup when circular logging is enabled in your exchange server settings. Since only changes are backed up, incremental backups typically run faster than full and synthetic full backups. Also, as only the log files since the last backup are backed up, incremental backups will run faster than differential backups too. Hence incremental backups are always configured to be scheduled more frequently than a full and synthetic full backup. Configuring incremental backup scheduling is optional.Differential Log Backup :?A differential backup backs up only the log files since the last full backup or synthetic full backup even when the last backup was a incremental backup. The logs are not deleted after the differential backup completes. You cannot perform a differential backup when circular logging is enabled in your exchange server settings. Since only changes are backed up, differential log backups typically run faster than full and synthetic full backups. But, as all the log files since the last full backup or synthetic full backup are backed up, differential backups will take longer to finish than an incremental backup. Hence differential backups are configured to be scheduled more frequently than a full and synthetic full backup. Configuring differential backup scheduling is optional.This step has the following options from which any one can be chosen.Run Weekly?- Choose the time and the day of the week the backup should run.?StoreGrid will execute the backup every week on the particular day and time chosen. Note that you can select multiple days of the week if you wish to run the backup on multiple days of the week.?StoreGrid will run at the stipulated time/day only.Run Daily?- Choose the time at which the backup should run daily. This will execute the backup everyday at the time you have provided.?StoreGrid will run at the stipulated time only.Run Every Few Hours?- Choose the hours/minutes interval between each time?StoreGrid must run. If?StoreGrid is restarted in the interim, the backup will run once?StoreGrid starts. Thereafter,?StoreGrid automatically reschedules the next backup after the period you’ve set. For example, if you created a backup schedule at 10 am and set it to run every 1 hour,?StoreGrid will first run the schedule at 10am and the next scheduled time will be 11am. However, if at 10.15am,?StoreGrid is restarted, then the schedule will run once at 10.15am and the next scheduled time will now be set to 11.15am. Additionally, you can also select the days in which this schedule should run. For example, if you do not want to run this backup schedule on Saturdays and Sundays, uncheck the checkbox against these days.Advanced Settings (Optional)If you want to configure some additional advanced options - like, CPU utilization, Compression settings, etc. click on the Advanced Options button.Advanced Backup Schedule SettingsThere 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 SettingsSet CPU UtilizationFor 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 CompressionIf 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 backupOnce 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.CONCLUSION AND FUTURE ENHANCEMENTBecause 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.REFERENCES[1]sql/database-administration/sql-server-backup, 25 September 2013[2](v=SQL.80).aspx, 25 September 2013[3] , 23 August 2013 , “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} 29 September 2013[9] , 29 September 2013[10]Robert Richardson, 2008 CSI Computer Crime and Security Survey at 19.i. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download