- Integrated Systems
- About Us
- Integrated Systems
- About Us
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
10-10-2013 11:22 AM
We're considering Nimble storage as part of our budget process, and I'm doing my due diligence getting up to speed. I'd like to validate my understanding of things and get clarification on an item --
One of our major systems runs on a database (called Progress) that is, to the best of my knowledge, not tied in with VSS the way Exchange or MS SQL are. We've always had to jump through hoops with our non-snapshot backup methods to prevent data corruption or issues with data not being backed up. Since's Nimble's snapshot-based data protection capability would be a cornerstone of our investment decision, I'm trying to determine if that selling point even applies to our circumstance.
My question is, simply, how would I approach a new Nimble setup for a database server like this? It's nearly all small transactions and not terribly high performance, but there is a steady stream of reads and writes throughout the day. Currently the database just sits on a VMDK file on its own chunk of SAN disk space. If we're not going to be able to leverage Nimble's snapshots for this server then we'll need to evaluate things just based on the performance increase and other benefits.
If I'm completely off on the wrong direction here, I'd appreciate some guidance. Our reseller has been helpful but my knowledge isn't really up to speed to where I feel like I'm asking intelligent questions, and this is something I need i wrap my brain around.
Solved! Go to Solution.
10-12-2013 11:17 AMSolution
what is the OS that the progress database runs on at the moment? Although we have specific integration pieces using VSS for Microsoft SQL & Exchange Server, we also have the ability to quiesce and snapshot virtual machines through VMware and the VMtool Snapshot integration in vCenter. This may give you the ability to pause and snapshot your virtual machine VMDK file systems as part of a schedule.
Even though the majority of our customers with databases use the application integration of our snapshots to pause and quiesce the environment, it's best to keep that to a maximum of perhaps every 30mins or 1hour time frames, as it takes a few seconds to pause and un-pause your database. For more granular snapshot recovery points you can then run crash-consistent snapshots alongside the 30mins/hourly snaps. OR it could be that crash-consistent snapshots are good enough for your database to recover from (Oracle databases are perfectly fine recovering from these snapshots, for example).
Hope the above helps.
10-12-2013 07:24 PM
Re: Snapshot strategies with non-VSS-aware software
Thanks Nick, that explanation makes sense. The Progress database runs on Server 2008 R2, and is around 16GB in size. The actual files that I see change throughout the day (extents) are 512MB each.
It sounds like this might be a "try it and see" for our application, which I'm okay with. We're used to making tradeoff decisions that go along with the software we use... Our current approach is 1 application-based "live copy" type backup per day, because it grinds the response time to a halt for everyone using the system for 45-60 seconds when we run it during business hours. So we'll put that feature in the "maybe, but certainly better than now" column for now. I'd want to do some serious testing of the crash-consistent snapshots in our environment before going that route, but it may be as simple as you say.
Thanks for the detailed info, it helps a lot.