- Community Home
- >
- Storage
- >
- HPE Nimble Storage
- >
- Array Performance and Data Protection
- >
- Re: Snapshot strategies with non-VSS-aware softwar...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2013 11:22 AM
тАО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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-12-2013 11:17 AM
тАО10-12-2013 11:17 AM
SolutionHi there,
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.
twitter: @nick_dyer_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-12-2013 07:24 PM
тАО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.