My issue echo's what Dave Hoggan is running into in that thread, and the response he, and myself, have largely gotten is not one that I consider to be acceptable considering the caliber of the product we're working with. There doesn't appear to be a good way to quickly and efficiently run a complete backup/restore of a single domain in the event of a catastrophic failure in R80.10, and my SE is now echoing these sentiments as well. In terms of Checkpoint supported backup methods, it's either "mds_backup", and pull it all off, or nothing, restoration procedure is the same. Everything or nothing. If you question why better backup functionality doesn't exist, you'll get the "just don't break our product and you won't need those backups" response, which simply isn't acceptable. We need to be able to recover from any unforeseen issue we may have, be it user induced or otherwise, and being able to efficiently schedule and take complete, separate domain level backups for both logging and policy/objects is a very basic part of that disaster recovery procedure.
The feature you're mentioning there is nice if you need to roll back a rule, but it is not a "disaster recovery" solution, as we found out first hand. My solution of a Veeam snapshot did work, but it's not a supported method, and I suspect that I may have caused some serious issues in MDS as a result of slapping a copy of the MDS VM over top the existing live MDS VM, considering everything is now database driven.
I've been told that "MDS_Backup" is the only real Checkpoint supported backup feature I can to implement to ensure our policy/logging backups are taking place, but for several reasons I don't like how this tool requires us to operate.
In terms of functionality of the solution, my major issue with the MDS_Backup feature is that I'll effectively need to shut my entire MDS down to pull supported backups, and if you're including logs in that backup, it will take hours to backup a series of domains and logs. Considering we require hourly diffs of all this data, this simply isn't an acceptable option, which is forcing us to move to an MLM so we can separate our logs from our policy.
We currently need to have separate backup/restoration/retention plans for:
- Daily full backups for everything that would be required to recover from a disaster event at the MDS level.
- Daily full backups, with hourly diffs for everything that would be required to recover from a disaster event at the domain level.
- Daily full backups, with hourly diffs on individual domain logs.
- The ability to restore a domain, or domain logs, without affecting any other domain in MDS.
How would it look if we billed four hours of work for modifying policy for one customer, then had all that work reverted because we had to run an mds_backup and revert to the midnight backup due to issues with a completely different domain? Not to mention that if we were to currently do that we would lose all the logging data from midnight to the point of the restore, unless of course we paid for an MLM, which at this point we are in the process of vetting out.
During our very informative R80.10 training course this last week we learned that it is possible to export logs off MDS prior to a restore to prevent data loss, but it's at best a "hack it together" method to something that's important enough that it should be baked into the product.
Apologies for the length of what has ultimately turned into a rant at this point, but progromatically exporting/importing every aspect of individual domains should be an easily schedulable feature, ideally through the GUI, exporting/importing logs for an individual domain should be a separate schedulable feature, exporting the entire shebang should be a third schedulable feature, again ideally all done through the GUI.
