Data protection and virtualised machines

Eggs, meet basket


Lab Let’s face it, we’re not very good at backups.

It’s nothing to be ashamed about. Few organisations could one hundred percent put their hands on their hearts and say, “Yup, we’ve got it covered!”

And as my esteemed colleague Tony Lock likes to point out, even places that think they have backups taped (if you’ll excuse the pun) may well still find issues if they actually try to recover the information they think they are protecting.

Data protection is more complicated than just taking a copy and storing it elsewhere, to be sure – particularly given that different information types have different requirements, both in terms of their value, and business risk should information be lost. No wonder perhaps that ‘keep everything’ is often the policy for information management, whether or not it’s actually legal to do so.

Complexity kills common sense, particularly in this sphere of data protection, where it can be just too damn hard to do things right. And then, enter virtualisation, which looks set to exacerbate the problem.

There are some very simple, yet far-reaching challenges to deal with when it comes to virtualisation backup – not least that virtual machines won’t necessarily be running when backups are scheduled. This factor is both a strength and a weakness – and it has resulted in a number of potential approaches to backing up the VM.

If a virtual machine is expected to be up-and-running for example, there is nothing to preclude treating it as a traditional physical machine and backing it up accordingly – running a backup agent inside the virtual machine. Potential challenges revolve mainly around bottlenecks. We know from Reg reader feedback that up-scaling server virtualisation hits issues of I/O bandwidth, which can only be exacerbated by the bandwidth requirements of the backup window.

Equally, given that the virtual machine has its own virtual disk file, a backup can be run on the host physical machine of said file – the VHD or VMDK in Microsoft and VMware parlance respectively. The main issue here is one of preserving state. If a virtual disk file is (say) 40Gb, in the time between the backup starting and finishing, the content of the file could well have changed.

Tools such as snapshots and cloning of VM’s can help (the running VM creates a delta of changes since the snapshot) but nobody is yet providing cast-iron guarantees about the consistency of the backup. Put bluntly, the restored image might boot, but information might also get lost, which is clearly not ideal. Understandably then, the advice here is often to shut down virtual machines before backing them up. Understandable, but hardly practical for many workloads.

Ultimately perhaps, the very flexibility offered by virtualisation may be its own worst enemy when it comes to backups. There are, indeed, plenty of options – but this also means plenty of complexity. Online vs. offline, streamed vs. snapshot, guest vs. host, it becomes difficult to decide on the best approach. The fact that a VM may be restored to a different machine, or indeed taken wholesale and moved outside the organisation, is a cause of data protection issues in itself.

There’s not going to be a right answer on this – perhaps we are still waiting for a vendor to come out with a cast-iron backup solution for the virtual environment. If it existed – perhaps it already does, but we’re not familiar – it would also support deduplication, otherwise we’re going to end up with rather large quantities of backed up VM files. Further features could include the management of backups - for example scheduling backups in a way that minimises bottlenecks across the virtualised environment - and perhaps most importantly, providing visibility on exactly how well the VMs have been protected.

We know that knowledge levels around virtualisation best practice are low – so this has to be an area of considerable risk if it goes untreated. For this reason as much as any, we would welcome your experiences in this area. ®

Broader topics


Other stories you might like

  • Stolen university credentials up for sale by Russian crooks, FBI warns
    Forget dark-web souks, thousands of these are already being traded on public bazaars

    Russian crooks are selling network credentials and virtual private network access for a "multitude" of US universities and colleges on criminal marketplaces, according to the FBI.

    According to a warning issued on Thursday, these stolen credentials sell for thousands of dollars on both dark web and public internet forums, and could lead to subsequent cyberattacks against individual employees or the schools themselves.

    "The exposure of usernames and passwords can lead to brute force credential stuffing computer network attacks, whereby attackers attempt logins across various internet sites or exploit them for subsequent cyber attacks as criminal actors take advantage of users recycling the same credentials across multiple accounts, internet sites, and services," the Feds' alert [PDF] said.

    Continue reading
  • Big Tech loves talking up privacy – while trying to kill privacy legislation
    Study claims Amazon, Apple, Google, Meta, Microsoft work to derail data rules

    Amazon, Apple, Google, Meta, and Microsoft often support privacy in public statements, but behind the scenes they've been working through some common organizations to weaken or kill privacy legislation in US states.

    That's according to a report this week from news non-profit The Markup, which said the corporations hire lobbyists from the same few groups and law firms to defang or drown state privacy bills.

    The report examined 31 states when state legislatures were considering privacy legislation and identified 445 lobbyists and lobbying firms working on behalf of Amazon, Apple, Google, Meta, and Microsoft, along with industry groups like TechNet and the State Privacy and Security Coalition.

    Continue reading
  • SEC probes Musk for not properly disclosing Twitter stake
    Meanwhile, social network's board rejects resignation of one its directors

    America's financial watchdog is investigating whether Elon Musk adequately disclosed his purchase of Twitter shares last month, just as his bid to take over the social media company hangs in the balance. 

    A letter [PDF] from the SEC addressed to the tech billionaire said he "[did] not appear" to have filed the proper form detailing his 9.2 percent stake in Twitter "required 10 days from the date of acquisition," and asked him to provide more information. Musk's shares made him one of Twitter's largest shareholders. The letter is dated April 4, and was shared this week by the regulator.

    Musk quickly moved to try and buy the whole company outright in a deal initially worth over $44 billion. Musk sold a chunk of his shares in Tesla worth $8.4 billion and bagged another $7.14 billion from investors to help finance the $21 billion he promised to put forward for the deal. The remaining $25.5 billion bill was secured via debt financing by Morgan Stanley, Bank of America, Barclays, and others. But the takeover is not going smoothly.

    Continue reading

Biting the hand that feeds IT © 1998–2022