Tag Archives: data protection

Random Short Take #109

Posted on by

Random short take #109. Looking for news that’s old? You’ve come to the right place. Let’s get random.

  • This opinion piece would be hilarious, if it wasn’t so alarmingly accurate. We weren’t allowed to trust Wikipedia articles but whatever AI tells us is just fine? Let’s pump the brakes and reflect, please.
  • And speaking of art and artifice, this post from John Birmingham on digital media versus holding the art in your hand was great.
  • Need to store that digital media somewhere? Backblaze knows a bit about that. Read the Q2 2026 Drive Stats report here.
  • Speaking of storage, this article over at El Reg on the Domesday Project was pretty cool.
  • And while we’re talking long-term storage, in press release news, check out what Cerabyte has been up to.
  • In people news, Preston de Guise is looking for a job. Hire him if you need someone smart who can really help your organisation.
  • I’m not looking to return to the world of home lab builds, but if you’re looking for a primer, this article covers off some of the basics really well.
  • And this is just … ugh.

Random Short Take #104

Posted on by

Random short take #104. Want news? This is where news goes to die. Let’s get random.

Brisbane VMUG – July 2025

Posted on by

The July 2025 edition of the Brisbane VMUG meeting will be held on Thursday 24th July at the Pig ‘N’ Whistle Riverside, Riverside Centre, 123 Eagle St, Brisbane City QLD 4000 from 3pm to 5pm. It’s sponsored by Druva and promises to be a great afternoon. Register here.

Here’s the agenda:

Session 1 (45min – 1hr): Cyber Recovery for VMware (Druva)

Presenter: Bruce Perram (Senior Systems Engineer)

Topic: Many organisations today are focused on prevention of cyber-attacks however organisations are still being breached. How do you recover from a cyber-attack? This session will include a demo of cyber recovery in a VMware environment. It will also explore the difference between backup & recovery from cyber recovery and the capability required rapidly perform a cyber recovery.

Session 2 (45min – 1hr): VCF 9 – The High Points and Demo (Broadcom)

Presenters: Peter Hauck (Staff Solutions Architect) and David Miller (Senior Solutions Architect)

Topic: With VCF 9 release last month there is a lot of new and exciting features to show. We will leave the details feature discussions to the excellent marketing coming from Broadcom HQ. In this session we run through a live demo of the solution and discuss what it means for customers today. The session is live so lots of opportunity to ask questions.

Druva has gone to great lengths to make sure this will be a fun and informative session. Following the sessions, the VMUG team will be hosting vBeers – an opportunity to network with other members of the community and chat with the experts!

Exciting giveaways await! You could score prizes like a VMUG Advantage subscription or a large LEGO kit – just make sure to register to be eligible.

Backblaze – Resolve bzfileids.dat File Error

Posted on by

This is a quick one. I recently had this Backblaze error pop up on one of my Mac computers.

Turns out you don’t need to contact support to resolve it, but you do need to follow the instructions in this article. I’ve copied the steps below  so you don’t need to read the article if that’s all too much for you.

Revalidating your Backup Data (Mac)

  1. Navigate to https://secure.backblaze.com/update.htm.
  2. Download the installer for macOS.
    Warning
    Do not uninstall the Backblaze Client, and do not skip the next step.
  3. Restart your computer.
  4. When your computer is back up, open the installer and click Install Now.
  5. Restart your computer.
  6. Click the Backblaze icon in your menu bar to open the Backup Client.
  7. Select Preferences.
  8. Press and hold the Option key, and click Restore Options.
  9. Let the process run for three to four hours.

Why Does This Happen?

According to the article, “[i]f you back up an extremely large number of files, or if your computer has used the Backblaze Computer Backup software for a very long time, the bzfileids.dat file may become too large to be fully loaded into RAM, prompting an error message”. I think I’ve been doing both, so there you go.

Random Short Take #103

Posted on by

Random short take #103. Want news? You’re probably not in the right place. Let’s get random.

VMware Cloud on AWS – TMCHAM – Part 14 – Stretched Clusters and Disaster Recovery

Posted on by

In this edition of Things My Customers Have Asked Me (TMCHAM), I’m going to cover some of the things to consider when looking at Disaster Recovery (DR) and availability solutions on the VMware-managed VMware Cloud on AWS platform. It might seem like basic stuff if you’re already using the platform, but there are plenty of customers I talk to that are struggling to distinguish between DR, data availability, and periodic data protection in a VMware Cloud context.

 

Terminology

I’m cheating a little here and re-using some of my older content, but I think it still holds up.

  • Disaster Recovery – Disaster Recovery is the ability to recover applications after a major event (think flood, fire, data centre is now a hole in the ground). This normally involves a failover of workloads from one DC to another in an orchestrated fashion. In a VMware context, you would use VMware Live Recovery (Site or Cyber, depending on the environment).
  • Disaster Avoidance – Disaster avoidance “is an anticipatory strategy that is in place in order to prevent any such instance of data breach or losses. It is a defensive, proactive approach to keeping data safe” (I’m quoting this from a great blog post on the topic here). In a VMware context, this would be a stretched cluster using vSAN on VMware Cloud Foundation or in VMC on AWS.
  • Periodic Data Protection – This is the kind of data protection activity we normally associate with “backups”. It is usually a daily activity (or perhaps as frequent as hourly) and the data is normally used for ad-hoc data file recovery requests. Some people use their backup data as an archive. They’re bad people and shouldn’t be trusted. You should consider PDP as separate to DA or DR solutions.

 

So How Do I Best Protect My Workloads? (Part 1)

Understand Your Workloads

You need to understand how your applications work. And you need to understand what talks to them and what they talk to. There are plenty of ways of doing this, including a variety if applications available that scan network traffic and draw pretty pictures of data flows for you. From experience, there’s a very good chance you won’t get this information by reading current documentation, because it won’t be current.

You need to understand how important your applications are to you. Do you need to recover them immediately if something goes wrong? Can you do without them for a few hours? A few days? How much data can you afford to lose? All of it? (in which case why do you still have this data sitting around?). None of it? Some of it? You need to be disciplined and thorough in your assessment of your workloads and what they mean to your business, because protecting them or recovering them can be an expensive exercise.

Understand What Scares You Most

What do you call a disaster? Is it a data centre turning into a hole in the ground? Do you run most of your workloads in an area prone to natural disasters? Or are you more worried about people in hoodies breaking into your infrastructure and encrypting it and your data protection infrastructure? (Hot tip: you absolutely should be worried about this). You need to be fairly paranoid about the scenarios you’re trying to protect your environment from. No one thought it was a problem keeping workloads in two buildings in New York until it was. At the same time, you’ll need to introduce some pragmatism into your planning. I’ve had customers ask me what they could do if all of the Sydney Region was wiped out (not just the AWS deployment, but the whole city). Could they recover data to Melbourne? Sure. Would they have any staff left to do it? Or want to do it? Depending on the nature of the disaster, the technical aspects of disaster recovery are going to be the easy bits. You still need to make sure the people and process bit is covered.

Who Can Help You? 

Do you want to handle any recovery activities yourself when things go bang? Or are you happy to let someone else do the heavy lifting for you? Some folks don’t trust outsiders to do “important” things, like recover workloads, whilst other organisations would consume absolutely everything as a service if it was an option.

How Much Can You Spend?

You need to answer the questions above before you can answer how much you’re willing to spend on one (or more) solutions to help keep your workloads protected. If your apps aren’t that important, or your business can continue to run without access to these apps for a period of time, then you’re going to be less inclined to go for the “platinum” solution. But if you’re whole business relies on applications being available 24/7/365, then you’re hopefully more understanding that you’ll need to invest.

 

So How Do I Best Protect My Workloads? (Part 2)

Data Availability with VMware Cloud on AWS

As I mentioned earlier in this post, if you’re looking to provide data availability for your workloads on VMware Cloud on AWS, you should be looking at deploying a stretched cluster solution. In short, stretched clusters in VMware Cloud on AWS are designed to protect against an AWS availability zone (AZ) failure. There’s a feature brief available here that goes into more depth on the solution. Key things to note are that the vSAN stretched cluster is deployed across 3 AZs (2 workload, 1 witness). So you could have 3 hosts in one AZ, 3 in another, and VMware deploys a witness node in the third site as part of the deployment. From the document, “vSAN Fault Domains are configured to inform vSphere and vCenter which Hosts reside in which AZ. Each Fault Domain is named after the AZ it resides within to increase clarity. Logical networks are also extended using NSX to support workload mobility across the two AWS availability zones”. You also have the option to keep data using various vSAN storage policies, including:

  • Dual-site mirroring (stretched cluster)
  • None – Keep data on primary (stretched cluster)
  • None – Keep data on secondary (stretched cluster)

Why would you not just mirror everything? Cost. Some applications simply don’t need that level of resilience, but it’s too complicated to deploy multiple SDDCs to support multiple deployment topologies (you can’t have a mix of single AZ and stretched clusters in the same SDDC), so customers can keep a mix of workloads in the same deployment. Note also that external storage solutions (like FSx for NetApp ONTAP) aren’t supported for use with stretched clusters. vSphere HA will restart the VM on the surviving AZ if a site failure is detected. There’s a short video on YouTube that covers a stretched cluster deployment and is worth looking at.

Disaster Recovery with VMware Cloud on AWS

I’ve covered VMware Live Cyber Recovery (and its predecessor, VMware Cloud Disaster Recovery) on this blog before. It’s a great solution to protect on-premises, GCVE, and VMware Cloud on AWS workloads.  It provides protection to a secure cloud filesystem with a Recovery Point Objective as low as 15 minutes, the ability to perform guided ransomware recovery in an isolated environment, and SaaS-based recovery automation. The kind of things you want to consider when evaluating the suitability of VLCR to your needs would be:

  • Recovery Point Objective – the maximum amount of time in which data may have been permanently lost during an incident. VLCR goes down to 15 minutes, but if you need lower than that you need to look at other architectures.
  • Scalability – how many Virtual Machines and how much storage are you trying to protect? And how quickly do you want to recover it? And where do you want to recover it to? Some folks don’t like VMware Cloud on AWS being the only recovery option, but VMware has announced “plans to enhance VMware Live Recovery support for Google Cloud VMware Engine (GCVE) as a cyber and disaster recovery (DR) site, for both on-premises as well as GCVE environments“. You can check out the configuration maximums for VMware solutions here.
  • Networking and security – how will you access your recovery workloads? Will you use HCX to have stretched networks between your protected sites and your recovery site? What does that look like for your core networking infrastructure? Is your CISO happy to recover stuff onto a cloud platform? There are many things you’ll need to work through internally to ensure people are comfortable. I’d also recommend you go with a pilot light deployment as opposed to an on-demand solution. While the pilot light option seems more expensive, it will save you when something goes wrong and you’ve already tested your deployment.
  • Other Considerations – there’s a bunch of info in the legacy VCDR Release Notes that highlight some of the constraints to be aware of from an architectural standpoint, and understanding some of these (like the ability to protect stretched clusters, but not recover to stretched clusters) is key to ensuring your architecture will work when you push the button. And one point that is often missed by folks looking at VLCR for the first time is that, as the recovery SDDC is just a VMware Cloud on AWS deployment, you can use it for other workloads in the meantime, like dev/test stuff, when you’re not in a recovery situation.

Periodic Data Protection with VMware Cloud on AWS

There are a tonne of different things you can do here, and I’d be naive to suggest that I could cover them all effectively in this post. To use periodic data protection solutions with VMware Cloud on AWS, you should check out this KB article, and work with your data protection vendor to ensure that the solution has been tested and works on VMware Cloud on AWS. I’ve encountered a few situations where the vendor has assumed that VMware Cloud on AWS works the same way as VMware on-premises, and with the same ability to do silly things with privileged access to ESXi hosts and things of that nature. There aren’t a lot of restrictions in place, but there are some important ones, like the aforementioned limits on direct host access, restricted account privileges, and so on. Just make sure you test it before you buy it. I’ll try and cover some of the scenarios that do and don’t work in a future post (without naming too many names).

 

Conclusion

I’m sticking with solutions available with VMware Cloud on AWS in this post, mainly because that’s what I’m talking to people about on a daily basis. But there’s plenty here that can be applied more generically to a variety of infrastructure solutions. You’ll have the same questions you’ll need to ask when it comes to protecting workloads on-premises (regardless of your choice of hypervisor), and you’ll need to make some hard decisions ab out what you want to protect depending on the value of what your workloads deliver to the business, and the available budget. You might also need to consider doing a combination of all three options, depending on the importance of the data / workloads you’re looking after. I’d always pick stretched clusters to keep my workloads up and available, but that won’t help me if some hacker decides to dump ransomware in my environment and encrypt all of my stuff. But if I need to go back 24 months to retrieve some file for an auditor, I wouldn’t use VMware Live Cyber Recovery for that. I should also mention that you should be using application-level protection as your first option for application resilience too. This other stuff is all infrastructure level, and potentially not as elegant, depending on your applications. But that doesn’t mean you can’t combine both methods. Unfortunately, there’s no one magical fix for this problem, but with a bit of planning, and some critical evaluation, you can protect your workloads against all manner of bad situations. And if you can’t do everything, at least do something, but just make sure people in your business understand the difference between the two. And remember, you’re only as good as your last recovery.

Random Short Take #97

Posted on by

Welcome to Random Short Take #97. Let’s get random.

Disaster Recovery – Do It Yourself or As-a-Service?

Posted on by

I don’t normally do articles off the back of someone else’s podcast episode, but I was listening to W. Curtis Preston and Prasanna Malaiyandi discuss “To DRaaS or Not to DRaaS” on The Backup Wrap-up a little while ago, and thought it was worth diving into a bit on the old weblog. In my day job I talk to many organisations about their Disaster Recovery (DR) requirements. I’ve been doing this a while, and I’ve seen the conversation change somewhat over the last few years. This article will barely skim the surface on what you need to think about, so I recommend you listen to Curtis and Prasanna’s podcast, and while you’re at it, buy Curtis’s book. And, you know, get to know your environment. And what your environment needs.

 

The Basics

As Curtis says in the podcast, “[b]ackup is hard, recovery is harder, and disaster recovery is an advanced form of recovery”. DR is rarely a matter of having another copy of your data safely stored away from wherever your primary workloads are hosted. Sure, that’s a good start, but it’s not just about getting that data back, or the servers, it’s the connectivity as well. So you have a bunch of servers running somewhere, and you’ve managed to get some / all / most of your data back. Now what? How do your users connect to that data? How do they authenticate? How long will it take to reconfigure your routing? What if your gateway doesn’t exist any more? A lot of customers think of DR in a similar fashion to the way they treat their backup and recovery approach. Sure, it’s super important that you understand how you can meet your recovery point objectives and your recovery time objectives, but there are some other things you’ll need to worry about too.

 

What’s A Disaster?

Natural

What kind of disaster are you looking to recover from? In the olden days (let’s say about 15 years ago), I was talking to clients about natural disasters in the main. What happens when the Brisbane River has a one in a hundred years flood for the second time in 5 years? Are your data centres above river level? What about your generators? What if there’s a fire? What if you live somewhere near the ocean and there’s a big old tsunami heading your way? My friends across the ditch know all about how not to build data centres on fault lines.

Accidental

Things have evolved to cover operational considerations too. I like to joke with my customers about the backhoe operator cutting through your data centre’s fibre connection, but this is usually the reason why data centres have multiple providers. And there’s alway human error to contend with. As data gets more concentrated, and organisations look to do things more efficiently (i.e. some of them are going cheap on infrastructure investments), the risk of messing up a single component can have a bigger impact than it would have previously. You can architect around some of this, for sure, but a lot of businesses are not investing in those areas and just leaving it up to luck.

Bad Hacker, Stop It

More recently, however, the conversation I’ve been having with folks across a variety of industries has been more about some kind of human malfeasance. Whether it’s bad actors (in hoodies and darkened rooms no doubt) looking to infect your environment with malware, or someone not paying attention and unleashing ransomware into your environment, we’re seeing more and more of this kind of activity having a real impact on organisations of all shapes and sizes. So not only do you need to be able to get your data back, you need to know that it’s clean and not going to re-infect your production environment.

A Real Disaster

And how pragmatic are you going to be when considering your recovery scenarios? When I first started in the industry, the company I worked for talked about their data centres being outside the blast radius (assuming someone wanted to drop a bomb in the middle of the Brisbane CBD). That’s great as far as it goes, but are all of your operational staff going to be around to start of the recovery activities? Are any of them going to be interested in trying to recovery your SQL environment if they have family and friends who’ve been impacted by some kind of earth-shattering disaster? Probably not so much. In Australia many organisations have started looking at having some workloads in Sydney, and recovery in Melbourne, or Brisbane for that matter. All cities on the Eastern seaboard. Is that enough? What if Oz gets wiped out? Should you have a copy of the data stored in Singapore? Is data sovereignty a problem for you? Will anyone care if things are going that badly for the country?

 

Can You Do It Better?

It’s not just about being able to recover your workloads either, it’s about how you can reduce the complexity and cost of that recovery. This is key to both the success of the recovery, and the likelihood of it not getting hit with relentless budget cuts. How fast do you want to be able to recover? How much data do you want to recover? To what level? I often talk to people about them shutting down their test and development environments during a DR event. Unless your whole business is built on software development, it doesn’t always make sense to have your user acceptance testing environment up and running in your DR environment.

The cool thing about public cloud is that there’s a lot more flexibility when it comes to making decisions about how much you want to run and where you want to run it. The cloud isn’t everything though. As Prasanna mentions, if the cloud can’t run all of your workloads (think mainframe and non-x86, for example), it’s pointless to try and use it as a recovery platform. But to misquote Jason Statham’s character Turkish in Snatch – “What do I know about DR?” And if you don’t really know about DR, you should think about getting someone who does involved.

 

What If You Can’t Do It?

And what if you want to DRaaS your SaaS? Chances are high that you probably can’t do much more than rely on your existing backup and recovery processes for your SaaS platforms. There’s not much chance that you can take that Salesforce data and put it somewhere else when Salesforce has a bad day. What you can do, however, is be sure that you back that Salesforce data up so that when someone accidentally lets the bad guys in you’ve got data you can recover from.

 

Thoughts

The optimal way to approach DR is an interesting problem to try and solve, and like most things in technology, there’s no real one size fits all approach that you can take. I haven’t even really touched on the pros and cons of as-a-Service offerings versus rolling your own either. Despite my love of DIY (thanks mainly to punk rock, not home improvement), I’m generally more of a fan of getting the experts to do it. They’re generally going to have more experience, and the scale, to do what needs to be done efficiently (if not always economically). That said, it’s never as simple as just offloading the responsibility to a third-party. You might have a service provider delivering a service for you, but ultimately you’ll always be accountable for your DR outcomes, even if you’re not directly responsible for the mechanics of it.

Nexsan Announces Unity NV6000

Posted on by

Nexsan recently announced the Nexsan Unity NV6000. I had the chance to speak to Andy Hill about it, and thought I’d share some thoughts here.

 

What Is It?

[image courtesy of Nexsan]

I’ve said it before, and I’ll say it again … in the immortal words of Silicon Valley: “It’s a box”. And a reasonably powerful one at that, coming loaded with the following specifications.

Supported Protocols SAN (Fibre Channel, iSCSI), NAS (NFS, SMB 1.0 to 3.0, FTP), Object (S3)
Disk Bays | Rack U 60 | 4U
Maximum Drives with Expansion 180
Maximum Raw Capacity (chassis | total) 1.12 PB Raw | 3.36 PB Raw
System Memory (DRAM) per controller up to 128GB
FASTier 2.5″ SSD Drives (TB) 1.92 | 3.84 | 7.68 | 15.36
3.5” 7.2K SAS Drives (TB) 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20
2.5″ NVME 1DWPD SSDs (TB) N/A
Host Connectivity 16/32Gb FC | 10/25/40/100 GbE
Max CIFS | NFS File Systems 512
Data Protection: Immutable Snapshots, S3 Object-Locking, and optional Unbreakable Backup.

It’s a dual-controller platform, with each controller containing 2x Intel Xeon Silver CPUs and a 12Gb/s SAS backplane. Note that you get access to the following features included as part of the platform license:

  • Nexsan’s FASTier® Caching – Use solid-state to accelerate the performance of the underlying spinning disks
  • Nexsan Unity software version 7.0, with important enhancements to power, enterprise-class security, compliance, and ransomware protection
  • Enhanced Performance – Up to 100,000 IOPs
  • Third-Party Software Support – Windows VSS, VMware, VAAI, Commvault, Veeam Ready Repository, and more
  • Multi-Protocol Support – SAN (Fibre Channel, iSCSI), NAS (NFS, CIF, SMB1 to SMB3, FTP), Object (S3), 16/32GB FC, 10/25/40/100 GbE
  • High Availability – No single point-of-failure architecture with dual redundant storage controllers, redundant power supplies and RAID

 

Other Features

Snapshot Immutability

The snapshot immutability claim caught my eye, as immutable means a lot of things to a lot of people. Hill mentioned that the snapshot IP used on Unity was developed in-house by Nexsan and isn’t the patched together solution that some other vendors promote as an immutable solution. There are some other smarts within Unity that should give users comfort that data can’t be easily gotten at. Once you’ve set retention periods for snapshots, for example, you can’t log in to the platform and the set the date forward and have those snapshots expire. The object storage componet also supports S3 Object Lock, which is good news for punters looking to take advantage of this feature.

Unified Protocol Support

It’s in the name, and Nexsan has done a good job of incorporating a variety of storage protocols and physical access methods into the Unity platform. There’s File, Block, and Object, and support for both FC and speedy Ethernet as well. In other words, something for everyone.

Assureon Integration

One of the other features I like about the Unity is the integration with Assureon. If you’re unfamiliar with Assureon, you can check it out here. It takes storage security and compliance to another level, and is worth looking into if you have a requirement for things like regulatory compliant storage, the ability to maintain chain of custody, and fun things like that.

 

Thoughts and Further Reading

Who cares about storage arrays any more? A surprising number of people, and with good reason. Some folks still need them in the data centre. And folks are also looking for storage arrays that can do more with less. I think this is where the Nexsan offering excels, with multi-protocol and multi-transport support, along with some decent security chops and an all-inclusive licensing model, it provides for cost-effective storage (thanks to a mix of spinning rust and solid-state drives) that competes well with the solutions that have traditionally dominated the midrange market. Additionally, integration with solutions like Assureon makes this a solution that’s worth a second look, particularly if you’re in the market for object storage with a lower barrier to entry (from a cost and capacity perspective) and the ability to deal with backup data in a secure fashion.

Random Short Take #91

Posted on by

Squeezing this one in before the end of the year. It’s shorter than normal but we all have other things to do. Let’s get random.

  • Like the capacity and power consumption of tape but still want it on disk? Check out this coverage of the Disk Archive Corporation over at Blocks and Files.
  • This was a great series of posts on the RFC process. It doesn’t just happen by magic.
  • Jeff Geerling ran into some issues accessing media recently. It’s a stupid problem to have, and one of the reasons I’m still such a sucker for physical copies of things. I did giggle a bit when I first read the post though. These kind of issues come up frequently for folks outside the US thanks to content licensing challenges and studios just wanting us to keep paying for the same thing over and over again and not have any control over how we consume content.
  • My house was broken into recently. It’s a jarring experience at best. I never wanted to put cameras around my house, but now I have. If you do this in Queensland you can let the coppers know and they can ask for your help if there’s a crime in the area. I know it’s not very punk rock to surveil people but fuck those kids.
  • You didn’t think I’d get to 91 and not mention Dennis Rodman, did you? One of my top 5 favourite players of all time. Did everything on the court that I didn’t: played defence, grabbed rebounds, and gave many a high energy performance. So here’s some highlights on YouTube.

That’s it for this year. Stay safe, and see you in the future.