Explaining and demonstrating the future of backup with Rubrik is great fun. I get to show people how their backup could be, how you can simplify, automate, take a first step to cloud and most importantly, save money by consolidating multiple technologies.
Most customers I speak with are heavily virtualized at 90-95%, but that remaining 5-10% often seems to have an inordinate amount of weight in the decision-making process of switching to a new solution. Sometimes this is because the remaining physical systems are critical to the business or just part of a checklist of requirements. If this 5-10% physical infrastructure is Windows, Linux, or running Oracle then great. I have connectors for Windows, Linux and RMAN integration for Oracle. But what if it’s a relic from a bygone era?
You would kill it in a heartbeat, but you can’t because the business needs it and redeveloping the app would take years which you don’t have. Recent examples I heard were Tru64 (I had to google this one), OpenVMS and Solaris 10 on SPARC. Backup solutions first created in 1989 are truly awful in a modern virtualized environment requiring automation, cloud, and the speed of flash, but the one thing they do have is broad support for everything under the sun. Yes, Rubrik is an agile shop adding big features every 3 months, but I’m pretty confident in saying a connector for an OS for which support ceased in 2012 is not going to happen.
So how can you modernize with Rubrik, but still backup the remaining legacy servers that Rubrik doesn’t support? Simple! Reduce the licensing of your existing backup solution right down to 5% to just do the old servers and use Rubrik as an NFS backup target for that small percentage. This way you still get a significant TCO saving by removing 95% your existing backup software licensing, plus the separate cost of deduplicated storage, and most importantly, you get to modernize the way you do backup while supporting everything you do today.
One possible response to this solution could be “I don’t want to use 2 different technologies to do backup” and I agree this isn’t always ideal, but anybody using backup software and deduplicated storage is already using 2 solutions. All I’m proposing is to use 2, but change the management to 95% one and 5% the other. Win win!
The feature which enables this is called “Managed Volumes” and this is the most underrated Rubrik feature in my opinion because of everything it can do. The primary use case of this feature is for multi-channel Oracle RMAN integration, but because a managed volume presents storage over NFS from Rubrik to be used as a disk-based backup target, it doesn’t have to be limited to that. That’s why we called the feature Managed Volumes and not just “Oracle Volumes”.
The most important thing is that it’s not just dumb network storage with deduplication, it’s a policy-driven NFS target under lock and key. It is only writable between begin and end snapshot commands and the rest of the time it is only readable (so you can restore at any point, but ransomware can’t infect it 24/7). Once the backup is written Rubrik then manages the retention of individual points in time (I.E all the files on the volume at that timestamp), replication of the data to another Rubrik cluster, archiving to cloud storage and finally, monitoring of successful backups! This last point for me is very important and is best explained by an example. If you create a managed volume and specify an SLA of backups every 24 hours, if a snapshot isn’t started then ended within that period then a new backup hasn’t taken place, and so Rubrik shows the Managed Volume as breaching the SLA.
Given this cool feature, there shouldn’t be any reason you can’t modernize your backup solution with Rubrik to benefit the majority of your environment, realize the huge cost savings, and not be held back that legacy 5-10% part of your infrastructure.
Watch out for part 2 of this blog post where I will take you through the setup and demo of how you can integrate Managed Volumes into your legacy backup solution. One way or another we can always accommodate those golden oldies still lurking around your datacenter.
Joshua
Hey. I agree, I should probably delete this post. They are working on fixing it to make it much better (i.e permanently writeable with snapshots).