BE 12.0: Backup Stream very slow

[Buzzman]

Hello,

i have to backup 1,3 TB of data at the from a sas storage to the scsi connected backup server via b2d. The backup starts with over 25ooMB/min. After a few hours (i can´t determin exactly when) the backup troughput goes down to 300 MB/min.

I´ve checked all options for the b2d folder. Caching is activated for the partition.

Does someone have a idea what could cause this downgrade of the troughput?

Best regards,

Buzzman

[CraigV]

Hi Buzzman,

It depends really...a lot of the time it is because of having to back up many small files. It is also dependant on what you're backing up to, and backing up from. Disk defragmentation can also cause slow response during the backup.

Here's a TN that you can read up on and see if you can pick up on some info that may help...

http://www.symantec.com/business/support/index?page=content&id=TECH8326

Laters!

[Buzzman]

Hi CraigV,

thank´s for your advice.

Your´re right, we´re having a lot of small files. Maybe it´s getting faster after the defragmention of the hard drive. Let´s see what happend after this weekend when the full backup has finished.

Best regards,

Buzzman

[Khue]

Just to chime in here, we have a similar issue here and I haven't really found a good way around it. We store small signature files in the range of 1-2 kb. We have about 400 gigs worth of these small files. It takes about 10 hours to back this up completely. Ideally, we should archive those images older then 3 years which would significantly cut space, but you still have the issue where backup exec just has slow copy times on small numerous files. It would be kind of nice if there was a way to compress them down quickly to a single flat file, but even that would take scads of time that could just be spent copying to BE.

[CraigV]

...1 option is to back up those files to disk first. From there, stream to tape. Disk handles the random IO a lot better than a tape drive would, and at least doing backup to tape of large files keeps the streamer at a more constant state.

[teiva-boy]

The proper option would be to use the Storage Foundation FlashBackup option with BackupExec.  This was designed to backup the RAW partition, ignoring the file count/sizes to backup the volume VERY fast.  

The negative to FlashBackup is that if you have a 1TB volume with only 100GB of files on it.  Your backup will be 1TB in size, as FlashBackup is backing up the RAW volume, ignoring the filesystem.

This means, it's best to use volumes that are only 10% or so larger than your datasize and manage your growth accordingly.  

[Buzzman · Accepted solution]

Hello CraigV,

now it works! But i think it´s better to describe the problem again in details.

Problem:

- We backed up 1,5 TB of data from a SAS-Storage to a raid0 (Size is 4TB) volume on the backup server.

- Storage and Server are connected via SCSI.

- When performing a full backup at the weekend the backup job starts with 2500MB/min. But the troughput gone down to 250-300MB/min. The backup time took more than 70 hours.

We have tried all to optimize the backup time (raised up stripe size of the raid volumes, defragmentation of the volumes, firmware updates on the raid controller and so on). All without success.

Solution:

- We´ve found a forum post (which had absolutely no relationship to backup time) with a small advice that the "maximum size for the backup-to-disk files" is relevant.

- Now we´ve done several test with different sizes between 20MB and 50GB for the backup to disk files.

- The best setting for us is 10 GB for the file size. The time for the whole backup job is about 11 hours.

OK, i hope this helps someone else too.

Best regards,

Buzzman