I was wondering if we move the snapvault relation managed by Backup Manager to Protection manager,
and if we don't remove the schedule for the secondary volume from the backup manager, who shall trigger the backup Job ?
I am not sure if there is something wrong in the setup or this is a normal behavior.
--> We have imported couple of Backup relations (Snapvault) to protection manager and added a protection policy to a dataset which shall schedule the snapvault update everyday and maintains the snapshot retention on the secondary volume.
At the same time we missed to remove the DFM Backup manager schedule from the same secondary volume.
But I have noticed that there is no snapshot created by Backup Manager or we only have the snapshots created by protection manager.
Off-course this is very good, but I was wondering if both (BM and PM) should have triggered the backup job. and created a snapshot on the secondary with their own naming format.
(The schedule time on both BM and PM are different)
you did not mention the version of DFM/UM you are using, however all recent versions of the software will not modify the existing SV schedule on the controllers when importing a relationship into a dataset.
Therefore, if there is/was an existing schedule on the controllers driving the updates (regardless if DFM/UM was managing them), they should be manually removed to avoid firing off extra/unplanned backups.
I am not sure why you did not see those BizConn/Backup Manager based backups continuing to occur, but I would have expected them along with the Protection Manager based backups.
Re: OnCommand Backup Manager and Protection Manager
If you notice the schedules in the volume there is no schedule times or day instead only retention settings are written.
If you notice typically on secondary a -xtranser schedules is created which will pull the changes from source, transfer the same and create an archive snapshot on secondary.
Below is the snippet from the snapvault command reference manual.
The third configuration step is to establish the SnapVault snapshot schedules on the primaries and the secondary with the snapvaultsnapsched command. A snapshot schedule in a volume creates and manages a series of snapshots with the same root name but a different extension such as sv.0, sv.1, sv.2, etc. (For snapshots on SnapLock secondary volumes, the extensions are representations of the date and time the snapshot was created rather than .0, .1, etc.). The primaries and secondary must have snapshot schedules with matching snapshot root names. On the secondary, the -x option to the snapvaultsnapsched command should be set to indicate that the secondary should transfer data from the primaries before creating the secondary snapshot. If -x is set, when the scheduled time arrives for the secondary to create its new sv.0 (or sv.yyyymmdd_hhmmss_zzz for SnapLock volumes) snapshot, the secondary updates each qtree in the volume from the sv.0 snapshot on the respective primary. Thus, the primaries and secondaries need snapshot schedules with the same base snapshot names. However, snapshot creation time and the number of snapshots preserved on the primary and secondary may be different.
But in case of BM managed relationships the schedules are managed by BM, snapshot creation is done by BM after successful transfer, only the snapshot retention is delegated to ONTAP via the create schedules with out any schedule times in it
Below are the details of the Relationship after imported to dataset.
[root@vmlnx221-118 log]# dfpm dataset list importedSv
Id Name Protection Policy Provisioning Policy Application Policy Storage Service