Buongiorno, il problema che segnaliamo è il seguente: il job di meta-index cataog che parte in conseguenza del job di backup del serverfarm di sharepoint con GRT abilitato, va lentissimo (non supera i 5 MB/s) e di conseguenza non termina in tempi ragionevoli (dopo 2 giorni abbiamo deciso di cancellarlo).
L'installazione è BackupExec 2012 SP1 su windows 2008 R2 e il job di backup gira su storage di deduplica locale al server.
Grazie del supporto.
The catalog phase of a Sharepoint content DB backup may take a very long time if your database is very large or contains a very large number of containers like sites, lists, libraries and a large number of objects but should never take 2 days. First be sure that AOFO is enabled for the backup then check on resource usage on the Backup Exec server for disk backup and the Sharepoint SQL server for Tape backup (look at CPU and memory for beremote.exe).
By default Backup exec 2012 uses AOFO/VSS for Sharepoint GRT backups because of the new change block method allowing the combining of inc/diff backups with the full to create a composite view of the DB backup to restore GRT items from...
What happens with a streaming backup of a large content DB is that the SPS agent has to keep track of the DB blocks during backup to use during the catalog phase. If a snapshot backup is done this tracking isn't necessary and the job can run much faster.
HI all and thanks for your reply,
the backup job of sharepoint is a backup-to-disk and not to tape, it runs on deduplication disk storage and the following data meta index catalog job (due to GRT enable) runs very very slow (it takes more than 2 days).
AOFO is enable by default, i could try to turn it off.
I read on other post that a possible cause is that the previous catalog may be corrupted, could this assumption be true?