In BackupAssist ER, the recommended backup method is a “disk to disk to cloud”. This gives you backup copies both on a local disk (e.g. USB HDD, NAS) and in the cloud (Azure, AWS).
The benefit of having both a local and cloud based copy of your backups are that it provides:
- Resilience and redundancy
- Multiple recovery options
I’ll explain more later, but let’s get into my challenge results.
- How did I do in the challenge?
- My test setup
- Under the hood: disk to disk to cloud backup
- My experiences and observations
- Performance analysis
- Azure costs
How did I do?
|Hands-on with BackupAssist ER |
Install, configure & start the backup
|4 min 51 secs|
|Waiting time |
Local drive image (10 min)
Upload to cloud (2 hr 32 min)
|Total time||166 min 51 secs|
For the BackupAssist ER Challenge Leaderboard, my hands-on time is 4 minutes and 51 seconds.
Here’s the video of me doing it:
My test setup
Being in COVID-19 lockdown meant I was limited to the hardware available to me at home. Luckily I had some old hardware lying around – enough that I could do the challenge.
|Equipment||Brand / model|
|Computer to be backed up||Microsoft Surface Pro 4 (from 2015)|
Intel Core m3-6Y30 CPU @ 0.90GHz
4GB RAM. Windows 10, 64-bit OS
|Local backup disk||Intel SSD 520 Series 180GB (from 2012)|
Connected via USB 3.0 enclosure, ADATA XPG
|Cloud backup storage||Microsoft Azure storage container (blobs) in the Australia East region.|
|Internet connection||4G connection via Optus, an Australian telco.|
Typical speeds of 30-50Mbps down, 30-50Mbps up.
Under the hood: disk to disk to cloud backup
Under the hood of BackupAssist ER are two backup engines – a brand new drive imaging engine, and an evolution of our existing file-based cloud backup engine.
We run the two engines in succession, for an overall two-stage backup job, giving our “disk-to-disk-to-cloud backup”.
|Disk To Disk To Cloud||Drive imaging engine||Performs a drive image to VHDX file (Microsoft Virtual Hard Disk format).|
|Cloud file backup engine||Transfers local files to cloud blob (chunk) storage, with deduplication, compression & encryption.|
This gives you a fully automated, automatic offsite backup system that allows for:
- Fast local system and granular recovery from local backup
- Cloud-based system recovery from cloud backup
- The ability to download a cloud backup to local system, and perform local recoveries anywhere.
Note: alterative scenarios are available, but the ER Challenge requires the “disk to disk to cloud” method.
How to do it
Follow the instructions here: https://www.backupassist.com/er/documentation/backup/disk-to-disk-to-cloud.htm
My experiences and observations
I found that installing BackupAssist ER and setting up my first disk-to-disk-to-cloud backup was very easy and straightforward. In fact, it was so straightforward, it’s impossible to make a mistake.
In fact, it almost seemed too simple.
I also expected that the cloud upload would take longer than it did. At about 6:30pm the backup started, and I left it to run overnight. In actuality, it finished by 8:39pm.
Stage 1 – the disk to disk image backup
|VSS Snapshot||10 seconds|
|Data transfer||7 minutes 55 seconds|
|Cataloging files||1 minute 30 seconds|
|Total size||50,138,331,579 bytes across 3 VHDX files|
Given that the backup itself took 7 minutes 55 seconds, the average transfer rate is 105554382 bytes per second – or 105.5MB/s.
Just to see how this compares with what throughput is expected with the hardware I used, I ran two robocopy operations.
Total Copied Skipped Mismatch FAILED Extras Dirs : 67746 67470 1 0 275 0 Files : 254041 253325 0 0 716 0 Bytes : 43.629 g 35.819 g 0 0 7.809 g 0 Times : 0:35:36 0:13:43 0:00:00 0:21:53 Speed : 46710848 Bytes/sec. Speed : 2672.816 MegaBytes/min.
Total Copied Skipped Mismatch FAILED Extras Dirs : 1 0 1 0 0 2 Files : 140 140 0 0 0 0 Bytes : 10.905 g 10.905 g 0 0 0 0 Times : 0:01:13 0:01:12 0:00:00 0:00:00 Speed : 161113703 Bytes/sec. Speed : 9219.000 MegaBytes/min. Ended : Saturday, 16 May 2020 2:56:19 PM
The two robocopy tests specify the expected lower and upper bounds of performance. The lower bounds – hundreds of thousands of files, is what a file backup engine can achieve, being bottlenecked by slow File I/O. The upper bounds is what a disk cloning engine can achieve, being bottlenecked by sustained disk I/O.
BackupAssist ER’s drive imaging engine is somewhere between a file backup engine and a disk cloning engine – it writes data block by block (like a disk cloner) but is aware of files, so that unused space is not backed up (like a file backup engine).
Stage 2 – the disk to cloud backup
|Upload||2 hours 31 minutes 28 seconds|
|Total size||22.79GiB = 24,470,576,168 bytes|
The average transfer rate is therefore – 2,692,625 bytes per second – 2.69MB/s.
The expected throughput from a 30Mbps connection, at 85% efficiency, is 3,187,500 bytes per second.
In my experience, this level of performance was pleasing, considering the variability in Internet speed during peak hours (6pm – 10pm). Secondary factors affecting performance include the processing it takes on the source to deduplicate, compress and encrypt, and performance of the cloud server, the network in between.
The final piece of the puzzle is to look at Azure costs. (as at May 2020)
|Operation||Cost – AUD||Cost – USD|
|Hot LRS write operations||$2.61||$1.66|
|Data transfer in||$0.00||$0.00|
At time of writing, data transfer in is free, but writing blobs is a charged operation.
Conclusion: The backup is successful – recoveries are next
And read my next blog: BackupAssist ER Challenge – the Local VM Instant Boot Recovery
Until next time,