sql server backup damage
Transfer: https://www.cnblogs.com/zhijianliutang/p/4080916.html
1, backup files, and databases on the same (or a group) of the physical disk. A disk fails, the backup also retain his job.
2, the backup media with bad, or do a network backup, data corruption occurs in the network transmission.
3, the database is doing a full backup, file backup or file group backup time, the contents of which already have with the bad.
So based on this, we want to avoid is the occurrence of the above three cases, in addition to a situation that is doing the SQL Server database backup time to save time, it is very simple basic data page of the copy down, will not do consistency an examination. But when recovery is required to recover the database (Recover) to a point in time transactional consistency. If the damage is prevented before the backup of SQL Server roll after roll (Redo and Undo), the recovery operation will encounter an error, this time we are going to help them?
In fact, in reality, in a bad environment, you experience this problem most hardware errors, but often wrong kind of bad with permanent backup files in the content, in versions prior to 2005 SQL, you experience this problem only to find more As early as the backup. But does that mean there will generate a lot of data loss.
So after SQL 2005 introduces a new "ignore errors" of recovery, the situation in times of crisis is when you can play a good role.
The command is: CONTINUE_AFTER_ERROR
This command will restore (RESTORE) in command of a new option. It will continue with the restore operation to skip the error and restore the contents of all existing SQL Servr restore all functions. After the data reduction can be applied to subsequent transaction log backups to restore the database. Encounters an error, SQL Server will be reported in the log if the log recovery, and not allowing users to access and manipulate these matters related to the page. Online database will love as much as possible in the circumstances. So in most cases, the database can be recovered in whole or only part of the data may be lost.
Data loss error depends on the encounter. For example, the general data page errors will cause the page to enter the state can be suspicious, but the database recovery will continue. Question page number will be written to the disk and record suspect_pages tables and error logs, alert administrators to continue to deal with them after the end of the recovery. If you do not set CONTINUE_AFTER_ERROR, SQL Server encountered a page as long as there is a problem, the whole recovery operation will stop.
If an error occurs in some of the more critical areas, such as file header information of a data file, then the recovery is still possible to fail completely, the database can not be restored. All this method only for fire fighting when available, can not guarantee results each use.
After using this command to restore complete databases, remember to check the error log for more information.
The command syntax is as follows:
RESTORE DATABASE database_name FROM backup device WITH CONTINUE_AFTER_ERROR,NORECOVERY....
Administrators at the end to continue to ignore the error restore order, using DBCC CHECKDB repair the database. To make CHECKDB after use RESTORE CONTINUE_AFTER_ERROR run with the greatest consistency, it is recommended to use the option WITH TABLELOCK DBCC CHECKDB command. In extreme cases, it may not have not enough information to fix the database, CHECKDB is no way to fix the database, data loss is inevitable. Not to say, with the RESTORE CONTINUE_AFTER_ERROR, backup broken does not matter.
In fact, the key is to establish a standby server or to change the awkward single disk.
CONTINUE_AFTER_ERROR simply by the command to skip all that it can bypass the error, but also to restore all the data read out of it, to the greatest extent to restore the data. But some data consistency requirements are relatively high system like this is unacceptable.
For such systems, backup and recovery strategy of choice when building, we must consider the worst-case scenario, like a good plan in advance, to limit the damage.
You can find a spare machine, do the Log Shipping, this method is recommended, mainly low cost
It has the following advantages:
1, compared to physical techniques such mirror, this embodiment is economical. Backup service hardware not ask for much, as long as the hard drive is large enough.
2, although SQL Server provides several backup verification mechanism, but the only way to ensure complete reliability of the backup is true to restore it.
3, restore the backup in advance, so that the real disaster occurs, only the last log backup to restore. Without the need to feel the burn when to wait that long to restore a full backup, disaster recovery can greatly save time.
4, although the database on the standby machine can not be modified, may be used to restore the database to the standby parameter read-only mode. Some reports inquiries can be transferred to the standby machine, reduce the burden on the production server.
In short, data security is very important, disaster recovery requires a very short time database, if there is no guarantee of mirroring, backup server is very necessary.