Non-official script! Provided on 'as-is' basis.
It is recommended to have vRangerPro DB backup before running the script!
Features:
1. Scans CIFS (only!) repository for existing Savepoints.
2. Generates new Global Manifest. Can be used to re-create missing Global Manifest.
3. Synchronizes DB records with actual repo content.
4. Can be executed from any PC with Powershell 2 installed.
5. Should work for non-USA customers. Tested on SpanishServer 2008 and Spanish SQL Express 2008.
Pros:
It fixes situation when imported SPs can not be deleted through GUI (Remove button disabled).
Re-scans/verifies existing repo. In theory some check procedure can be added, e.g. var is missing or unreasonably small var created.
Lets completely avoid ‘Restore from Manifest’.
Customer can create own set of SPs. For example, take following scenario. DR site. Repo exists, admin brings set of SPs from different locations and drops them into the repo share, runs script. Ranger displays both old (if still exist) and new SPs in restore grid. Regular restore job can be created from SP Grid.
Cons:
Requires version 2 of Powershell
Does not perform thorough check of backup content. Presence of 2 metadata files in SP directory is sufficient to consider SP existing.
SP directory should follow original naming convention: root_of_the_repo\<ObjectName>_<ObjectUUID>\<ObjectName>_<Date>_<Time>_<JobTemplate UUID>.
Instructions:
1. Launch Powershell, execute “Set-ExecutionPolicy Unrestricted” if necessary
2. run script
3. select SQL instance, provide credentials if necessary
4. select existing repo you would like to sync
5. provide credentials to access repo share if necessary
6. refresh Repo view in Ranger.
Old GlobalManifest and script log are saved in the root of the repository.
================ update. 03/09/2012 ==================
Some of you may have seen a following error when executing original version of a script.
Exception calling "ExecuteNonQuery" with "0" argument(s): "Conversion failed when converting from a character string to uniqueidentifier."
It happens due to a broken link between BackupTask and SavePoint tables. When backup task is completed successfully, the row in the BackupTask table should have a pointer to the corresponding savepoint. For some reason there are successful tasks with pointer set to NULL.
Attached new version (reposync02) of the script can handle this situation properly and will re-establish link between tables if necessary.
I also recommend to run following sql command to find if there are any broken links between 2 tables. Check 4th (Table_Link) column for NULL value.
This issue could be a reason for malfunctioning retention. SPs with broken link will most probably be ignored by retention mechanism.
SELECT t.TaskId, t.VmName, t.StartTime, bt.SavePointId AS Table_Link, sx.SavePointId
FROM Task t, BackupTask bt, SavePoint s, SavePointXml sx
WHERE t.TaskId = bt.TaskId
AND s.SavePointId = sx.SavePointId
AND bt.TaskId = sx.ManifestXml.value('/*[1]/JobTaskID[1]', 'uniqueidentifier')
AND s.IsDeleted = 0
ORDER BY t.StartTime
P.S. This script has been used in multiple support cases and proved to be very helpful. Especially taking into consideration some recent glitches with "FLR from Manifest".
The post is open for vote, questions and comments.
================ update. 05/28/2013 ==================
New version of the script has been posted:
http://communities.quest.com/thread/23459?tstart=0