In R80.10 is cpstop before 'migrate export -n' still recommended?

[phlrnnr]

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.

[Jerry]

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

[_Val_]

correct, cpstop is not performed when doing migrate export. 

[_Val_ · Accepted solution]

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. 

[phlrnnr]

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!

[_Val_]

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.

[phlrnnr]

Should I only care about  the 'connection-mode' parameter?  Or should I also care if any sessions have 'locks' or 'changes'?

[_Val_]

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.