Subscribe

Upgrade to SMO 3.2 results in protection failure.

Hi.

A customer recently upgraded to SMO3.2 for all databases.

The reason for the upgrade is that we are currently in a vfiler migration proccess and the new filer has ontap 8.1 so SMO 3.2 was need according to the support matrix.

Everything should be supported with snapdrive,smo,ontapversion etc.

It was recently discovered that all the backups had a unreasonably long lag. When we tried to run the smo backup create manually the result was this.

[ INFO] DS-10016: Starting backup for dataset smo_oraslask-vir-1.test.it.gu.se_slask1 with retention class daily.
[ERROR] FLOW-11019: Failure in DatasetBackupAdd: SD-10028: SnapDrive Error (id:2483 code:102) Failed to modify backup version for backup ID 0, error(21012):Volume name 'storetest-vas-1:/slask1_arch' was not found.
[ERROR] FLOW-11010: Operation transitioning to abort due to prior failure.
[ WARN] FLOW-11011: Operation aborted
[ERROR] FLOW-11008: Operation failed: SD-10028: SnapDrive Error (id:2483 code:102) Failed to modify backup version for backup ID 0, error(21012):Volume name 'storetest-vas-1:/slask1_arch' was not found.
[ WARN] SMO-02032: Error while protecting backup: FLOW-11019: Failure in DatasetBackupAdd: SD-10028: SnapDrive Error (id:2483 code:102) Failed to modify backup version for backup ID 0, error(21012):Volume name 'storetest-vas-1:/slask1_arch' was not found.

We have double check the dataset and even tried to recreate the dataset entirely. Even tried to make a new baseline snapvault without success ( with a test database ).

We get the above error no matter what we do. I have a case with netapp, but i'm cheking here as well if anyone recognize this issue.

Snapdrive has also been checked and it seems to be able to connect to the filers.

Smo creates snapshots on the primary without any problem but no snapshots is created/transfered to the secondary.

Re: Upgrade to SMO 3.2 results in protection failure.

Hi Tony,

Couple of things...I would make sure the customer has opened a support case for this, if this still hasn't been resolved.

One thought off the top of my head...Do you know if the dataset was created in DFM as a SMO application dataset? This would be done using the smo gui/cli and not via DFM directly.

You can verify this by using the NMC for DFM, clicking on the dataset, and then in the lower right bottom of the screen, you will see the version of SMO being listed...

If the dataset was created outside of SMO, then that would be consider a non-application dataset, which is not supported with SMO.

hope that helps!

Freddy

Re: Upgrade to SMO 3.2 results in protection failure.

Hi!

Yes, a case has been opened.

The dataset was created with the smo application. When creating the smo profile.

Could be something with the profile creation process perhaps, but we receive no errors or warnings when creating the profile with smo.

/Tony