The Mozy Blog: Windows 10, FilterError0, and Digitally Signed Driver Errors
A new update has been released for the Windows client that resolves some issues users were experiencing with Windows 10. Check out the latest blog for details!
In a recent Mozy newsletter, you may have heard about an increase to the retention time Mozy keeps versions of your files. We at Mozy, understand that having a greater retention period provides our users a greater window to recover data in the event of a data loss. This increase also allows for adjustable data retention (available only to MozyPro, MozyEnterprise, and Service Providers). As exciting as this change is for Mozy, it is sure to spark many questions and concerns about how it affects the backups and restores.
From a technical and support standpoint, I want to take this opportunity to explain a bit more about what Version Consolidation (VC) is and how it would apply to the backups. First off, let me talk about the 4 main points to understand about Version Consolidation.
By using VC, Mozy is able to provide a greater window of retention for restores since there are less individual patches being retained on the data centers.
Increased Backup Performance
Using VC allows for a significantly smaller database requirement to store the information about the backups. A smaller database allows for faster backup processing
Increased Restore Speed
VC’s reduction of overall patches means less patches are needed to restore heavily patched files. Less patches to restore means files restore faster.
Decreased Restore Point Granularity
This will be explained later, but consolidating the versions does decrease the granularity of the versions that can be restored later.
When VC is turned on, a default retention policy is enabled based on account type.
MozyHome will be extended out to 90 days (currently 30 days)
MozyPro will be extended out to 180 days (currently 60 days)
MozyEnterprise will be extended out to 1 year (currently 90 days)
MozyOEM and Service Providers will be extended per contract terms.
MozyPro and MozyEnterprise will have policy choices to select from the Admin Console. The default will be in place unless specifically changed by the admin user. More information for those options will be available in the future.
How does VC work?
VC is only applicable to files that are changed. If you upload data that is never modified, VC does not affect those files. But for files that are modified, continue reading to understand how VC manages the versions of those files.
The most recent version of a certain file that is uploaded is the current version.
Backups made during a single day that upload changes to the same file, will be referred to as interim backups.
After interim backups are 3 days old, they will be consolidated, with one from each hour (where present) selected to be an hourly backup. Thus you can have up to 72 hourly backups (72 hours in 3 days).
After 3 days, a single hourly backup from each day will be selected as the daily backup.
Daily backups made in a week will be consolidated into a weekly backup on Saturday.
Weekly backups throughout a month will be consolidated into a monthly backup on the last Saturday of the month (only applies to MozyPro and up, as MozyHome does not have monthly backups).
And so on…
The details of these types need to be understood in order to know the restore capabilities of the backup.
How does this VC affect my backup performance?
Currently, Mozy keeps track of every single patch, or version, of a file and stores that information in a database. As your files are modified and then uploaded on a backup, those patches can quickly add up. Consider a SQL database or an Outlook PST file for example. Files like these are routinely changed multiple times per day. Assuming you run 12 backups per day during a 30 day window, that single file now has 360 patches.
Using VC, the number of patches for that single file, drops to 30 patches (25 daily versions, and 5 weekly versions). This decrease allows for a smaller database for the backup information. A smaller database allows for a faster backup process as it requires less time to update that database.
The decrease in patch count also allows for faster restore processing. When Mozy restores a file, we build the file together from all the patches that were backed up. Rebuilding 30 patches will take a lot less time to build than 360 patches. This would allow for restores to process faster, presenting the file for download in a more timely fashion.
How does VC decrease my restore point granularity?
As noted earlier, VC does decrease the granularity of restore points in the backup. This is a side effect of the consolidation process. However, our internal research has shown that 90% of restores downloaded from Mozy are done within a few days of the last backup. So, even using VC, this should not affect restores.
Let’s look at an example based on a MozyHome account that backed up changes to a single file every day, for 32 days.
The latest version that is backed up, or the current version, will remain indefinitely. If a file is changed and then a backup is run, that most recent version backed up becomes the new current version.
The hourly backups are available for 72 hours. This means that the hourly backup versions are available for restore going back 3 days.
The daily backups are available for 30 days. This means that the consolidated daily versions are available going back 30 days.
The weekly backups are available for 90 days. This means that the consolidated weekly versions are available going back 90 days.
Consider the calendar below. This would tell you how long until the noted version would expire based on the 90-day MozyHome retention, for backups starting Jan 1 and stopping Feb 1.
We are aware that many of you will have questions about Version Consolidation and how it would apply to your specific scenarios. Support is available on this Community as well as your communications channels on support.mozy.com.
Providing digital safety for your data is our utmost priority, so please contact us if you have ANY concerns about your data.