This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
This tool creates a backup of all GAIA gateway configurations with one CLI command "ebackup":
- Only one CLI command "ebackup" - Backup of all Gaia gateway configurations (Check Point appliances, Open Server, SMB appliances 11xx, 14xx) - Migrate export on SMS - Migrate-server on MDS - Backup all files to one TGZ file - FTP upload support backup file - CP upload support for backup file via cprid_util
- MDS > All CMA's are read out and their gateways backuped. - SMS > All gateways are read out and backuped.
Note: - Tested with R80.10, R80.20 and R80.30. - If the tool is started on a MDS, a mdsstop and mdsstart is performed during the migrate_server export.
CLI Parameter
Syntax
Description
-s
The option -s performs a cpstop and cpstart when the migrate export tool is executed.
-v
The option -v shows the gateway OS, JHF, Kernel, Type of all gateways.
-l
The option -l shows all ebackup tgz files in /var/log/.
-d
The option -d delete all ebackup tgz files in /var/log/.
-no_migrate / -n
The option -no_migrate has the consequence that no migrate export is executed.
-port <sms port> / -p <sms port>
The option -port <sms port> add the management server port, if it's not running on port 443.
-ftpserver <ftp server ip> -ftpuser <username> -ftppw <password>
The ftp options allow to upload the tar file to a ftp server.
- cpupload <cp_system_ip>
The option -cpupload performs a backup upload to a other Check Point gateway or SMS via cprid_util.
Example
# ebackup -> Backup all GAIA configs from all gateways + migrate export with locale backup file (/var/log/[date]_ebackup.tgz) # ebackup -s -> Backup all GAIA configs from all gateway + migrate export with cpstop and cpstart for migrate export # ebackup -no_migrate -> Backup all GAIA configs from all gateway without migrate export # ebackup -ftpserver 1.1.1.1 -ftpuser username -ftppw test123 -> Backup all GAIA configs from all gateway + migrate export with ftp upload
# ebackup -cpupload 1.1.1.1 -> Backup all GAIA configs from all gateway + migrate export with cp upload via cprid_util
Install Tool
Use this auto installer script from "Spoiler" on the SMS or MDS as CLI command in expert mode:
If an FTP upload is too insecure for you, you can also transfer the backup file to another Check Point system with the option -cpupload via cprid_util.
- Add parameter -s for cpstop/cpstart - Add ftpserver/ ftpuser and ftppw parameters for ftp upload.
0.1 03-15-2020 - oneliner to show backup clish configs 0.6 03-23-2020 - GA version ebackup 0.7 03-25-2020 - add parameter -s for cpstop/cpstart 0.8 03-26-2020 - add parameter -no_migrate (no migrate export) 0.9 03-26-2020 - bug fixed (special thanks to Paul_Gademsky) 1.0 03-27-2020 - bug fixed (SMS and MDS) 1.1 03-30-2020 - add option -port 1.2 03-30-2020 - bug fixed 1.3 03-31-2020 - ftp upload function (-ftpserver, -ftpuser, -ftppw)
2.0 04-04-2020 - MDS support 2.1 04-06-2020 - bug fixed 2.2 04-07-2020 - add option -v 2.3 04-09-2020 - add option -cpupload (upload tgz file to a other Check Point gateway or SMS)
3.0 06-20-2023 - Support for R81.20
➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
asy Backup Tool
Features
This tool creates a backup of all GAIA gateway configurations with one CLI command "ebackup":
- Only one CLI command "ebackup" - Backup of all Gaia gateway configurations (Check Point appliances, Open Server, SMB appliances 11xx, 14xx) - Migrate export on SMS - Migrate-server on MDS - Backup all files to one TGZ file - FTP upload support backup file - CP upload support for backup file via cprid_util
Disclaimer: Check Point does not provide maintenance services or technical or customer support for third party content provided on this Site, including in CheckMates Toolbox. See also our Third Party Software Disclaimer.
Does EasyBackup support R81.10? We recently upgraded and it no longer sees our Gateways. It found an older gateway in our environment but I had to change the gateway detection to .objects[] | select(.type | contains("Member","cluster-member")) in order to get it to see our R81.10 gateways.
Does EasyBackup support R81.10? We recently upgraded and it no longer sees our Gateways. It found an older gateway in our environment but I had to change the gateway detection to .objects[] | select(.type | contains("Member","cluster-member")) in order to get it to see our R81.10 gateways.
Very nice tool @HeikoAnkenbrand ! Thanks for sharing it with the community.
Note that starting from R81.20 and a certain JHF in R81.10, there is no longer a need to restart the MDS or SMS services when performing export. The admins can continue to work seamlessly while the exports are running.
That should make the tool easier to use without worry from an automated job.
Perhaps you should update that in the headline documentation.
Very nice tool
@HeikoAnkenbrand ! Thanks for sharing it with the community.
Note that starting from R81.20 and a certain JHF in R81.10, there is no longer a need to restart the MDS or SMS services when performing export. The admins can continue to work seamlessly while the exports are running.
That should make the tool easier to use without worry from an automated job.
Perhaps you should update that in the headline documentation.
Thanks @Tomer_Noy. This may explain the issue I am having. When I run ebackup -s, the export fails at the pre verification stage and then my API and CPM services fail to restart until a reboot is done. My backup file is 4k in size, which is the GAiA configs.
Thanks
@Tomer_Noy. This may explain the issue I am having. When I run ebackup -s, the export fails at the pre verification stage and then my API and CPM services fail to restart until a reboot is done. My backup file is 4k in size, which is the GAiA configs.
As Tomer noted, you no longer need to stop and start the cp services as of R81.20. In addition "migrate" is being depreciated and has been replaced with migrate_server. I ended up modifying Heiko's script a little to fit my SMS and it's been working perfectly. I don't have a MDS, so I didn't touch that part of the script. Below are my edits where I changed the migrate line to use migrate_server and its needed switches. I also commented out the cpstop and cpstart lines.
############## SMS ############################
# SMS migrate export
if [ $serv_value -eq 0 ]; then
if [ $MIGRATE == "1" ] ; then
REMOTE_FILE="$NOW-SMS-Migrate-Export";
REMOTE_DATEI="$FILE_PATH/$REMOTE_FILE";
echo;echo "Migrate Export SMS:";echo;
if [ $SHOW_SUM == "1" ] ;
then
# cpstop > /dev/null 2>&1;
echo " NO - cpstop";
fi
REMOTE_DATEI_CHK="$REMOTE_DATEI.tgz";
/opt/CPsuite-R81.20/fw1/scripts/migrate_server export -v $RVER -skip_upgrade_tools_check -n $REMOTE_DATEI 2>&1> \tmp\ebackup_migrate ;
if [ ! -f $REMOTE_DATEI_CHK ]; then
echo " Failed - SMS migrate export";
else
echo " OK - SMS migrate export";
fi
if [ $SHOW_SUM == "1" ] ;
then
# cpstart > /dev/null 2>&1;
echo " NO - cpstart";
fi
fi
fi
As Tomer noted, you no longer need to stop and start the cp services as of R81.20. In addition "migrate" is being depreciated and has been replaced with migrate_server. I ended up modifying Heiko's script a little to fit my SMS and it's been working perfectly. I don't have a MDS, so I didn't touch that part of the script. Below are my edits where I changed the migrate line to use migrate_server and its needed switches. I also commented out the cpstop and cpstart lines.
We have configured new MGMT server on AWS cloud with vR81.10 & applied your ebackup script v3.0 on it.
We have configured cronjob to create ebackup on every monday & transfer that backup to AWS S3 bucket. EBackup is working as expected but it is not getting stored on S3 bucket through cronjob. Kindly help.
Regards,
Sunil Redekar
Hello Heiko,
Thank You for your ebackup tool script.
We have configured new MGMT server on AWS cloud with vR81.10 & applied your ebackup script v3.0 on it.
We have configured cronjob to create ebackup on every monday & transfer that backup to AWS S3 bucket. EBackup is working as expected but it is not getting stored on S3 bucket through cronjob. Kindly help.
thank you for providing this tool. During our migration to R82, I noticed an issue in the script. On line 17, the output was not redirected to /dev/null as intended. Instead, /dev/null gets deleted, which caused problems on our system.
Could you please review and correct this in the next version?
Best regards, Maurice
Hello Heiko,
thank you for providing this tool. During our migration to R82, I noticed an issue in the script. On line 17, the output was not redirected to /dev/null as intended. Instead, /dev/null gets deleted, which caused problems on our system.
Could you please review and correct this in the next version?