exchange backup on a sbs2008 forces tape change?

[Toofarnorth]

i have a client with sbs2008 installed. we run be2010r2 sbs edition on it.

be is installed on the sbs2008 server itself.

backup goes to a hp dat 160 tapestation.

the problem started with the tape reaching maximum capacity. i had to split the backup into two parts. systemstate is taken on its own and goes to a backup to disk folder. the other part is unchanged and contains the exchange database and files from the shares.

when i run the test of the backup job it says that there is around 65gb of data. this should fit on one tape.

i have tried re-arranging the order the backup is taken;

if i backup exchange first it asks for a new tape after it has written the exchange data to the tape.

if i backup the files first it asks for a new tape before it will continue with the exchange backup.

do you have any tips for me regarding this?

id really like to fit all into one tape (and i do know that its recommended to backup exchange in a job of its own. the client just wants one tape to keep track off and the job has to run at night..)

thanks in advance!

[pkh]

If your tape is full, splitting your job will not cramp more data onto to the tape.  A test backup does not actually backup the data.  The only way to truly tell how much data is written onto the tape is to do an actual run.  I would suggest that you do a backup onto two tapes and see how much data is actually written onto them.

If your client wants everything onto one tape, then it is time to think of higher capacity tapes like LTO.

[Toofarnorth]

thank you for taking the time to answer :)

my apologies for not explaining properly... 

the problem is not to fit everything on one tape anymore. i have split the backup into 2 jobs, where one stores 16gb on disk and the other one stores 65gb on tape.

the problem is:

whenever i try to backup exchange this makes backup exec ask for a new tape.

the exchange backup is approx 15gb in size and the files i have in the same job approximately 50gb. so they should both fit on one tape.

if i put exchange backup first in the resource order list it will backup exchange and then ask for a new tape when its time to backup the files.

if i put exchange last in the resource list it will back up the files and then ask for a new tape when its time to backup exchange.

the strange part is that it was working fine before the tape got full.... 

[pkh]

In your jobs, you should target the devices and not the All Device pool.  The job that is going to disk should target the B2D folder directly and the one going to tape should target the tape drive.  Do NOT target the All Device pool.

[Toofarnorth]

i have verified that the backups point to their respective devices.

to be on the safe side i have assigned them to separate media sets as well. ill report back with status after trying that.

maybe the best/easiest way would be to back up exchange to disk and then just add those files to the tape backup?

[pkh]

If you are using GRT, you should back up Exchange to disk and then duplicate that to tape. Don't backup the .bkf files like ordinary files.  Backing to disk will save you the need to stage when you want to restore an individual mailbox.

It sounds like you are still cutting it very close to the capacity of the tape.  Did you ever put in a second tape and let the job complete.  You can then see how much data is written to the tapes and the compression ratio.  If you are using compression and find that you are getting more on the tapes than on the disk, then you are actually compressing data which is already compressed.  In this case, it might be better to turn off compression.  See my article on this subject.

https://www-secure.symantec.com/connect/articles/compression-short-explanation

[Toofarnorth · Accepted solution]

Found the solution. Turns out that folder redirection was enabled with user only access to the files.

This lead to the test run not seeing all files that were backup'ed from those folders. I had to back it up to disk and then check what was actually in that backup to discover where the problems were.

Thank you for your advice and i hope this might help others in the same situation :)