Compression across a network

[Bakinup]

When I first started using BESR 8.0 I was told not to use compression over a network. It woud save but not restore properly. Is this true? Does BESR 8.5 address this ? It seems if it worked, a restore or save would go much faster.

Thanks

[Jon_R]

It is not recommended to perform backups over the network using compression highter than 'Standard'. It can be done and may restore, but testing should be done in your environment to ensure the validity of the images.

[Bakinup]

It took awhile but I finally tested standard compression on 2 XP machines. The first worked ok but the second got the ED800012 error (internal structure of the image file is damaged or unsupported)
One of the solutions was to not use compression across the network. So I guess it is hit and miss on this network. Seems it was corrupted when writing the backup to the network storage.

I read somewhere that the backup file can be recompiled??  Is this the same as copying the v2i file without compression to another location?  I found this in the recovery environment. but found no mention of recompile. 
Does theis completely uncompress the file? 
    

[marcogsp]

Open the image in the Recovery Point Browser, then highlight the image name.  Then from the File  menu choose Copy Recovery Point.  The process will give you the option to change the compression scheme of the target image.  Not guaranteed to fix all the problems with your image, but it is worth trying if you suspect that file compression is part of the problem

[Bakinup]

I tried the recompile  but the image must have  been  bad when it was saved. I got the same error as when i was trying to copy  it. 
But I didn't try saving  it locally on the network storage .  Maybe I will try that?? 


Thanks

[marcogsp]

Well, the recompile is a good example of this product being affected by the GIGO principle, -- Garbage In, Garbage Out.  If you can spare the disk space , reducing the compression and storing to a more local drive could help.  In my environment,  I store about two to three weeks worth of images on a large local partition which is part of a larger RAID 5 array.  I then copy the images to a SAN device via scheduled scipt, in order to retain several more weeks of images.

In my environment, I can utilize Medium compression, but the switches, cabling and storage devices are good quality.  The absolute best equipment is not required,  low quality equipment will cause more problems with the imaging process.  As Jon_R pointed out earlier, testing in your environment  is neccessary in order to insure the quality of the images.  I test my images at least once per month in a lab environment.  The results of this testing allows me to feel comfotable with using Medium compression.  Of course, your environment will determine what compression level you can work with.

Best of Luck

[criley]

The following TechNote might help you:

http://support.veritas.com/docs/292972

[Bakinup]

GIGO was applied when the backup was made. as Marcogsp put it.
I found the document that Chris mentioned. That was what was happening
The Document states that if BESR 8.0 is installed Use Live update to go to 8.03 or later.
I am using manager 8.0 to load the agent and schedule the backup. I have not found a way to update to 8.03.   Live update is up to date, (so it states). 
I have considered going to 8.5 but the issue seems to persist within that. Plus  migrating to 8.5 sounds like I would lose everything and have to start over. 
I am backing up over the network to a NAS box. Manager runs on a virtual 2000 server. I tested the Standard compression a few time before  using it and never had an issue until this particuliar backup was made. Maybe the backup should be made with no compression just to be safe. The nodes are too far apart to run around and back them up on a USB device.

So I guess my question is ; Is standard compression robust enough to use across a large LAN with many Routers  switches and a fair amount of traffic??  Or is it hit and miss. And how do I update to 8.03  in manager that is presently using 8.02.26412

This forum has really helped. 
Thanks