Can

Firstly, that is hardly unexpected.  Your media database keeps entries of backups for all your clients, and these entries are not removed until the backups expire and the media is relabelled, so it will get bigger if your backups are not passing out of retention or if you add more backups (clients/savesets) which is the case.  If your media database increases in size the time to back it up will increase.  Your indexes relate to the browse period you set on your backups but they are not so much of an issue as your system is not put on hold while they are backed up.

Secondly, I worked with a system with a very large media database a few years back which was about 2GB (at the time EMC said this was one of the largest media databases they had seen); the size of the media database led to a very unstable system and we eventually resolved this by splitting the backup server across two backup servers.  Although EMC don't publish any suggested maximum I would suggest going over 2GB is asking for trouble.  If you believe this system will continue to grow like this I would suggest you begin to plan for the eventuality that you are going to have to bite the bullet and add another backup server.

Hi David,

  Seems that system will continue to grow. We run media db scavange and controlled corruption many times but nothing changed.

  Also we have a hang problem on backup server related with media db size. When a mminfo query runs or while nsrim in progress, backup server cant do anything (I mean it is stopping to create daemon.log and nmc console is locking, it means all backup processes are stopping) . 

  A SR has been opened 3 months ago. Many configuration has been tested with EMC but there is no result.  Now we started performance tuning on that server.  We are checking and fixing all schedules, groups, clone and stage operations, non-used clients, Parallelism values and policys. We hope that it will be more stable after workarund finish ? Have you any suggestions exectp splitting the backup server across two backup servers? We will do it but we need time to do this operation.

  By the way you said your mediadb size was 2 gb. What was the elapsed time for your bootstrap backup ?

Thanks.

If you are running a scavenge that tells me you are having problems with database corruption; this is something you should only be doing in emergencies and not as part of usual operations.  Also as you point out when you access the media database, to run queries against it, to back it up or on the daily run of nsrim this locks other backup processes from starting until it completes, which as the media database becomes larger becomes a bigger outage.  From memory we were seeing about an hour for the backup of the media database.

You can try tuning the server but you are not going to achieve much as the problem is the media database is becoming the bottleneck.  How long do you retain your backups for?  The site where we had the issue was a financial organization that had a requirement to keep backups for 7+years which was the main reason for the media database becoming so large.  Most other sites I have worked on have had a much lower retention time.  If you don't have the legal requirements to keep data so long you may find you can do something such as keep long retentions on full backups but have shorter retentions on incremental backups.

Hi David,

  Thanks for your helpful answers, we will seperate the server ASAP.

Are you sure that it is media db that takes so much time?  If this index + bootstrap then that's nothing unusual as index size is the one which will consume most of the time for saving.  If this is bootstrap backup, this contains resource and media database backups.  Resources itself are small files which may take some time to backup. To add the misery, recently in latest versions EMC added that jobsdb is backed up by default as part of bootstrap backup and that "database" may contain millions of small files (at least you can deselect that feature).  I assume the only way to check the time of mdb backup itself is to do export via nsrmmdbasm and see what time do you get - mdb backup is nothing more then export written by uasm to tape.

Hi Hrvoje,

  we solved the problem with mmrecov, media db size reduced from 2.6 gb to 2.2 after mmrecov and broken links has beeb cleared than mediadb saving time has reduced to 5 minutes.

Thanks.

If your media database is that size you are likely to continually be plagued by issues.  I would suggest you start planning to split the server as a medium term resolution of these issues.

Hi David,

  We are planning about it but interesting thing is mmrecov result I think. There isn't any documentation of about this future of mmrecov ( deleting broken links and increasing media db performance).

Thanks.

I've not heard anything about plans to replace mmrecov which would be a radical redesign of the software; if there was a change to this I would expect mmrecov to remain as a legacy recovery method.  Perhaps one of the EMC guys can comment on this about whether there is any substance in that rumour...