With the progress of technology, every aspect of computing has taken a new turn. Ancient techniques have given way to modern methods for almost everything. From exchanging data to monitoring activities to product development, everything has been revamped. Let's take the example of backing up. Till a few years ago, the media used for backing up primarily consisted of tapes. Now everything has been moved to the Cloud. With such a drastic leap of events, why would one still stick to the old brick level backup technique for backing up individual Exchange mailboxes?
This discussion throws light on this topic and explains why sticking to this old technique is not such a great idea.
Why does the need for Brick level backup exist?
Let's start with the basic question. Why might brick level backup be needed? In most cases, there is only one reason behind it – that an organization wants to selectively backup one or more mailboxes rather than the entire database.
Arguments against Brick level backups
- #1 - Taking selective backups could be understandable when it meant backing up data to slow tapes using techniques like NT Backup utility or other third-party tools. Agreed that at that time database sizes were not as huge as Exchange 2010 and Exchange 2013 allow today, still, backing up could prove to be quite slow owing to the tape media involved. Plus, tapes had the added disadvantage of being prone to failure by the time you'd reach the end of backing up. Such failures in most cases would not even be noticeable (highly dangerous situation).
- #2 – Most modern applications do not support tape backups. This includes Exchange 2010 and Exchange 2013, which don't support tape backups at least using Windows Server backup. Instead, backing up is now done using Windows Volume ShadowCopy Services (VSS) based utilities and operations. This makes the entire process much faster and more robust than before.
- #3 – It is widely stated by experts of the trade that database which are adequately and redundantly backed up (with as many as 4 copies) in the Database Availability Groups (DAGs) do not require a traditional backup system. Though inevitably, every organization would require backups to be taken for purposes such as long-term offsite storage, but at the same time, the dawn of DAGs has created a whole new environment within which to consider how and when to take backups.
- #4 – Brick level backing up is not supported by Microsoft. It doesn't provide any method to perform brick level backup. It doesn't even offer any operation that can restore information from a brick level backup and merge it into an individual mailbox seamlessly. Thus users willing to take such backups will need to come up with their own ideas for doing so.
- #5 – Restoring an individual mailbox within a database backed up using brick level technique might still be easy however, resolving any issues which might crop up during the process could prove to be a challenge.
- #6 – To take the backup of a single mailbox, using a PowerShell cmdlet called New-MailboxExportRequest cmdlet to export everything out to one or more PSTs could prove to be much more convenient and quick. Similarly, to restore content from a database, you could mount an Exchange recovery database using a backup copy and then recover the data from it using the New-MailboxRestoreRequest cmdlet.
Alternatively, there is a good solution available to replace brick level method as well as manual PowerShell command technique. Try Stellar Repair for Exchange software over Exchange brick level backup to extract and restore individual Exchange mailbox and mailbox items to Outlook PST file. Whether Exchange database is in offline mode or corrupt, you can open, export, and restore selective mailbox for good backup; rather than a complete database backup.
Free Download Buy Now* Download free version to scan and preview recoverable exchange mailbox items.
