What do the rest of you do for backups in clustered environments? You can backup the cluster level configuration very easily but if you have a failure you need a machine level backup. Do you take the time to remove the machines from the cluster to get a good machine level backup?
Anyone know what the best practice is for this or what is your procedure?
i think the goal of a "cluster" concept is to have a no-backups-necessary kind of virtual configuration floating around in the ether. of course if you are making lots of machine level changes, then it's not practical to forgo individual backups.
temporarily removing machines and rejoining them shouldn't be too difficult, although you would want to probably suspend listeners and bring it offline for a few minutes:
1. temporarily remove the machine: > clusterconfig removemachine
2. save configs via either email or local storage: > saveconfig yes > mailconfig yes
important to note is that using 'mailconfig' or 'saveconfig' on a clustered box does give you everything you need, you just can't manually import it again as-is with 'loadconfig'. maybe it'd be easier to just do mailconfig from all appliances and parse out the machine level stuff in the XML config files???
i'd like to hear any other suggestions on how to pull this stuff out though! i'm sure there are some good ones!
Most of the times, a disaster recovery is needed due to a human error. The way Ironport handles the cluster configurations does not meet that fact at all. The Ironport way of clustering is a perfect solution for host outages, but gives no remedy against a (stupid) mistake of a human.
At this moment we take a daily copy of the configuration with a Unix shell script that triggers the Ironport to mail the configuration.
Another improvement plan I have is based on syslogNG functionality. We are forwarding our Ironport logs to syslogNG and that brings in some interesting features. One idea that's in my mind is to abuse syslogNG to trigger the "mail-me-the-config" shell script every time someone is "committing" a change. This way you will get a good repository of Ironport config files. This allows you to investigate when a certain change was made and gives you a (poor-mans) way of rolling back.
As soon as I have finished the stuff I might publish it (if someone is interested). The most optimal would be that Ironport would implement a way of reverting to previous policy versions.
We have had the problem at a customers site, that the A/C was failing for the whole datacenter and due to a long chain of events both ironports on site were rebootet several times, but power failures occured during bootup. In the morning both cluster devices had a broken filesystem...
There is an open feature request with ironport to allow cluster backup. Just open a ticket as feature request to make the topic more important.
The lack of a working loadconfig in clusters has been much complained about to IronPort for years.
In addition to the issue of recovery from a catastrophic cluster failure it makes change control procedures messier to deal with because one is unable to quickly revert to a known good saved configuration.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...