All of these applications have a method for delivering a static copy of the data but you need to evaluate if this is required. Considerations are (a) memory dumps to store what hasn't been written to disk, (b) transaction logs that allow you to replace transactions from a time period and (c) general ability to sync data to disk, at which point a storage solution snapshot can take over.
As well as utilizing the application, I hit on the key functionality of storage solutions and created a business continuity methodology, reusing older storage devices. I worked my way from disk to RAM to understand the application and then flipped that to determine the right approach. The disk has a copy of the data but there were items in memory and it had an option to maintain a transaction log. A large DB takes a big amount of time to back up so I needed a large window for a full backup. This also means I can't do a full backup during most of the business week.
Digging in the configuration files and the documentation, I found a few settings that are of value in this situation. First, I could send a command that forces all the writes in memory to be put into the DB stored on disk. Second, I found the flag that turns on transaction logging and specifications necessary to construct this. These were the two points I needed to start developing my plan.
Recovery time... I can replace a full day in about 2 hours, thus I could recover nearly two weeks in one day if I had to.
The plan of attack:
- Do a full back-up via application on Sunday when activity is low
- Each night do a backup of the transaction logs so we can 'replay the day'
- Take both of these and store on a separate NAS
