I have a Actian (Pervasive) DB instance that we are backing up on a server. The vendor is telling us that Actian/PSQL does not support incremental or differential backups. I read some Actian docs and they are ambiguous at best and contradictory at worst but do seem to indicate that only "full" backups are recommended.
They also indicate a "backup agent" that works with many recovery products and mentions other features that would support that it does work.
If you look at the PSQL logs it shows the the DB going into freeze/thaw and a VSS writer running. We have not purchased an add-on "backup agent" from Actian.
I have a hard time believing this isn't really working. I have restored data from RR many times including full volumes but I guess some data could be corrupted. How would you ever know? How do I test this? Does anyone have any first hand experience with Actian PSQL?
Although I do not have Actian (Pervasive) experience, the documentation that you refer to seems to support the hypothesis that backups can be performed properly using Rapid Recovery.
The incremental/differential backups the vendor is referring to are most likely related to file level backup. The Rapid Recovery backups are volume/block level thus they should not be an issue.
The backup agent seems to be compatible with file level backup applications as well so it is out of scope.
I can see the following possible issues, though:
1. The documentation states that the PSQL VSS writer quesce all databases at the same time, no matter the volume on which they are located. Since Rapid Recovery is not PSQL aware, it means that all volumes of the protected server must be in the same protection group. (I.E. you should not backup volumes C: and D: hourly and volume E: every two hours; all volumes should be snapped at the same time).
2. We have seen some offset irregularities when snapping some third party applications. We have no way of knowing if Actian exhibits this kind of behavior which would result in possible crash consistent backups which, in turn, depending of a large number of factors, may or may not be a serious issue.
There are some unsupported empiric ways to figure out if your particular configuration is 'elastic' enough to support such a situation.
During my system admin years, I had to use the snapshot capabilities of my filers for backing up some VMs running non standard database applications (i.e. old FoxPro).
Since they were 'built in house applications', I was able to add a table to which I was writing some data right before taking a snap. To make sure that I had a chance to recover I was attempting to mount the specific databases every week and randomly attempting to mount and browse three consecutive snaps. If two out of three were OK (and my witness test record was present as well) I was OK with the outcome. To mention that even under load and without any VSS support, more often than not I was able to perform the test without any failures.
Please note that I do not endorse such procedures, just sharing old (but by no means tall) tales :)
I'm curious as to what you mean by-
"The backup agent seems to be compatible with file level backup applications as well so it is out of scope"
If you mean it seems to contradict itself then I agree.
The standby VM we make for this server we have used in production during downtime and it has always worked. We have noticed no odd behavior.
I tired to get a support ticket in with Actian but all their Web forms do not seem to be working. All in all I am pretty unimpressed with both our application vendor and Actian DB. I can't imagine a modern DB that requires manual intervention to get a working backup of. Also if snapshots "corrupt" the DB wouldn't that eliminate replication of VM's and pretty much all VM backup titles?