Exchange backup is divided into online backup and offline backup. As the name implies, the backup when exchange is running is online backup, and this kind of backup often needs programs that support exchange, such as NTBACKUP and solutions provided by third-party backup software for exchange databases. This program logically backs up data, that is, backs up all data related to information storage and all data related to directory services. Offline backup is a file-level backup performed when the service is stopped.
Online backup
Exchange supports four types of online backups: regular or full, copy, incremental and differential. A regular backup first backs up the database file, then backs up the transaction log file, and then deletes the transaction log file from the directory. This means that you can disable circular logging because your backup software will delete the log files. Therefore, if you perform a regular backup, you will not encounter the problem that the log file is full. To restore a regular backup, just restore the last regular backup set and start the service.
Incremental backups only apply to log files, so they only apply when circular logging is disabled. Like regular backups, incremental backups also clear the log files after the backup. Therefore, it provides another way to delete log files without affecting recoverability. To restore an incremental backup, you must return to the last regular backup set, which contains your database files. Restore these database files, restore each incremental backup set after a regular backup, and then start the service. Please note that the service can only be started after all backup sets are restored, otherwise any logs restored after backup sets cannot run forward.
Like incremental backups, differential backups apply to log files, so circular logging must be disabled to use it. However, unlike incremental backups, differential backups do not delete log files. To restore the differential backup set, go back to the last regular backup and restore the differential backup set (including all log files generated after the last regular backup). When using incremental backup, the service can only be started after restoring all backup sets.
Offline backup, any backup software can perform offline backup. However, when restoring, offline backup cannot automatically release all log files like corresponding online backup. Therefore, Microsoft does not recommend using offline backup for daily backup. However, when online backup fails, offline backup is very important.
recover
The way to restore data depends on whether you restore online backup or offline backup. It is easier to restore online backup than offline backup. In the daily routine backup, you only need to restore the last routine backup and start the service. In a regular plus incremental backup, you will restore the last regular backup and all incremental sets and start the service, and Exchange will release all log files. In a regular plus differential backup, you will restore the last regular backup, restore the last differential backup, and start the service.
In offline backup, you will perform one step to restore the directory service and another step to restore the information store. For directory services, you should restore the DSADATA directory, and if necessary, use the Windows NT registry to find multiple DSADATA directories on different drives. Then, start the service. For information storage, restore the MDBDATA directory (its location will also appear in the registry), then run the ISINTEG.EXE program in the bin directory under Microsoft Exchange Server, and provide the program with the -patch command line option. Then, stop the service and it should start again.
2. How to do it
Online backup
To perform an online backup of your Exchange Server computer using the Backup Wizard, click Start, point to Programs, point to Accessories, point to System Tools, and then click Backup. Alternatively, type ntbackup at the command prompt.
In the Content to Back Up dialog box, select to back up the selected file, drive or network data, and then click Next. This will start the online backup.
In the Items to Back Up dialog box, expand the Exchange Server tree, select any or all Exchange Server computers in your organization to back up, and then click Next.
Note: You cannot select the gray box next to the word "Microsoft Exchange". You must double-click Microsoft Exchange or click the plus sign (+) to expand the Exchange server tree. You can expand this tree down to the directory or information store of any server. Verify that the file listed in the Backup Media or File Name box is the file to which you want to back up your data, and then click Next. Click Finish to continue the backup.
To back up an Exchange Server computer without using a wizard, follow these steps:
Click Start, point to Programs, point to Accessories, point to System Tools, and then click Backup. Alternatively, type ntbackup at the command prompt.
In the Welcome to Windows 2000 Backup and Recovery Tool dialog box, click the Backup tab, and then expand the Microsoft Exchange tree. Select any or all Exchange Server computers in your organization to back up. Note: You cannot select the gray box next to the word "Microsoft Exchange". You must double-click Microsoft Exchange or click the plus sign (+) to expand the Exchange server tree. You can expand this tree down to the directory or information store of any server.
Verify that the file listed in the Backup Media or File Name box is the file to which you want to back up your data, and then click Start Backup. Verify the information in the backup job information dialog box, and then click Start Backup.
Offline backup and recovery
Inspection work:
Determine if circular logging is enabled for the storage group (not enabled). (exchange system manager >; Storage group->; Attribute-> General, uncheck Enable circular logging. )
Determine the path locations of Exchange databases, streams, transaction logs and checkpoint files, and the log file prefixes of storage groups. (exchange system manager >; Storage group->; Attribute-> General, log file prefix (E0n), transaction log location (E0n*. Log), system path location (E0n.chk), Database paths listed in the database attribute of each database_name object, *. stm，*。 Edb) Unload the database to be backed up.
Offline backup
1. Verify the database file (. Education bureau and. Stm files) are consistent and match each other. To do this, run the following command on each file
Eseutil /mh database (*. Edb) File | Find /i "Database Signature"
Eseutil /mh database file (*. Stm)| Find /i "Database Signature"
If two files have the same DB signature, they belong to the same file set.
Eseutil /mh database file, status = clean shutdown.
2. Backup *. Economic Development Bureau and *. Stm file.
3. Load the backed-up database.
4. If you want the funds to roll in the future, please back up all numbered transaction log files (E0nxxxxx.log file). Do not back up E0n.log, Res 1.log and Res2.log files.
5. Check the file header of the checkpoint file to determine the highest numbered log file that can be safely deleted. If the database stops abnormally, the checkpoint will track the minimum number of log files required for automatic recovery. To view the checkpoint file, run the following command: eseutil /mk E0n.chk
6.Make to verify the integrity of the backup log file: eseutil /ml E0n.
Offline recovery
"Point in time" recovery. The log file will not be reloaded into the database. All data created after backup will be lost. All stopped databases in the storage group must be consistent and a valid checkpoint file must exist. Do not delete the current checkpoint file or any existing log files.
"Roll forward" recovery. The log file created after backup will be played to the database. If all log files are available, all data created after backup can be saved. If circular logging is enabled, you must perform a "point-in-time" recovery of offline backups instead of a "roll forward" recovery. All databases in the storage group must be stopped and kept consistent, and all log files created after the backup is generated must exist (including the current E0n.log). The checkpoint file must be deleted.
"point in time" recovery
1. Unmount the database to be restored, and verify that it is consistent, matches, and the checkpoint is valid.
Eseutil /mk E0n.chk | FIND /i "checkpoint"
Eseutil/mle0n.log | find/i "lgeneration" to see if the checkpoint is in the log.
2. Copy the backup. Education bureau and. Stm files are copied to the appropriate database and stream file locations.
3. In Exchange System Manager, click the Database property of the database object and select the checkbox "This database can be overwritten when restoring".
4. Load the restored database.
"Roll forward recovery"
1. Unmount the database to be recovered.
2. Check the consistency.
3. Check whether the log signature recorded in each database header is the signature of the low anchor log. Run the following command:
Eseutil /mh database_name | find /i "log signature"
Eseutil/mllow _ anchor _ log | find/i "signature"
4. Check whether the current database path location is the same as the path location when the backup was created.
Eseutil/ml "last _ consistent" _ log | find/i "database name or schema"
5. As far as possible, starting from the lowest anchor number in the continuous sequence, collect all logs and copy them to the current transaction log path.
6. Verify that all logs * * * share the same log signature and are in a continuous sequence.
eseutil/ml E0n & gt； 20049995942.htm.txt
7. If the high anchor log has not been named E0n.log, please rename it.
8. Delete the E0n.chk file from the system path folder.
9. As the last check before mounting the storage group, please verify the following:
All database files exist in their running paths.
The only log file in the running transaction log path starts from the low anchor log and at least continues to the high anchor log, and the available log with the largest number is named E0n.log.
There is no E0n.chk file in the system path folder.
10. If the information store is not running, please start it, and then mount at least one database in the storage group.
Three. Database fault handling
When the database cannot be mounted, please perform the following steps.
1. Try to start the information store and check the error message and event log.
Check consistency
Eseutil /mh database name
3. If state=dirty shutdown, don't delete the log.
If state=clean shutdown, move the log out and go to step 1 1.
4. The soft recovery eseutil /r execution is inconsistent.
Check the consistency successfully again and go to step 9.
5. If the disk space is insufficient, please perform defragmentation (eseutil /d).
6. The database is inconsistent, and the soft recovery is unsuccessful.
Delete all log files in mdbdata, as well as chk files and temp.edb files.
7. Execute eseutil /p to restore to a consistent state.
8. Load the database once, and then unload it immediately.
9. Use Isinteg.exe to repair Pub 1.edb database and Priv 1.edb database (all tests of isinteg-s (servername)-fix-test).
10. If the information storage service can be started, the information storage is stable, and the same error and warning are still reported after running Isinteg.exe for many times, please use the ExMerge utility to rebuild the information storage by exporting data. Pst format, and then import it into a new or clean database structure.
1 1. Restart the information store and mount the store.
12. Make a full backup.
Four. Other information
Yes. Education bureau and. Stm file is the final repository of all database information. In most cases, these two documents should be regarded as one document; Please back up and restore these two files in turn. The two files must be synchronized with each other in time; Ann. The edb file backed up on one day does not match the stream file backed up on another day. To avoid confusion about which log files belong to each storage group, Exchange logs belonging to the specified storage group are named with a unique log prefix, which is the first three characters of the file name, and the current log file of the storage group is always E0n.log. The transaction log has a size of 5 MB. If the current log file is full, it will be renamed with hexadecimal serial number (called log generation number) and a new current log file will be generated. The log file numbers are E0n0000 1.log, E0n00002.log, etc. The numbered log file is usually specified as E0nxxxxx.log
If the database stops abnormally, the checkpoint file (E0n.chk) will record the transaction log as the starting point of recovery, and the recovery must be replayed from this starting point to restore the consistency of the database. This process is called "soft recovery". Contrary to "hard recovery", soft recovery is the process of replaying log files after online backup is resumed. The most important difference between soft recovery and hard recovery is that during hard recovery, patch file data is inserted into the log file playback process. Inconsistent Exchange database files are files where all outstanding transactions are not written. During normal operation, the Exchange database file is inconsistent because some information in the cache has not been actually written to the file. Generally, Exchange database files are considered consistent only after the database service is shut down normally. However, the database as a whole (considered as the sum of the information in the transaction log and the database file) is always consistent, unless the required log file is deleted prematurely.
Handle mismatch between database signature and path.
Like log files, databases have their own signatures. The difference is that although the log signature will not change after the E0n00000 1.log file is created, the database signature will change whenever the physical topology of the database changes, and these changes will not be tracked through the log file. When using Eseutil to defragment or repair the database offline, the DB signature will be changed. After such an event, the database can be attached to the same previous log stream, but when the database has a previous signature, it will not accept the replay of all executed transactions. The previous copy of the database does not accept replays of any transactions executed after the database signature changes. Because the database signature is reset in this way, it is strongly recommended that you create a full database backup immediately after offline defragmentation or repair of the database. If you later restore a copy of the database with an old signature, it will be successfully relocated to the signature change point, but you will lose all changes after that point. If the database path is changed in the middle of the log stream, the effect is similar to changing the signature: the replay will be interrupted at the change point. (The online backup API provides a way to remap paths during recovery; Therefore, even if the path is changed after the backup is created, the online backup API can completely replay the log. )
Right-click the mailstore-database, and there should be an option to allow it to be overwritten by restore. Just click on it.
If it still doesn't work, it depends on the transaction log.