Yesterday I was hoping the issue would be solved by adding the extra roles, but it didn't.
My data set updated, but not at the time of the snapmanager taking a full backup, but at the time the schedule was set in the protection manager (1PM).
If I compare the default protection policy with the one I created, I see the following differences:
Remote backups only (default)
1. Primary data : Local Backup Schedule : none
2. The Primary data to Backup schedule is "First Sunday at 8:00PM plus weekly and daily"
3. Throttle : Nightly transfer window
3. Backup retention duration: Hourly 0 hours, Daily 2 weeks, Weekly 8 weeks, monthly 14 weeks
SQL Server Remote backups (custom one created)
1. Primary data : Local Backup Schedule : none
2. The Primary data to Backup schedule is "Daily @1PM"
3. Throttle : None
3. Backup retention duration: Hourly 1 weeks, Daily 1 weeks, Weekly 2 weeks, monthly 8 weeks
The backup retention change is for trial, because at this time I only have my snapvault comming over to the second tier, but no retention at all. I set no throttle (not needed) and had set a daily schedule at 1PM. This is actually the time the snapvault is triggered at this moment. Since we want the snapmanager to trigger it, I changed it to a new one "Monthly - No schedule" !
If I look at the job overview in PM I see this for the data set: Could not find any backups to transfer on Primary data node of application dataset SnapMgr_SQLServer_RMGINFRA01(20434).
If I check it on the dfm server:
C:\>dfpm backup list SnapMgr_SQLServer_RMGINFRA01
There are no backups.
From what I read in the doc kb58938, I should see at least one or more entries like these here (even if the snapvault transfer doesn't work):
10121 02 Jun 2010 01:15:20 unlimited Primary data 06-02-2010_01.14.49
If I snap list one of the volumes on the primary that are part of the data set, I see the following snapshots:
roesnap1> snap list rmginfra01data
Volume rmginfra01data
working...
%/used %/total date name
---------- ---------- ------------ --------
21% (21%) 2% ( 2%) Jul 28 00:16 sqlsnap__rmginfra01__recent
41% (31%) 5% ( 3%) Jul 27 00:16 sqlsnap__rmginfra01_07-27-2010_00.15.37__daily
48% (17%) 6% ( 1%) Jul 26 00:16 sqlsnap__rmginfra01_07-26-2010_00.15.47__daily
52% (15%) 8% ( 1%) Jul 25 00:16 sqlsnap__rmginfra01_07-25-2010_00.15.30__daily
58% (22%) 9% ( 2%) Jul 24 00:17 sqlsnap__rmginfra01_07-24-2010_00.15.34__daily
59% ( 5%) 10% ( 0%) Jul 23 14:08 roesnab1(0118052941)_rmginfra01data_sv_rmginfra01data-src.3 (snapvault)
59% ( 2%) 10% ( 0%) Jul 23 13:40 roesnab1(0118052941)_SnapMgr_SQLServer_RMGINFRA01_backup_1_RmgInfra01SqlData-src.0 (snapvault)
62% (19%) 12% ( 2%) Jul 23 00:16 sqlsnap__rmginfra01_07-23-2010_00.15.41__daily
67% (25%) 14% ( 2%) Jul 22 00:16 sqlsnap__rmginfra01_07-22-2010_00.15.26__daily
roesnap1>
Like you see above, there is also another snapvault relation from the previous setup with script (before integration with PM) which I don't want to delete at this time !
Another strange thing I see is the not match between source (Jul 23 13:40) and destination (Jul 28 01:00) snapshot in the snapvault relation.
roesnab1> snap list SnapMgr_SQLServer_RMGINFRA01_backup_1
Volume SnapMgr_SQLServer_RMGINFRA01_backup_1
working...
%/used %/total date name
---------- ---------- ------------ --------
5% ( 5%) 0% ( 0%) Jul 28 01:00 roesnab1(0118052941)_SnapMgr_SQLServer_RMGINFRA01_backup_1-base.6 (busy,snapvault)
roesnab1>
Feedback is more than welcome at this time !!
Regards,
Geert