The migration feature analyzes SnapManager job metadata on the host to determine which databases to include in the proposed datasets for the host, and which policies to attach to each dataset. If the host is a member of a Windows cluster, the migration feature analyzes the metadata on each node in the cluster to determine the datasets.
If you back up a pair of heavily used databases every hour, for example, and a lightly used database on the same host once a day, migration will propose two datasets: one for the heavily used databases, the other for the lightly used database. It will then attach a policy with an hourly schedule to the heavily used dataset and a policy with a daily schedule to the lightly used dataset.
In the following illustration, assume that "HUDB" refers to the heavily used databases and "LUDB" refers to the lightly used database. The migration feature will create the following datasets and policies:
For each host or Windows cluster, migration automatically proposes as many datasets and policies as needed. Snapshot copies on the storage system are not affected.
Both backup and verification metadata are migrated. The following SnapManager for Microsoft SQL Server 7.x job properties are migrated, where relevant to the job type:
These properties are captured in the policies attached to the proposed datasets. You need to evaluate the policies to determine whether they are appropriate for the resources defined in the dataset.
Snapshot copies for the backup jobs you want to migrate must exist in NetApp storage. Ordinarily, the migration feature does not migrate backup jobs for databases that no longer exist on the host, with one exception: If the SQL Server instance that owns the database still exists, the job metadata is migrated. This means that you can restore the database if necessary from Snapshot copies in storage.
Even if the SQL Server instance no longer exists, the migration feature warns you to that effect. You can then reconfigure the SQL Server instance and restore the databases it owns from Snapshot copies in storage.
SnapCenter does not migrate the following:
You cannot use migrated job metadata to determine the status of a clone split.
You must specify users, roles, and permissions explicitly for the SnapManager for Microsoft SQL Server.