Actifio’s Mike Salins is back for another in-depth data focused review covering revolutionary Oracle data capture.
Today we’re going to be talking about Oracle RMAN, backups, different methodologies for backups, some of the pros and cons of each and we’re going to dive into how Actifio has implemented Oracle backups and recovery. There are really three approaches for Oracle backups. You have your traditional approach your full and incremental backup. You got a storage snapshot approach then you have the incremental merge method which is often called incremental forever. Traditional method, fulls and incrementals really nothing unexpected here. You get a full copy of an Oracle database, you usually use Oracle RMAN to get it that full copy is a standalone copy. There is everything that you need in there including some archived logs that are generated during the full copy. If you want to use this full copy to create it, you’re copying from the Oracle server to whatever backup target it is. This might be disk attached to your Oracle server. It might be a backup server.
Full Video:
Free Oracle Backup and Recovery Vendor Checklist
Download Now
In order to do the restore you reverse the process the data gets copied back. To help the process out a little bit Oracle has incrementals. You might create an Oracle incremental one or two or three or more in between false. And you would do that of course to minimize your backup window and Oracle incremental is fast and efficient since Oracle 10, it uses change block tracking so that it doesn’t have to go and look for all the changes it just knows what the changes are.
The downside of course to this is while it helps your backup window it hurts your recovery times, because now your recoveries don’t just have to copy a full copy they also then have to roll in all of the incrementals that have been taken since that full copy was created. That approach has been around for a long time, it’s very well proven, it’s actually very well proven to be not effective with really large databases, which is probably why you’re watching this in the first place. So that brings you to option number two, storage array snapshots.
The pros of storage array snapshots are they’re very fast, right taking a backup is as simple as taking your group of disks that are sitting underneath your Oracle database and taking a snap. Put the database in hot backup mode first, take the snap, take it out of hot backup mode and do a short archived log backup so that you get consistency, contrary to popular belief putting a database in the hot backup mode doesn’t actually prevent rights from taking place. The data will still be inconsistent, it’s just inconsistent after a known point in time therefore you can use the archived logs to make it consistent.
Benefit there is of course the speed. The downside on the other hand is it’s now very linked to your storage design so your LUN layout underneath your database. And if you add a disk well you need to be sure that that’s included now in here, maybe either through some automation or whoever set it up. Accessing the data is of course very fast, but usually it takes a storage type person because you’ve got a disk copy and now you need to present that someplace to use it, you have to turn that into a database bring it online. Usually DBA gets involved with that.
You also now have risk because this is a single point of failure. It’s your production storage array, and while we all like to think production storage arrays are never going to go down the reality is we’ve all probably experienced one going down at some points in our career. And then finally you have cost on this because retention on here is going to be relatively short due to the fact this tends to be expensive storage. So your short retention means you need to make another copy. So not only are you consuming some space in your storage array, but now you’re going to be making probably false from here maybe everyday to get a longer-term retention someplace else. It’s not like incrementals it’s a step towards better backups. This does a much better step towards restores of recent data, it doesn’t fully address the cost aspect of things just yet.
And that brings us to incremental merge. Incremental merge varies a lot by customer implementation by vendor implementation. An incremental merge is basically a feature that Oracle introduced a while back where they say instead of making a full copy make something called an image copy. And this image copy is a runnable copy of your database. It’s not in a backup format like a backup, like a full backup is, it’s that runnable copy. And this gives you the ability now to take an incremental and roll it in to that image copy. Now why would you want to do that? Well, when this was first introduced Oracle had published a paper that said if you want to have fast incremental forever backups, you can simply do an image copy followed by a series of incrementals and as many incrementals as you want that’s your retention period. If you say you wanted four, five recovery points you’d have your full and four incrementals.
When you take your sixth incremental you roll in the first one effectively bringing your full copy forward one day. When you take your seventh you roll in your second again bringing it forward. So you have this rolling rotation of retained data. It’s very similar to what you can do with the snapshot except it is now somewhere else. And that means you eliminate the single point of failure, you may have in a lower cost storage, so you might be reducing that storage cost a bit. It still has some downsides of course. Some of the cons on this approach are, you’re still leveraging your Oracle server to do some of that work. It’s running the incremental. It’s doing the merge whereas the snapshot based approach has almost no burden, no load on that production server.
There is a little bit of a trade-off there. This does tend to scale a little bit better, but it has some hang-ups due to this retention approach, and in particular the issue is recovery time, because if you want to get your most recent point in time, which is typically what you want most often you now have to roll forward every incremental that you’ve got which makes it actually slightly worse than recovering from your full when it comes to incremental rolling time. Now the benefit of course is you’re starting with something that’s in a runnable format. You don’t have to copy it somewhere to use it, you can actually present it and use it from your backup medium. So that introduces us to some of the topics there.
Let’s talk about Actifio specifically now. When it comes to Actifio what we said was we said, we want to make sure that that solution we provide is fully automated, fully reliable, doesn’t rely on any reverse engineering, for example of data structures inside the Oracle database. We wanted to leverage this incremental merge process, but we wanted to do it in a way that eliminates some of the downsides even here. And so what we did was we said we’re going to have an Actifio appliance. This Actifio appliance is going to present storage to the Oracle server. It of course is backed by some backup storage. Now that backup storage can be whatever tier you like sort of like the incremental merge approach here. And what we’ll do is we’ll do the initial image copy, create our full copy here. Now we have a full. Not at the end of that we take a snapshot and call that day number one. Every time we run our database backup after that, we simply do an incremental and a merge into the copy that’s coming from Actifio that updates our top copy here to be the most recent point in time and then we take another snapshot of it.
Rather than roll in of the incrementals at the time of recovery we’re effectively rolling in the incrementals at the time of backup. And what this allows us to then do is say any point in time that you want you can simply select it, present it back to an Oracle server and bring that database online right away. We also implemented in such a way so that we can integrate with Oracle ASM. And when we do that, what we do is we say ASM format here means put the data in ASM format here. It’s not in the backup format its right in the ASM. That gives us a few benefits when it comes down the road to recovery as we can take about in another video. But more importantly is we don’t have to have this in ASM format if this is and we don’t have to have this in file system format if this is, we can actually switch. So a database in ASM format in production if you have a test environment then maybe you want to run file system on, you can have Actifio store this in file system format here.
And then when you go to use it elsewhere it can be in that file system format. We can also do the vice versa as long as ASM binaries are installed here if your database is in file system format during the image copy and the incrementals and merge we can be storing it in ASM format to enable you to use at that – in that ASM format. Fully compatible of course with Oracle RAC both on recoveries and on backups. But finally and probably most importantly here is when it comes to retention all of the different options here have kind of fallen down a little bit. And what we’ve done is we’ve implemented so that we generate a list of deltas between each of our snapshots here and then we allow you to send them somewhere else for long-term storage. So this might be cloud, it might be de-duplicated disk, we offer many choices, but even if this is something like Amazon S3 in the cloud, you can say I want to keep my longer-term copies out here and only keep maybe a week’s worth here or months worth here yet we still allow you to pick this point in time for example and present it right back to a server and bring that database online again without first having to copy it to your local copy and then back. This can even be an internet connection bringing that database online.
So lots of flexibility and functionality around long-term backups, long-term storage and efficiency is to only be sending deltas incremental forever even when we’re sending data out to the cloud or into that dedupe.
A few final thoughts. This solution was developed in Actifio by DBAs, for DBAs. We have a number of DBAs on staff who lived especially in the financial industry, lived through the pain of all the different methods that were out there at the time and really wanted to do something better and this is ultimately what the solution has come up to be. We also wanted to make sure that everyone knows the one big mystery about incremental forever tends to be data integrity.
Everyone talks about data integrity. Everyone says RMAN takes care of that for you. It does all sorts of checksumming and it does to a point. But if you have a block of storage that since the date it was created has never changed, it’s never backed up again. You still want to find out and validate that it’s correct, that it’s not been lost or corrupted. Actifio has a patented fingerprinting technology that we have implemented so that every image that we take, every backup image we read from the production copy a selected set of blocks different every time, generate a unique fingerprint based on those blocks. And then on the Actifio side we read the same blocks after we have copied them generate that fingerprint and we actually store the fingerprint along with each one of these images on separate disks in a separate place, but associated with each image.
And then every time you access the image for any reason for recoveries, for a test environment, for a future backup we recalculate by rereading all those appropriate blocks, rechecking the fingerprints still matches what the original one did. So that you can have that confidence to know that despite the block had never being written again since the original time it’s still valid and available for you.