Catalog size in netbackup 7.6.1.1

I've heard of people going to 3TB.  But then certain commands might take a very long time to run.  I think the real issue is number of images, and the amount of meta-data in the EMM database run by Sybase ASA.

Apologies but I'm not aware of hard-limits of image count.  I guess the real issue is how big the Sybase ASA database gets.  I can't imagine that the size of the image database ".f" files is an issue.  So, if you have BIG backups (i.e. lots of files in not many images) then maybe you don't and won't have a problem.  i.e. the list of files backed-up is not in the EMM database, they are in flat files in folders.  So, a big catalog backup does not necessarily indicate a big EMM database.

It is actions like the back-ground auto image cleanup/expiry which obviously take longer as the quantity of images grows.  

.

Just curious... how many images do you have?

> bpimagelist -d 01/01/1970 00:00:00 -idonly | find /v /c ""

I have multiple installation with catalog sizes in the range of 3-5 TB running on Linux. No functionality issues seen. One issues is however the time the catalog takes, we have taken extra steps to secure it.

28.000 images is not a lot. All my environments are > 1.2 millions images and that is not even one of the dirty dozen.

28000 images seems like a small number of images to have a 1TB catalog.  Your ratio of large backup image sizes versus image count must be quite high indeed.  E.g. one my environments has 15000 backup images, and the catalog is only 80GB.

.

Can anyone confirm whether SLP incomplete images do not show in the bpimagelist listing?

.

I really do not mean to scare monger, but I'm wondering whether it might be worth raising a support case to get your catalog looked at?  Or perhaps confirm for yourself whether you have many truely large backup images with millions upon millions of files in them.  I could knock up a quick script to list all image sizes, along the lines of...

1) list all images using bpimagelist

2) read the list, and create a list of unique client names

3) read the list of uinque client names and run bpclimagelist to generate a simple list of all imagers per client - and bpclimagelist is handy because it gives you the total number of files, and the size of each backup image.

~35MB per backup image. 

If user has short retension time but lots of VMware accelerated backup doing every day fulls ?

Dolly - Please enlighten us :-D

My domain in question is basically vm & ndmp backups. Average full backup of entire domain usually ranges between 130 - 145 TB. 30% of the VMs are daily full (not accelerated) while rest of 70% are weekly full & daily cumulative incr.  Daily fulls/daily cumu incr are kept 2 wks. weekly fulls are kept much longer.

Could this be reason why  the catalog grow exponentially? I found this link which seems to explain that there's  no hard limit interms of catalog size.

https://support.symantec.com/en_US/article.HOWTO99788.html/

The issue with Catalogs size is mainly:

1.  Some commands will take more time to run, for example, bpimagelist

2.  Time it takes  to backup/ restore

Given restores generally take longer than backups (OS has to recreate inodes etc which slows things down), if your 5TB catalog takes 2 days to restore, but your business states the back server has to be restorable within 1 day, you have a problem !

Thank you all for your support & helpful suggestions