Lack of 64-bit compression

[Michael_McKenne]

I complained about it during beta testing.   I am complaining again.   Why can't they fix compression in 64-bit version of BE.   We paid for a working product.   Microsoft wants us moving towards 64-bit and they are partners.   We deserve the same consideration as 32-bit customers.    Windows 2003 64-bit Server and XP Pro x64 are fully released and supported products.   They are not fringe OS like Canon believes.   I dropped Symantec Norton products because of Symantec's poor support and lack of innovation.   I was highly disappointed with them buying Veritas.   I hope they spin Veritas back to a independent company.  So we can get back to the excellent support they offered before the dark days of Symantec.    The product has been out long enough for them to fix the issue.    Maybe they should offer us discounted pricing for a limited product.   I see no excuse why it has not been resolved by now.  

I have called in on my support contract complaining about it.   Symantec management said they will offer the same great service as Veritas did.   I am still waiting for this.   I rather have compression fixed.   I should not have to call in to get great support.   It should be in the product not by my support contract. 

I am checking on other backup software for my second Windows Pro x64 SP2 AMD64 workstation.   I am going to be installing its second Exabyte tape drive and want a better supported product.    I might end up switching both workstations over to another product. 

Sorry for the ranting.    Not happy....

[Greg_Meister]

Michael,

Please confirm if hardware and software compression both fail, or only software compression that is failing on the x64 systems.

Thanks,

Greg

[Greg_Meister]

Michael,

If you are using software compression, this has been reported as fixed in the latest build (7170). If you've upgraded to 7170, and are still experiencing a problem with software compression, please call support and have a case opened, so this can be addressed accordingly.

Also, just to clarify, software encryption and software compression on the same job is still a no-no.

Greg

[Rob_Swift]

Greg,  If it indeed fixes the problem can you update the following document since it says there are no plans to fix this bug with a hotfix:  http://seer.entsupport.symantec.com/docs/287306.htm

We are going to try to download this hotfix shortly.

[Greg_Meister]

Hi Rob,

Quoted from the same technote you linked:

"However, the issue is currently scheduled to be addressed in the next major revision of the product. "

Build 7170 is that next revision. Let me know if that does indeed resolve the compression issues.

Thanks,

Greg

[Michael_McKenne]

I will upgrade to it tonight and report.  I will also remove and update the drivers with tapeinst.exe.  

[Michael_McKenne]

First backup on VXA-3 is 722 MB/min. 

Software compression:

Second backup fell below 300 MB/min on new tape.

I ran Exabyte tools both short and long test.  Both passed.

Third backup started at 11 MB/min and climbed to 500 before falling back to 200. 

Switching back to hardware compression

Message Edited by Michael McKenney on 04-01-200712:48 PM

[Greg_Meister]

Michael,

From what you're describing, you are not having an issue with compression working, but with the change in throughput between software and hardware compression. Is this correct, or is there also an issue with compression not working (1:1 or lower to tape media)?

Have you tried installing Exabyte tape drivers and test the same backup job within Backup Exec? I've seen occassional instances where OEM drivers have performed better an  certain environments.

Greg

[Michael_McKenne]

I tried the manufacturer's drivers for Windows.   They did not work well.  Exabyte will only gaurantee the driver for Windows native backup.  I was wondering if the BE driver and manufacturer's drivers were the same ones.   Yesterday, I got 718 MB/min on a backup with BE11D.   Probably, the next backup will be back to 660.      They said Veritas should have provided proper drivers.    What is strange is software compression works one day and not the next.    The workstation is not changed that much in a week.   I can't see my hardware performance dropping that much on SCSI RAID and Firewire 800.   Drive performance is still the same.   Wednesday is the next backup.  

[Rob_Swift]

I can confirm that build 7170 will now use software compression on a 64-bit Windows platform in our environment.  In our case we are performing Backup-to-disk and the throughput/rate is as expected.

Greg, I would still recommend that some one update doc 287306 (http://support.veritas.com/docs/287306) so it is clear the the "next major revision" (i.e. build 7170) is now available.

Thanks

[Greg_Meister]

Michael,

If you are running the same job, with the same settings, backing up the same resources, to the same tape device; and the only change is which day or time the job is running, we need to investigate what is changing in the environment to alter the throughput rate. We get the data as fast as the environment gets it to us (locally or over the network), and we write to the destination device as fast as it will accept. We do not have any "throttling" or direct control of the throughput.

As for the software compression that "works one day and not the next", I'd like to know if hardware compression behave with the same intermittency. Does the same condition occur using software compression to a Backup-to-Disk device?

Greg

[Michael_McKenne]

Monday nights, I run error checking on all partitons.   Backups are usually Wednesday and weekend.   Anti-virus has all BE and SQL processes excluded from scanning.   I get home from work.  Turn on the workstation.   Then, kick off the backup with a pre-scan.   I don't have much running during a backup.   BE can use all four 2.4 GHz cores and 8GB of RAM.   Windows indexing usually has 10 files to reindex on startup.   Indexes are kept on the S: drive (6 drive RAID 10 array), which does not get backed up.   S: is paging, temp, indexing, and target array for CS2 and other projects.  Once a project is completed, its moved to either E: (8 drive RAID 10 array) or L: (Firewire 800 drive).   Be barely hits the CPU and RAM.   I wish it could lauch a separate backup process for each array and drive.   I would like to have my three backups running each as a separate process to improve performance.   One backup on cores 1,2,3 and BE running on 0.    I usually just let the backup run till complete.   I have the resources to run BE and other apps at the same time.   It would be great if BE 11D could be made SMP multi-core to improve performance and have a separate process for each backup session running.

Hardware compression was usually consistently around 660MB/min.   Software compression can be 660-730 MB/min.   10D in XP Pro SP2 was 715-730 MB/min.  I run O&O Defrag Pro 8.6 and do complete / name order.   I have all the advanced caching enabled on SCSI RAID and LaCie Firewire 800 drives.