Restoring to a Reporting Appliance
You can choose to keep a separate CS-MARS appliance for reporting on old, archived data. Although obvious benefits to this exist, you should also be aware of some pretty rigid limitations.
The first limitation to address was discussed in the previous section. When using the pnrestore utility to restore the configuration and events to a different MARS appliance, the new appliance must be the same model or bigger. For example, you cannot restore data that was archived from a MARS-200 to a MARS-50. However, you can restore data that was archived from a MARS-50 to a MARS-200, MARS-100, MARS-100e, or a MARS-50. This means that you might spend more money on a reporting appliance than you might like. On the other hand, a reporting appliance can always be pressed into duty as a primary MARS appliance in case of hardware or other catastrophic failure.
The second limitation exists in MARS 4.2 software and earlier releases. In these releases, the pnrestore utility does not allow for specifying an ending date and time when selecting the time range of events to restore. This means that importing a specific range of events requires additional work on the archive server before data can be restored.
As long as you keep these two limitations in mind, a second MARS appliance can be useful for running reports on data that no longer resides on your primary appliance.
For example, assume that you're saving one year of events on your archive server. Because of the rate of events that your primary MARS appliance receives, however, you're able to store only eight months of event data on your MARS-100.
An auditor has asked you to provide a report showing all configuration changes that were performed on your perimeter firewall during a 30-day period one year ago. Your perimeter firewall is a Cisco ASA-5540, and it's already configured to send logs through syslog to MARS. This report is simple to define, because a report is already defined that can be used as a template. However, on the production MARS appliance, it reports only on the data it has available on its local hard drives.
Figure 7-2 shows a built-in report that can be modified to suit your needs. This report displays network device configuration changes over a short period of time. This can easily be modified to report over a longer period of time and can be filtered to display only changes from a single device.
You have a second MARS-100 that's dedicated for reporting and other development tasks. Using the pnrestore utility with MARS 4.2.1, you can specify the starting date and time, but not the ending date and time.
Figure 7-2 CS-MARS Firewall Configuration Changes Report
Figure 7-2 CS-MARS Firewall Configuration Changes Report
To restore the necessary data to the reporting appliance, follow these steps:
Step 1 Calculate whether your reporting appliance can store the number of events you expect to restore. In this case, because your production MARS can maintain about eight months of events, you should experience no problems when restoring a single month or so to your reporting appliance.
Step 2 Log in to your archive server and copy only the files you'll need to a separate directory.
Step 3 Bootstrap the reporting MARS appliance to the correct version of software and appropriate network configuration. This is the same process you follow when initially configuring a MARS appliance. This process consists of logging in with your web browser and entering the initial IP address, passwords, and so on.
Step 4 Use the pnrestore utility to restore these events to the reporting appliance. The following example is similar to what you would use if your NFS archive server is 10.0.0.120 and you want data restored from June 4, 2006, and later:
pnrestore -m 1 -r 1 -p 10.0.0.120/nfs/report -t 06/04/06:0
If you look at the archive server, you'll see that the directory structure is something like this:
Within each of the dates, you'll see the following directory structure:
This directory structure within the date directories is the event information you need to import.
The easiest way to copy all necessary files from an entire month would be to first create a target directory for the files. In this case, a good choice might be /nfs/report, as follows:
mkdir /nfs/report
The following command, in Linux, would copy the necessary files from the month of June 2006:
Next, copy the pnos files to /nfs/report/pnos:
cp pnos/* /nfs/report/pnos
When this is finished, you're ready to use the pnrestore command just as if you were recovering from a disaster, but rather than restoring /nfs/mars-lc, you'll recover /nfs/report instead.
Continue reading here: Configuring Csmars to Integrate with CSManager
Was this article helpful?