Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage
In Exchange, recovery and restore have different meanings. While restore involves putting database and log files back in place on Exchange server, recovery involves replaying transaction logs into the restored database of the server.
Hard Recovery vs. Soft Recovery: An Analysis
Recovery is further differentiated into soft recovery and hard recovery. Hard recovery is a log file replay process and is similar to soft recovery process except that in hard recovery:
Hard recovery comes into action after restoring from online backup. The log file succeeds and ignores database path listed in log files in case database is restored to different path than from which it was backed up.
Transaction log files restored in temporary folder are replayed first, as stored in temporary folder. Temporary folder is defined by the Administrator before restoration process starts. However, log files in normal transaction folder may also be replayed.
Hard recovery does not fail in absence of other databases in storage group
As mentioned earlier, in Eseutil hard recovery, database files are restored from online backup set.
Earlier, Restore in progress was used as the Registry Key. Starting Exchange 2000, this key was replaced with Restore.env. The content of current Restore.env file are viewed by running the command Eseutil.cm. Database files (EDB and STM) restored from online backup set are restored to normal paths defined to the database. Restore is actually overwriting existing databases. Before, restoring process begins, if required, create backup for existing database or move them to other location because online backup restore process may fail due to any reason and even if the existing database files do not start now; these may be repaired and data could be retrieved, if the need arises.
Steps to restore using Eseutil Hard Recovery
Create a temporary folder before starting restoration from online backup. The backup program restores transaction log files from online backup file to temporary folder location and not to the normal transaction file path.
Backup program creates a Restore.env file in temporary location. This Restore.env file in Hard Recovery performs same function as checkpoint in Soft recovery i.e. defines the range of transaction log files which should be present in temporary folder for hard recovery. Any extra log which is placed in the temporary folder logs and not defined in the range listed in Restore.env is never replayed. Recovery process automatically deletes these extra logs from the temporary folder. To include these extra logs in the Restore.env, place these in the normal transaction logs folder for the storage group and not in temporary folder. This is because, the hard recovery first finishes replaying the logs from the backup set, and checks the normal transaction logs folder for the availability of next log in sequence.
Here is an example: Let’s assume that the log file sequence starts E0000003.log to E0000008.log and needs to be restored from backup to temporary folder. After these log files are played, recovery now looks in the temporary folder for E0000009.log file which belongs to the same log sequence. Internal markers identifies it as belonging to the same log however, replay-decision is not based upon log file name alone.
Sometimes, when the log file is not located, replay continues till the log file in the series is obtainable. If log file 9 is not available, the recovery process creates a new log file in the temporary folder. This is named as E00.log.
This is the point of total recovery using Eseutil Hard Recovery. It starts automatically and attaches to most recent log file in the storage group. Subsequently, all files in the temporary directory are deleted.
However, Eseutil hard recovery does not result in recovery at all times. Following two reasons are some of the causes:
Exchange Administrators already dread the corruption in Exchange database and if Eseutil Had Recovery is unable to recover the database even after following all steps, diligently, it might further lead to more problems. Despite the fact that Eseutil is less prevalent, it is used by Exchange Administrators. New generation solutions like New-MailboxRepairRequest is replacing Isinteg tool.
Long scripts and longtime interval do not sometimes lead to favorable results. Avoid such circumstances using Exchange data recovery software. Exchange Data recovery software repairs corrupt database exchange files, and saves as MS Outlook PST files. Recovery tool manages highly corrupt files and restores all mailbox contents including Emails, attachments, contacts, and other mailbox components.
How Recovery software is better than Eseutil?
Stellar Phoenix Mailbox Exchange Recovery is one of the most suited options which performs all above functions and more and recovers complete Exchange database.
Exchange servers may get corrupt. This is followed by Database corruption. Though Eseutil Hard Recovery may yield positive results, the probability is low due to inadequate script-knowledge and outdated utility tool. Connecting with Stellar Phoenix Mailbox Exchange Recovery software ensures complete file preview and data recovery with few easy steps. As the software supports almost all Exchange versions, it is one of the favorites amongst Exchange Administrators. Demo version verifies the above said statement.
|Is Google Getting Smarter Than You? How Machine Learning is Changing Our World||117|
|Learn Reliable Approaches to Migrate Exchange 2010 Mailbox to Office 365||61|
|Improve the Security of Software With These 4 Courses||192|
|What you should to know before migrate exchange Server 2007 to exchange 2016||33|