Backup To Disk file size

[CoreyWilson]

Can anyone tell me why Veritas defaults to creating 1GB files when you choose to use backup to disk? I have set this for 50gb files (since we are backing up about 3tb) and 1gb files leads to hundreds being created in our backup directory.

Is there anything wrong with increasing the file size? I cant find much information in the manual or help files about it but wanted to make sure there wasnt a catch to bumping up the size if the default is 1GB.

Thanks all.

 

[steveot]

1 gib files are easier to manage but cuase more fragmentation. If your running 10.1 you may want to look at installint hotfix 27.

Lets say you change the file size to 50gb. You have a job that runs and the backup size is 200gb. Lets say something happens to one of the bkf files or the OS corrupts one of the files. You have lost a 1/4 of you backup set. You can catalog the other 3 files and get whatever information is left on the remaining 2 bkf files. So of you put the files at 10gb and one got corrupt the chances of losing more data is less, etc.

 

[steveot]

Also in the above example back to the 50gb file size example, lets say another job comes along and overwrite one of the bkf files and it was intened to do so, same scenerio, less risk with smaller files.

 

[CoreyWilson]

Thanks Steve,

Makes perfect sense, that is what I was thinking as well but I wanted to ask as I have little experience with backup to disk with this product and was not totally sure.

Is there a best practice? 10gb sounds like a reasonably easy to manage file size with reduced risk without flooding the backup directory with hundreds of instances.

 

[steveot]

Not really a best practice. I can just tell you that smaller files can reduce the performance of the backup to disk job over time. Unless you use the pre-allocation feature in 10.1. WHen you use the pre-allocation is best to start with a formatted volume where teh backup to disk file reside.

http://seer.support.veritas.com/docs/283264.htm