cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2111
Views
0
Helpful
3
Replies

Backup/restore the NGIPSv host

brianjp2472
Level 1
Level 1

Using the Firepower/FireSIGHT management center 6.0.0.1 in a virtualized implementation and hashing out a backup strategy. We have the Defense Center covered, and now trying to determine how best to back up the NGIPSv. The docs say there is no supported method or way to backup and restore the config:

• You cannot create or restore backup files for NGIPSv, Firepower Threat Defense physical or virtual managed devices or ASA FirePOWER modules. To back up event data, perform a backup of the managing Firepower Management Center

So that leaves us with snapshots as really the only alternative to do this. However, I am left wondering if the NGIPSv needs to be backed up at all? I can't find any information out there as to if the NGIPSv holds any config that would need to be snapped/backed up? Then I find this:

  • Restoring a virtual machine with snapshot is not supported.

Here:

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/quick_start/ngips_virtual/NGIPSv-quick/intro-ngipsv.html

So, again,

1. Has anyone done snapshots of the NGIPSv and have you encountered any issues?

2. More importantly, does the NGIPSv need to be backed up at all?

1 Accepted Solution

Accepted Solutions

Given that licensing is now on the DC, I think it is just a preference. If you redeploy, you might have to delete the old sensor and add the new after registering the redeployed sensor to the DC.  If you use a snapshot, that is already done.  Also, only the default policy will get deployed to the new sensor. If you are using the sensor with a customized policy, that would have to be pushed back to the sensor... the exception being if you have scheduled automatic policy pushes.

View solution in original post

3 Replies 3

djthomason
Level 1
Level 1

I would think a snapshot completed after any upgrade would be sufficient. As all event data is sent to the FSMC (Defense Center) as long as you have a snapshot, all you would need to do is to revert to the snapshot and push the latest policy to be back up to date.

Other options would include using something like VEEAM if you absolutely had to have the latest version with all the policy pushes.

Having said all that, I'm not sure what you will get if you activated a snapshot that was a minor version behind the version that died. In that case, I would think you might have to manually push the upgrade as the database may have recorded that sensor as already being upgraded.

So what would be the benefit of having snapshots for the NGIPSv? You mentioned that it would be fully up to date and all that would be needed is a policy push. But it seems that when you attach a new NGIPSv to the DC it will automatically push out policy to it. At least that's what I saw in my observations. So does it simply become a preference of reverting a snap as opposed to re-deploying the VM?

Given that licensing is now on the DC, I think it is just a preference. If you redeploy, you might have to delete the old sensor and add the new after registering the redeployed sensor to the DC.  If you use a snapshot, that is already done.  Also, only the default policy will get deployed to the new sensor. If you are using the sensor with a customized policy, that would have to be pushed back to the sensor... the exception being if you have scheduled automatic policy pushes.

Review Cisco Networking for a $25 gift card