Can you please elaborate on your comment from the Logger's perspective. The bottom line is that I am looking for a practical solution to backup the logger data that can be restored in a practically usable format.
Also a year and a half after your post, the archives are still not zipped (Logger 5.3.1).
The other funny thing regarding archives is that their size absolutely does not reflect the amount of daily logs kept in those archives.
For instance, archiving approx. 4000 Oracle events writes archives in size of 800M.
But over 800.000 Windows appl. logs plus 1.2 million VMS logs require only 946M !?
The other issue is that the size of archives of a certain Storage Group usually grows for a week or even longer, than suddenly falls down, without any obvious reason. The number of daily events stored in this archive remain the same, but the size may start at 500M and go up to 1.2G, and then again fall down to 500M.
I'm not sure whether ArcSight is aware of that.
There is more to it, there are reasons why the sizes are inconsistent. The archives are done in chunks and it may bring data that shouldn't be part of that archive.
As for not zipping it, the archive data is already compressed. Try zipping it and see how much smaller it gets. It would be good to hear it.
The archives are absolutely unzipped. Its is a good question for HP ArcSight, why is it so.
If I understand you right, the data in archives might be "wrong" ?! Does it mean, from wrong Storage Groups.
In this case, archiving makes no sense at all.
Yeah, we also "load" the archives from the original Logger and have a spare destination Logger we use to forward all the archive events to which will then re-index the events. This assumes you have at least one Logger that is basically empty and dedicated to this purpose.