Recently, I have been confronted with problems and opinions on the subject of backup and Exchange Server. This is certainly a topic that can be argued about, so I have collected a few statements on the subject of backup:
- We don't need a backup, we use a DAG
- We don't need a backup, we have a mail archive
- We back up Exchange and store the backups for 10 years
- We back up Exchange with Windows Server backup to an external USB HDD
- You cannot secure Exchange properly
- We don't need a backup, we have a DAG and a lagged copy
- We make an image backup, only the many log files are disturbing
I will leave these statements as they are for now, even if I have my problems with some of them. First of all, the facts about backup and Exchange Server.
Supported backup technology
Exchange 2016 only supports "Exchange-aware", VSS (Volume Shadow Copy Service) based backups. "Exchange-aware" specifically means that the backup tool used must use the Exchange VSS Writer to back up and restore Exchange databases. Exchange 2016 installs a VSS Writer with the name "Exchange Writer" for this purpose:
Backup programs that want to back up Exchange Server must therefore address the "Microsoft Exchange Writer" if a backup is to be carried out.
Exchange 2016 (already valid from Exchange 2013) has a significant change compared to the VSS writer architecture used in Exchange 2010. Exchange 2010 contained two VSS Writers: one in the Microsoft Exchange Information Storage Service (store.exe) and one in the Microsoft Exchange Replication Service (msexchangerepl.exe). The functions of the two VSS Writers were combined into one Writer in Exchange 2016: Microsoft Exchange Writer. This Writer can now be used to back up and restore active and passive databases.
Although the new Writer runs under the "Microsoft Exchange Replication" service, it still requires the "Microsoft Exchange Information Store" service, so both Exchange services are required for a backup application to be able to back up and restore Exchange databases.
The Exchange Writer supports the following backup types:
| Backup type: | Description: |
| Full Backup | Backs up the database (.edb), transaction logs (.log) and checkpoint files (.chk). The transaction logs (.log) of the database are truncated and deleted. |
| Copy Backup | Backs up the database (.edb), transaction logs (.log) and checkpoint files (.chk). The transaction logs (.log) of the database are not deleted and are retained. |
| Incremental backup | Backs up only the transaction logs (.log) since the last incremental or full backup. The transaction logs (.log) of the database are truncated and deleted. |
| Differential backup | Backs up only the transaction logs (.log) since the last incremental or full backup. The transaction logs (.log) of the database are not deleted and are retained. |
Exchange Writer backup process
The following diagram shows how a backup is carried out with the VSS Writer:
A backup is essentially carried out on the basis of the following points:
- The backup program (or an agent) starts the backup process
- The VSS requester of the backup program sends the command to create a VSS snapshot of the respective Exchange database
- VSS communicates with the Exchange Writer to prepare a snapshot. Exchange 2016 prohibits administrative actions for the database, checks all volume dependencies and interrupts all write operations for the selected instance of the database and transaction logs. During the creation of the snapshot, only read access is permitted.
- VSS communicates with the relevant storage providers to create a snapshot of the volumes containing the selected Exchange database.
- After the snapshot has been created, VSS Exchange informs you that normal operation can continue, write operations and administrative actions can be carried out again.
- The backup program now backs up the data from the snapshot
- The VSS requester of the backup program verifies the consistency of the backup and reports a successful backup. Exchange deletes the transaction logs after a successful backup and records the time of the backup for the database. If the database is part of a DAG, the log shortening is replicated among all copies; servers that hold a copy of the database also delete the transaction logs.
-
Do I need a backup now?
To come back to the statements mentioned at the beginning: Do I need a backup at all?
Nobody needs a fuse,...
... because in the event of a disaster, the only thing that matters is recovery.
I would like to refer to the collected statements:
Whether and how Exchange is secured depends on the company's requirements. There are a few points that should be considered here:
- An e-mail archive is no substitute for a backup; in the event of a defective database, a functioning database can rarely be restored from it. Even though there may be solutions that make this possible in principle, how long does a restore take and how long will the system be up and running?
- A DAG with two servers in the same server room / data center only protects against the failure of a single server / database. Errors / effects on the server room / data center can also cause Exchange to fail.
- A backup to an external USB-HDD is certainly better than having no backup at all in the event of a fault. But here too, as long as the backup is located in the same server room or data center, a fire, for example, could destroy the Exchange server(s) including the backup. The same applies to a DAG with a lagged copy; in the worst case, you may have little to gain.
- How long backups need to be kept depends on the requirements of the company. I would simply say that very few people restore a database from the last year. An archive is a good way to have access to old emails if necessary.
- Exchange can be backed up using an image tool. However, this tool should then be able to address the Exchange VSS Writer so that the backup is also in a consistent state. This is the only way to ensure that the log files are truncated and deleted.
- Backups and restores must be tested regularly. On the one hand, this gives you the certainty that the restore works and you acquire a certain routine that prevents errors in the event of a disaster.
Whether and how Exchange is secured depends more on how important the system is for the company. If an Exchange failure can disrupt important business processes in the company, you should have the best possible protection against it.
In the K case, it is usually important to get the system up and running as quickly as possible (definition issue) with the most up-to-date data (definition issue). Will a backup from 2007 still help me?
And yes, you can get by without a backup, but then you should have at least two data centers that are sufficiently far apart. Sufficient distance is again a matter of definition, just think of a flood.