Rubrik Cloud Data Management 4.2 Announced – “Purpose Built for the Hybrid Cloud”

Rubrik recently announced 4.2 of their Cloud Data Management platform and I was fortunate enough to sit in on a sneak preview from Chris Wahl, Kenneth Hui, and Rebecca Fitzhugh. “Purpose Built for the Hybrid Cloud”, there are a whole bunch of new features in this release. I’ve included a summary table below, and will dig in to some of the more interesting ones.

Expanding the Ecosystem Core Features & Services General Enhancements
AWS Native Protection (EC2 Instances) Rubrik Envoy SQL Server FILESTREAM
VMware vCloud Director Integration Rubrik Edge on Hyper-V SQL Server Log Shipping
Windows Full Volume Protection Network Throttling NAS Native API Integration
AIX & Solaris Support VLAN Tagging (GUI) NAS SMB Scan Enhancements
SNMP AHV VSS snapshot
Multi-File restore Proxy per Archival Location
Reader-Writer Archival Locations

 

AWS Native Protection (EC2 Instances)

One of the key parts of this announcement is cloud-native protection, delivered specifically with AWS EBS Snapshots. The cool thing is you can have Rubrik running on-premises or sitting in the cloud.

Use cases?

  • Automate manual processes – use policy engine to automate lifecycle management of snapshots, including scheduling and retention
  • Rapid recovery from failure – eliminate manual steps for instance and file recovery
  • Replicate instances in other availability zones and regions – launch instances in other AZs and Regions when needed using snapshots
  • Consolidate data management – one solution to manage data across on-premises DCs and public clouds

Snapshots have been a manual process to deal with. Now there’s no need to mess with crontab or various AWS tools to get the snaps done. It also aligns with Rubrik’s vision of having a single tool to manage both cloud and on-premises workloads. The good news is that files in snapshots are indexed and searchable, so individual file recovery is also pretty simple.

 

VMware vCloud Director Integration

It may or may not be a surprise to learn that VMware vCloud Director is still in heavy use with service providers, so news of Rubrik integration with vCD shouldn’t be too shocking. Rubrik spent a little time talking about some of the “Foundational Services” they offer, including:

  • Backup – Hosted or Managed
  • ROBO Protection
  • DR – Mirrored Site service
  • Archival – Hosted or Managed

The value they add, though, is in the additional services, or what they term “Next Generation premium services”. These include:

  • Dev / Test
  • Cloud Archival
  • DR in Cloud
  • Near-zero availability
  • Cloud migration
  • Cloud app protection

Self-service is the key

To be able to deliver a number of these services, particularly in the service provider space, there’s been a big focus on multi-tenancy.

  • Operate multi-customer configuration through a single cluster
  • Logically partition cluster into tenants as “Organisations”
  • Offer self-service management for each organisation
  • Centrally control, monitoring and reporting with aggregated data

Support for vCD (version 8.10 and later) is as follows:

  • Auto discovery of vCD hierarchy
  • SLA based auto protect at different levels of vCD hierarchy
  • vCD Instance
  • vCD Organization • Org VDC
  • vApp
  • Recovery workflows
  • Export and Instant recovery
  • Network settings
  • File restore
  • Self-service using multi-tenancy
  • Reports for vCD organization

 

Windows Full Volume Protection

Rubrik have always had fileset-based protection, and they’re now offering the ability with Windows hosts to protect a volume at a time, eg. C:\ volume. These protection jobs incorporate additional information such as partition type, volume size, and permissions.

[image courtesy of Rubrik]

There’s also a Rubrik-created package to create bootable Microsoft Windows Preinstallation Environment (WinPE) media to restore the OS as well as provide disk partition information. There are multiple options for customers to recover entire volumes in addition to system state, including Master Boot Record (MBR), GUID Partition Table (GPT) information, and OS.

Why would you? There are a few use cases, including

  • P2V – remember those?
  • Physical RDM mapping compatibility – you might still have those about, because, well, reasons
  • Physical Exchange servers and log truncation
  • Cloud mobility (AWS to Azure or vice versa)

So now you can select volumes or filesets, and you can store the volumes in a Volume Group.

[image courtesy of Rubrik]

 

AIX and Solaris Support

Wahl was reluctant to refer to AIX and Solaris as “traditional” DC applications, because it all makes us feel that little bit older. In any case, AIX support was already available in the 4.1.1 release, and 4.2 adds Oracle Solaris support. There are a few restore scenarios that come to mind, particularly when it comes to things like migration. These include:

  • Restore (in place) – Restores the original AIX server at the original path or a different path.
  • Export (out of place) – Allows exporting to another AIX or Linux host that has the Rubrik Backup Service (RBS) running.
  • Download Only – Ability to download files to the machine from which the administrator is running the Rubrik web interface.
  • Migration – Any AIX application data can be restored or exported to a Linux host, or vice versa from Linux to an AIX host. In some cases, customers have leveraged this capability for OS migrations, removing the need for other tools.

 

Rubrik Envoy

Rubrik Envoy is a trusted ambassador (its certificate is issued by the Rubrik cluster) that represents the service provider’s Rubrik cluster in an isolated tenant network.

[image courtesy of Rubrik]

 

The idea is that service providers are able to offer backup-as-a-service (BaaS) to co-hosted tenants, enabling self-service SLA management with on-demand backup and recovery. The cool thing is you don’t have to deploy the Virtual Edition into the tenant network to get the connectivity you need. Here’s how it comes together:

  1. Once a tenant subscribes to BaaS from the SP, an Envoy virtual appliance is deployed on the tenant’s network.
  2. The tenant may log into Envoy, which will route the Rubrik UI to the MSP’s Rubrik cluster.
  3. Envoy will only allow access to objects that belong to the tenant.
  4. The Rubrik cluster works with the tenant VMs, via Envoy, for all application quiescence, file restore, point-in-time recovery, etc.

 

Network Throttling

Network throttling is something that a lot of customers were interested in. There’s not an awful lot to say about it, but the options are No, Default and Scheduled. You can use it to configure the amount of bandwidth used by archival and replication traffic, for example.

 

Core Feature Improvements

There are a few other nice things that have been added to the platform as well.

  • Rubrik Edge is now available on Hyper-V
  • VLAN tagging was supported in 4.1 via the CLI, GUI configuration is now available
  • SNMPv2c support (I loves me some SNMP)
  • GUI support for multi-file recovery

 

General Enhancements

A few other enhancements have been added, including:

  • SQL Server FILESTREAM fully supported now (I’m not shouting, it’s just how they like to write it);
  • SQL Server Log Shipping; and
  • Per-Archive Proxy Support.

Rubrik were also pretty happy to announce NAS Vendor Native API Integration with NetApp and Isilon.

  • Network Attached Storage (NAS) vendor-native API integration.
    • NetApp ONTAP (ONTAP API v8.2 and later) supporting cluster-mode for NetApp filers.
    • Dell EMC Isilon OneFS (v8.x and later) + ChangeList (v7.1.1 and later)
  • NAS vendor-native API integration further enhances our current capability to take volume-based snapshots.
  • This feature also enhances the overall backup fileset backup performance.

NAS SMB Scan Enhancements have also been included, providing a 10x performance improvement (according to Rubrik).

 

Thoughts

Point releases aren’t meant to be massive undertakings, but companies like Rubrik are moving at a fair pace and adding support for products to try and meet the requirements of their customers. There’s a fair bit going on in this one, and the support for AWS snapshots is kind of a big deal. I really like Rubrik’s focus on multi-tenancy, and they’re slowing opening up doors to some enterprises still using the likes of AIX and Solaris. This has previously been the domain of the more traditional vendors, so it’s nice to see progress has been made. Not all of the world runs on containers or in vSphere VMs, so delivering this capability will only help Rubrik gain traction in some of the more conservative shops around town.

Rubrik are working hard to address some of the “enterprise-y” shortcomings or gaps that may have been present in earlier iterations of their product. It’s great to see this progress over such a short period of time, and I’m looking forward to hearing about what else they have up their sleeve.

Cohesity Basics – Cloud Tier

I’ve been doing some work with Cohesity in our lab and thought it worth covering some of the basic features that I think are pretty neat. In this edition of Cohesity Basics, I thought I’d quickly cover off how to get started with the “Cloud Tier” feature. You can read about Cohesity’s cloud integration approach here. El Reg did a nice write-up on the capability when it was first introduced as well.

 

What Is It?

Cohesity have a number of different technologies that integrate with the cloud, including Cloud Archive and Cloud Tier. With Cloud Archive you can send copies of snapshots up to the cloud to keep as a copy separate to the backup data you might have replicated to a secondary appliance. This is useful if you have some requirement to keep a monthly or six-monthly copy somewhere for compliance reasons. Cloud Tier is an overflow technology that allows you to have cold data migrated to a cloud target when the capacity of your environment exceeds 80%. Note that “coldness” is defined in this instance as older than 60 days. That is, you can’t just pump a lot of data in to your appliance to see how this works (trust me on that). The coldness level is configurable, but I recommend you engage with Cohesity support before you go down that track. It’s also important to note that once you turn on Cloud Tier for a View Box, you can’t turn it off again.

 

How Do I?

Here’s how to get started in 10 steps or less. Apologies if the quality of some of these screenshots is not great. The first thing to do is register an External Target on your appliance. In this example I’m running version 5.0.1 of the platform on a Cohesity Virtual Edition VM. Click on Protection – External Target.

Under External Targets you’ll see any External Targets you’ve already configured. Select Register External Target.

You’ll need to give it a name and choose whether you’re using it for Archival or Cloud Tier. This choice also impacts some of the types of available targets. You can’t, for example, configure a NAS or QStar target for use with Cloud Tier.

Selecting Cloud Tier will provide you with more cloudy targets, such as Google, AWS and Azure.

 

In this example, I’ve selected S3 (having already created the bucket I wanted to test with). You need to know the Bucket name, Region, Access Key ID and your Secret Access Key.

If you have it all correct, you can click on Register and it will work. If you’ve provided the wrong credentials, it won’t work. You then need to enable Cloud Tier on the View Box. Go to Platform – Cluster.

Click on View Boxes and the click on the three dots on the right to Edit the View Box configuration.

You then can toggle Cloud Tier and select the External Target you want to use for Cloud Tier.

Once everything is configured (and assuming you have some cold data to move to the cloud and your appliance is over 80% full) you can click on the cluster dashboard and you’ll see an overview of Cloud Tier storage in the Storage part of the overview.

 

 

Thoughts?

All the kids are getting into cloud nowadays, and Cohesity is no exception. I like this feature because it can help with managing capacity on your on-premises appliance, particularly if you’ve had a sudden influx of data into the environment, or you have a lot of old data that you likely won’t be accessing. You still need to think about your egress charges (if you need to get those cold blocks back) and you need to think about what the cost of that S3 bucket (or whatever you’re using) really is. I don’t see the default coldness level being a problem, as you’d hope that you sized your appliance well enough to cope with a certain amount of growth.

Features like this demonstrate both a willingness on behalf of Cohesity to embrace cloud technologies, as well as a focus on ease of use when it comes to reasonably complicated activities like moving protection data to an alternative location. My thinking is that you wouldn’t necessarily want to find yourself in the position of having to suddenly shunt a bunch of cold data to a cloud location if you can help it (although I haven’t done the maths on which is a better option) but it’s nice to know that the option is available and easy enough to setup.

Random Short Take #5

So it’s been over six months since I did one of these, and it’s clear that I’m literally rubbish at doing them regularly.

Cohesity – SQL Log Backup Warning

This one falls into the category of “unlikely that it will happen to you but might be worth noting”. I’ve been working with some Cohesity gear in the lab recently and came across a warning, not an error, when I was doing a SQL backup.

But before I get to that, it’s important to share the context of the testing. With Cohesity, there’s some support for protecting Microsoft SQL workloads that live on Windows Failover Clusters (as well as AAGs – but that’s a story for another time). You configure these separately from your virtual sources, and you install an agent on each node in the cluster. In my test environment I’ve created a simple two-node Windows Failover Cluster based on Windows 2016. It has some shared disk and a heartbeat network (a tip of the hat to Windows clusters of yore). I’ve cheated, because it’s virtualised, but needs must and all that. I’m running SQL 2014 on top of this. It took me a little while to get that working properly, mainly because I’m a numpty with SQL. I finally had everything setup when I noticed the following error after each SQL protection job ran.

I was a bit confused as I had set the databases to full recovery mode. Of course, the more it happened, the more I got frustrated. I fiddled about with permissions on the cluster, manual maintenance jobs, database roles and all manner of things I shouldn’t be touching. I even went for a short walk. The thing I didn’t do, though, was click the arrow on the left hand side of the job. That expands the job run details so you can read more about what happened. If I’d done that, I would have seen this error straight away. And the phrase “No databases available for log backup” would have made more sense.

And I would have realised that the reason I was getting the log backup warning was because it was skipping the system databases and, as I didn’t have any other databases deployed, it wasn’t doing any log backups. This is an entirely unlikely scenario in the real world, because you’ll be backing up SQL clusters that have data on them. If they don’t have data on them, they’re likely low value items and won’t get protected. The only situation where you might come across this is if you’re testing your infrastructure before deploying data to it. I resolved the issue by creating a small database. The log backups then went through without issue.

For reference, the DataPlatform version I’m using is 5.0.1.

Cohesity Basics – Auto Protect

I’ve been doing some work with Cohesity in our lab and thought it worth covering some of the basic features that I think are pretty neat. In this edition of Cohesity Basics, I thought I’d quickly cover off the “Auto Protect” feature. If you read their white paper on data protection, you’ll find the following line: “As new virtual machines are added, they are auto discovered and included in the protection policy that meets the desired SLAs”. It seems like a pretty cool feature, and was introduced in version 4.0. I wanted to find out a bit more about how it works.

 

What Is It?

Auto Protect will “protect new VMs that are added to a selected parent Object (such as a Datacenter, Folder, Cluster or Host)”. The idea behind this is that you can add a source and have Cohesity automatically protect all of the VMs in a folder, cluster, etc. The cool thing is that it will also protect any new VMs added to that source.

When you’re adding Objects to a Protection Job, you can select what to auto protect. In the screenshot below you can see that the Datacenter in my vCenter has Auto Protect turned off.

The good news is that you can explicitly exclude Objects as well. Here’s what the various icons mean.

[Image courtesy of Cohesity]

 

What Happens?

When you create a Protection Job in Cohesity you add Objects to the job. If you select to Auto Protect this Object, anything under that Object will automatically be protected. Every time the Protection Job runs, if the Object hierarchy has been refreshed on the Cohesity Cluster, new VMs are also backed up even though the new VM has not been manually included in the Protection Job. There are two ways that the Object hierarchy gets refreshed. It is automatically done every 4 hours by the cluster. If you’re in a hurry though, you can do it manually. Go to Protection -> Sources and click on the Source you’d like to refresh. There’s a refresh button to click on and you’ll see your new Objects showing up.

 

Why Wouldn’t You?

As part of my testing, I’ve been creating “catchall” Protection Jobs and adding all the VMs in the environment into the jobs. But we have some VMware NSX Controller VMs in our lab, and VMware “only supports backing up the NSX Edge and controller through the NSX Manager“. Not only that, but it simply won’t work.

In any case, you can use FTP to back up your NSX VMs if you really feel like that’s emoting you want to do. More info on that is here. You also want to be careful that you’re not backing up stuff you don’t need to, such as clones and odds and sods. Should I try protecting the Cohesity Virtual Edition appliance VM? I don’t know about that …

 

Thoughts

I generally prefer data protection configurations that “protect everything and exclude as required”. While Auto Protect is turned off by default, it’s simple enough to turn on when you get started. And it’s a great feature, particularly in dynamic environments where there’s no automation of data protection when new workloads are provisioned (a problem for another time). Hat tip to my Cohesity SE Pete Marfatia for pointing this feature out to me.

Moving From CrashPlan Back To BackBlaze

The Problem

I recently received an email from the CrashPlan for Home Team and have included some of the text below:

“Thank you for being a CrashPlan® for Home customer. We’re honored that you’ve trusted us to protect your data.

It’s because of this trust that we want you to know that we have shifted our business strategy to focus on the enterprise and small business segments. This means that over the next 14 months we will be exiting the consumer market and you must choose another option for data backup before your subscription expires. We are committed to providing you with an easy and efficient transition.”

You may or may not recall (or care) that I moved from Mozy to BackBlaze when Mozy changed their pricing scheme. I then moved to CrashPlan when a local (to Australia) contact offered me an evaluation of their seed service. Since then I’ve been pretty happy with CrashPlan, and had setup some peer to peer stuff with Mat as well.

 

Now What?

CrashPlan are offering existing customers a very smooth transition to their business plans. While the price is a little higher than before, it’s still very reasonable. And there’s a big discount on offer for the first twelve months, and a bunch of other options available. Plus, I wouldn’t have to re-seed my data, and I can access local support and resources.

 

The Siren’s Call

There are a whole lot of differnet cloud backup solutions you can access. They’re listed in this handy table here. Some of them are sync-only services, and some of them are fully-fledged offerings. I’ve been a fan of BackBlaze’s offering and technical transparency for a long time, and noticed they were pretty quick to put up a post showing off their wares. Their pricing is very reasonable, I’ve never had too many problems with the software, and they offer USB restores of data if required. The issue is that I have about 1TB of data to seed and on an ADSL connection it’s going to take for ages. BackBlaze’s don’t offer the ability to seed data in a similar fashion to CrashPlan, so I’ll be sucking it up and trickling the data up to BackBlaze while maintaining my account with CrashPlan for Home. I’ll get back to you in a few years and let you know how that’s gone. In the meantime, the kind folks at BackBlaze did send me this link to their FAQ on moving from CrashPlan to BackBlaze which may be useful.

 

Feelings

A few people on the Internet were a bit cranky about the news of this mild pivot / change of strategic focus from CrashPlan. I think that’s testament to CrashPlan’s quality product and competitive pricing. They’re still giving users a lot of notice about what’s happening, and offering a very accessible migration path. The business plan is still very affordable, and offers a lot of useful functionality. As Mozy discovered a few years ago, consumers are notoriously cheap, and it’s sometimes hard to pay the bills when the market is demanding ridiculously low prices for what are actually pretty important services. I have no insight into CrashPlan’s financials, and won’t pretend to understand the drive behind this. I could choose to move my account to their business plan and not have to re-seed my data again, but I’ve always had a soft spot for BackBlaze, so I’ll be moving back to them.

If you’re not backing up your data (at least locally, and ideally to more than one destination) than you should start doing that. There’s nothing worse than trying to put back the pieces of your digital life from scraps of social media scattered across the Internet. If you’ve already got things in hand – good for you. Talk to your friends about the problem too. It’s a problem that can impact anyone, at any time, and it’s something that not enough people are talking about openly. BackBlaze haven’t paid me any money to write this post, I just thought it was something people might be interested in, given the experiences I’ve had with various vendors over time.

Opinion: How Much Do You Really Care About Your Data?

I’m sure you care a lot about it. I care a lot about my data. And I get paid to care about other people’s data too (up to a point). I did this as a topic for vBrownBag at Dell EMC World 2017. Unfortunately I wasn’t as prepared as I should have been and had a brain freeze towards the end and cut it short. The premise of the talk was around sizing for data protection activities. Whilst I didn’t want to go into specifics from a technical perspective, I think some people have been missing some fundamental stuff and I thought it might be useful to post some concepts that may prove useful.

 

Build The Foundation

Get your data protection foundation in place before you buy anything. It seems obvious, but you need to do a whole lot of preparatory work before you can put a reliable data protection solution in place. The key to a solid foundation, in my opinion, is understanding the answers to the following questions:

  • What are you trying to do?
  • What’s really important to the business?
  • How do you categorise the information and articulate the value?
  • What about dead data?

Once you’ve been able to successfully answer these questions, you can start to think about how the answers can be converted into a data protection solution.

 

What Are You Trying To Do?

Understanding what you’re actually trying to do is important. It seems a simple thing, but I run into a lot of well-meaning people who don’t understand the difference between backup and recovery, disaster recovery, and archiving. You might perform backup activities on a daily / weekly / monthly basis to provide a mechanism to recover files in the event of deletion, system failure, or some kind of corruption. You provide disaster recovery facilities in the event of a massive system failure, usually due to a significant environmental failure (for example, one of your data centres is flooded or your primary storage array has fallen over and can’t get up). An archive is something that you need to keep for a defined period of time but is not something that you access frequently. It’s a bit like those old photos you keep in a shoe box under your bed (remember when photos were actual things we held in our hands?). You might access them from time to time but they’re kept in a different spot from the documents you access on a daily basis. It’s important not to confound these three activities, as the technical solutions that can provide these services often look very different.

 

What’s Really Important To the Business?

So now you understand the kind of activity you’re trying to conduct. At this point it’s a good idea to try and understand what data you’re trying to protect. Spoiler alert – you’ll need to talk to the business. Sure, they might come back to you and tell you that everything is important and everything needs to be kept forever. You can park that for the time being. More importantly, they’ll be able to tell you what is the mostest of the most important applications and data. and when those applications and data are accessed. This information is important when it comes to assessing the capability of the proposed data protection solution. Some customers I’ve consulted with only run business hours and don’t care if it takes a full weekend to do their backups. Other businesses run applications that can’t be down while backups are running, so they need to look at alternative approaches to data protection that can be done in a shorter / non-disruptive timeframe (and usually for a higher cost). The business can also guide you on what really keeps the company running. I’ve lost count of the times I’ve walked into a company to do some consulting and observed a lot of people in the IT department who didn’t understand what was important to the business or why the business had placed such an emphasis on one particular application. You don’t need to be a world-leading expert on Widget X, but if that’s the main product sold by your company, it’s a good idea to at least understand the basics and the systems that support those basics.

 

How Do You Categorise The Information And Articulate The Value?

Understanding the data you have to protect is important. But how do you understand it’s value? You need to talk to the business about it. Once you understand what’s important to them, you can start to articulate the various levels of “value” that can assign to data. And it might not just be application data that is valuable to your company. Obviously, the infrastructure platforms hosting that data are also important (and certainly worthy of attention). Some companies find it simpler to articulate the value of data in terms of their core business, or in terms of revenue generated, or sometimes in terms of whether someone will die if the system is down (this is more often a healthcare system consideration than something you might see in retail). It’s also important that, once you think you’ve identified the data and estimated its value, that you get someone important in the business to review these assumptions and sign off on them. I’ve worked in plenty of places where the business has one idea of what’s being done with the data and the IT department has a whole other idea of what’s going on. It’s also important to revisit these assumptions on a regular basis to ensure that your protection systems haven’t been left behind when the company “pivots”.

 

What About Dead Data?

Finally, consider data lifecycles. It’s okay to delete things. It’s sometimes even a good thing. Not just because it clears up space, or provides some level of catharsis, but there may be legislative considerations that require you to get rid of old records to reduce the company’s exposure to potential litigation. Not everything needs to be kept forever. If it does, you may not need to back it up every day. Keeping everything forever will eventually cost you a lot of money to support. Unfortunately it’s often at the point that people have been doing this for a few years that they realise this approach may not be the best one.

 

Conclusion

Data protection can be hard. Particularly if you haven’t had the opportunity to understand the business and consult with them regarding what’s important to them (and how you can help them, not just get in the way). Hopefully I’ve provided some useful pointers here that will get you on the right path. Obviously, everyone’s situation is different, and what might be important to you may not be important to someone else. Life is like that. The point of this is that there’s a whole lot of work that needs to happen before you get to the point of even thinking about what the solution will look like. It seems like a common sense notion, but it’s one that is often dismissed in the rush to get solutions delivered in the enterprise.

While I’m on my soapbox, Preston is a lot better at this stuff than I am, so you should check out his latest book on data protection – it’s a ripper.

And if you want to see jet-lagged me ramble on (albeit briefly) during my vBrownBag debut, here you go.

Rubrik – Cloud Data What?

I’ve done a few posts on Cohesity in the past, and I have some friends who work at Rubrik. So it seemed like a good idea to put up a short article on what Rubrik do. Thanks to Andrew Miller at Rubrik for helping out with the background info.

 

The Platform

It’s converged hardware and software (called “Briks” – there are different models but 2RU (4 nodes) are the most common).

[image via Rubrik’s website]

The Rubrik solution:

  • Is fundamentally built on a scale out architecture;
  • Provides a built-in backup application/catalogue with deduplication and compression;
  • Uses a custom file system, distributed task scheduler, distributed metadata, etc;
  • Delivers cloud native archiving, policy driven at the core around imperative vs. declarative;
  • Can leverage cloud native archive (with native hooks into AWS/Azure/etc.);
  • Has a custom VSS provider to help with STUN (super VMware friendly),
  • Provides a native API since day one (REST-based), and along with vSphere (VADP, CBT, NBDSSL), handles SQL and Linux natively (there’s apparently more to come on that front); and
  • There’s an edge appliance for ROBO, amongst other things.

 

Cloud Data Management

Rubrik position their solution as “Cloud Data Management”.

In a similar fashion to Cohesity, Rubrik are focused on a bunch of stuff, not just backup and recovery or copy data management. There’s a bunch of stuff you can do around archive and compliance, and Rubrik tell me the search capabilities are pretty good too.

It also works well with technologies such as VMware vSAN. Chris Wahl and Cormac Hogan wrote a whitepaper on the integration that you can get here (registration required).

 

Thoughts

As you can see from this post there’s a lot to look into with Rubrik (and Cohesity for that matter) and I’ve really only barely scratched the surface. The rising popularity of smarter secondary storage solutions such as these points to a desire in the marketplace to get sprawling data under control via policy rather than simple tiers of disk. This is a good thing. Add in the heavy focus on API-based control and I think we’re in for exciting times (or as exciting as this kind of stuff gets in any case). If you’re interested in some of what you can do with Rubrik there’s a playlist on YouTube with some demos that give a reasonable view of what you can do. I’m hoping to dig a little deeper into the Rubrik solution in the next little while, and I’m particularly interested to see what it can do from an archiving perspective, so stay tuned.

CrashPlan – Backup Adoption is the Killer App

I’ve been happily using CrashPlan for about a year now, after publicly breaking up with MozyHome, and sleeping around on Backblaze. I’ve signed up for another 3 years or so, so I’m fairly committed at this point. I’m a big fan of the Aussie DC presence and ability to use a local seed drive. The client itself is easy to use, and the pricing has been reasonable in my experience. But enough about my opinions.

I had a weird problem the other day on my main iMac where it looked like I had to re-seed all of my data. I’d had this problem before with MozyHome (link), but with a smaller set of data, so wasn’t too keen to re-upload over 900GB again.

CrashPlan

So I logged a case with support. A very nice gentleman named Daniel R got in contact with me and got me to send through some logs. I hadn’t realised I could clicky on the CrashPlan icon in the main window to open up a console. That’s kind of neat.

CP_window

I sent through the logs and Daniel got back in touch to have me modify my settings.xml file. No dice though. He then got back to me to advise that my archive was in a “maintenance queue” and he’d removed it from that queue and advised me to restart everything and see how it went. I’m fascinated by what the “maintenance queue” might be and how my archive ended up there.

Still no go, so he had me do a full uninstall (I think with prejudice) and re-install. The instructions for this process can be found here. For a complete uninstall, the following steps need to be done (on Mac OSX).

  1. Open the Finder
  2. Press Command-Shift-G and paste /Library/Application Support/CrashPlan/Uninstall.app into the dialog
  3. Double-click Uninstall
  4. Follow the prompts to complete the uninstall process
  5. Remove the following directory from your system:
  6. Custom installation (as user): ~/Library/Application Support/CrashPlan​

 

Once I’d re-installed everything, I could log back in with my normal credentials, and “adopt” the backup sitting in the Code42 DC that was assigned to my iMac. Simple as that. And then all I had to do was synchronize the changes. Seriously awesome, and so simple. No data loss, and smiles all round. And resolved in about 52 hours (including about 12 hours of them waiting for me to send logs through). And hence the title of the blog post. The ability to re-attach / adopt backups with new / replacement / freshly re-installed machines is a really cool feature that no doubt is saving people a fair bit of angst. It’s also not a feature you really think about until you actually need it.

So I’d like to publicly thank Daniel R at Code42 Support for his promptness and courtesy when dealing with me, as well as his ability to actually, well, resolve the issue.

Apple – I know too much about iPad recovery after iOS 8

So I now know too much about how to recover old files from iPad backups. I know this isn’t exactly my bread and butter, but I found the process fascinating, and thought it was worth documenting the process here. It all started when I upgraded my wife’s iPad 2 to iOS 8. Bad idea. Basically, it ran like rubbish and was pretty close to unusable. So I rolled it back, using the instructions here. Ok, so that’s cool, but it turns out I can’t restore the data from a backup because that was made with iOS 8 and wasn’t compatible with iOS 7.1.2. Okay, fine, it was probably time to clear out some apps, and all of the photos were saved on the desktop, so no big deal. Fast forward a few days, and we realise that all of her notes were on that device. Now for the fun bit. Note that I’m using a Mac. No idea what you need to do on a Windows machine, but I imagine it’s not too dissimilar.

Step 1. Recover the iPad backup from before the iOS upgrade using Time Machine. Note that you’ll need to be able to see hidden files in Finder, as the backup is stored under HOME/Library/Application Support/MobileSync/Backup and Time Machine uses Finder’s settings for file visibility. I used these instructions. Basically, fire up a terminal and type:

$ defaults write com.apple.finder AppleShowAllFiles TRUE
$ killall Finder

You’ll then see the files you need with Time Machine. When you’re finished, type:

$ defaults write com.apple.finder AppleShowAllFiles FALSE
$ killall Finder

Step 2. Now you can browse to HOME/Library/Application Support/MobileSync/Backup and recover your backup files. If you have more than one iDevice backed up, you might need to dig a bit through the files to recover the correct files. I used these instructions to locate the correct backup files. You’ll want to look for a file called “Info.plist”. In that file, you’ll see something like

<key>Device Name</key>
<string>My iPhone</string>

And from there you can restore the correct files. It will look something like this when recovered:

screen1

Step 3. Now you’ll want to go to the normal location of your iPad backups and rename your current backup to something else. Then copy the files that you recovered from Time Machine to this location.

screen2

Step 4. At this point, I followed these quite excellent instructions from Chris Taylor and used the pretty neat iPhone Backup Extractor to extract the files I needed. Once you’ve extracted the files, you’ll have something like this. Note the path of the files is iOS Files/Library/Notes.

screen3

Step 5. At this point, fire up MesaSQLite and open up the “notes.sqlite” file as per the instructions on Chris’s post. Fantastic, I’ve got access to the text from the notes. Except they have a bunch of html tags in them and are generally unformatted. Well, I’m pretty lazy, so I used the tool at Web 2.0 Generators to decode the html to formatted text for insertion into Notes.app files. And that’s it.

Conclusion. As it happens, I’ve now set this iPad up with iCloud synchronisation. *Theoretically* I won’t need to do this again. Nor should I have had to do it in the first place. But I’ve never come across an update that was quite so ugly on particular iDevices. Thanks to Apple for the learning opportunity.