- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
I'm running an R80.10 version of Security Managment Server. With the new database format, etc. is it still recommended to do a cpstop before running 'migrate export -n <path>' ?
In automating the migrate export / move file off of the server, I'd prefer not to have to completely stop and restart the check point services if it isn't necessary.
Hi Philip,
the recommendation comes from the fact you want to make sure nobody is doing any changes during the backup or migrate procedure. The most efficient way to do that is to turn off management.
This is not a requirement and just a recommendation, as you mentioned. WIth R80.X you can script your procedure so you query open admin session with MGMT API before going into the next step.
afaik migrate_export does the cpstop anyway but don't worry, moving files on cpd running wouldn't affect your "extract". that's what I've experienced few weeks ago in production env. on R80.10 take 112
correct, cpstop is not performed when doing migrate export.
Hi Philip,
the recommendation comes from the fact you want to make sure nobody is doing any changes during the backup or migrate procedure. The most efficient way to do that is to turn off management.
This is not a requirement and just a recommendation, as you mentioned. WIth R80.X you can script your procedure so you query open admin session with MGMT API before going into the next step.
Thanks a lot for the suggestions. A couple follow ups:
1. If there are open sessions / users making changes, could that cause the exported database to be corrupt? Or would the export just not contain their changes?
2. If I were to use the MGMT API to do this query, I'm guessing I'd have to call 'show-sessions' to get all object UIDs for existing sessions. Then I'd have to loop through each of those UIDs using show-session. What parameter(s) in the response of show-session should I check specifically to see if the session is open?
3. If I detect one of these open sessions, is it better for me to abort the migrate export? Or to do cpstop and kick them out of their sessions?
Thanks for your help!
Q: If there are open sessions / users making changes, could that cause the exported database to be corrupt? Or would the export just not contain their changes?
A: Yes, there is a risk of inconsistency when someone is performing a write operation while you are exporting DB
Q: If I were to use the MGMT API to do this query, I'm guessing I'd have to call 'show-sessions' to get all object UIDs for existing sessions. Then I'd have to loop through each of those UIDs using show-session. What parameter(s) in the response of show-session should I check specifically to see if the session is open?
A: You only need to see if there are no session in any of the write and/or locking mode
Q: If I detect one of these open sessions, is it better for me to abort the migrate export? Or to do cpstop and kick them out of their sessions?
A: You can abort, of course. Alternatively, you could pause migrate operation, query users by name and aske them to disengage. Kicking out is also an option, less graceful and a bit more risky, especially for sessions in write mode.
Should I only care about the 'connection-mode' parameter? Or should I also care if any sessions have 'locks' or 'changes'?
Let me rephrase my answer on the second question. If you can make sure that there are no write and/or lock sessions, you are good to go.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY