Windows Server Backup Data Structure Causing Slow NAS Backup

We have been playing further with Windows Server Backup this week, and looking at the files and data structure that it creates, comparing file sizes, backup strategies and speed of Internet replication.

Windows Server Backup Data Structure Layout

When a Windows Server Backup 2012 writes a full backup to a share on a NAS device like a RKive.IT unit using a UNC path, it creates a data structure as follows:

 WindowsImageBackup
└── WIN2012Server
├── Backup 2016-03-03 180023
│   ├── 2566f653-ec9c-11e3-80b9-806e6f6e6963.vhdx
│   └── 2566f654-ec9c-11e3-80b9-806e6f6e6963.vhdx
├── Catalog
│   ├── BackupGlobalCatalog
│   └── GlobalCatalog
├── MediaId
└── SPPMetadataCache

You might at first glance think that this is fine, and looks well structured so that you can easily see above that the full backup was created on the 3rd March.  A typical Windows Server 2012 will probably have between 200Gb and 500Gb of data, and if it is a Small Business Server with Exchange and Sharepoint, potentially more.  However, there is a problem with this data structure given these data amounts.

Slow Cloud Data Backup

The problem comes with most companies up-link from their premises.  A typical Infinity connection will allow around 5Gb of data to be synchronised to our off-site data vault per hour.  So a 500Gb machine will take around 100 hours to synchronise.  No problem you may think, as once it has synchronised, it will already have a full backup and when the next full backup runs after 14 days of incremental backups it will just refresh the differences.  No.  This doesn’t happen quite as you and I would expect.

Windows Server Backup Creates Another Directory

You see, when the next full backup takes place, it deletes the full backup from 3rd March and creates a new directory with the new date 17th March.  These new files are now in a different folder location, as follows:

WindowsImageBackup
└── WIN2012Server
├── Backup 2016-03-17 180019
│   ├── 2566f653-ec9c-11e3-80b9-806e6f6e6963.vhdx
│   └── 2566f654-ec9c-11e3-80b9-806e6f6e6963.vhdx
├── Catalog
│   ├── BackupGlobalCatalog
│   └── GlobalCatalog
├── MediaId
└── SPPMetadataCache

What then happens is that the RKive.IT unit will then need to resynchronise all these new files, another 500Gb, or 100 hours.  Very annoying to the users of the broadband link unless throttling is employed (see your local RKive.IT unit’s control panel settings for throttling).

Resolving Slow Internet NAS to NAS Replication

In resolving the slow NAS to NAS replication between the local RKive.IT unit and the remote cloud data backup vault requires that the full backup is not deleted above, but instead updated.  Unfortunately, Windows Server Backup does not do this, so this cannot reliably be used as a customers main software to stowing data into the cloud.

Replacement for Windows Server Backup

Now we can see why there are so many replacements to Windows Server Backup on the market.  In choosing any of these, it needs to be able to firstly create a snapshot for “Disaster Recovery” (see these notes about the type of backup) and then also a mirror of the customers data structure.

Using Windows Server Backup

If you absolutely must use Windows Server Backup, what we would suggest is to keep the saved backups as small as possible.  Perhaps only stow the system state, recovery, and the C: drive of the server.  Move any data off the C: drive of the server.  Then to backup the rest of the server, D: drives and any other drive letters, use a free piece of software like FBackup to mirror (note I say mirror) your servers data volumes to the RKive.IT unit each night.  This work around would mean that the stowed data structure would not completely change that much and you can then take advantage of the ultra efficient algorithms that rsync uses to update the off-site data backup vault (NAS to NAS replication over the Internet) with changes/additions from the local RKive.IT unit.

Notes:

  • Both the RKive.IT unit and the off-site data backup vault as NAS drives.
  • The RKive.IT unit is a rented unit placed on the customers LAN.
  • The vault is also a NAS unit kept in our data centre.  The RKive.IT unit is paired and updates the vault.
  • The data sizes above are based on average examples from a few customers data stores.
  • The up-link speed is based on observed Business Infinity links with typical Internet traffic, web, mail, Windows Updates, etc.
Print Friendly, PDF & Email
Facebooktwittergoogle_pluslinkedinmail