Oracle ZFS Storage Appliance: Unable to delete replication target package/snapshots

Asset ID:	1-72-2213620.1
Update Date:	2018-03-07
Keywords:

Solution Type Problem Resolution Sure

Solution 2213620.1 : Oracle ZFS Storage Appliance: Unable to delete replication target package/snapshots

Applies to:

Oracle ZFS Storage ZS3-4 - Version All Versions and later
Oracle ZFS Storage ZS3-2 - Version All Versions and later
Sun ZFS Storage 7420 - Version All Versions and later
Sun ZFS Storage 7320 - Version All Versions and later
Sun ZFS Storage 7120 - Version All Versions and later
7000 Appliance OS (Fishworks)

Symptoms

Attempts to delete duplicate replication packages on the replication target node fail with this error:

An unanticipated system error occurred:

dataset cannot be destroyed

This may be due to transient failure, or a software defect. If this problem persists, contact your service provider.

Changes

None.

Cause

Known issue.

Bug 20861589 - unanticipated error when destroying package with project set to nodestroy=true

Solution

Change the project property 'nodestroy=true' to 'nodestroy=false', then try to destroy the package(s) again.

Example:

NAS:shares (pool-0) replication source-001 package-002> select test10 get nodestroy
nodestroy = true

NAS:shares (pool-0) replication source-001 package-002> select test10 set nodestroy=false
nodestroy = false (uncommitted)
NAS:shares (pool-0) replication source-001 package-002> commit

NAS:shares (pool-0) replication source-001 package-002> select test10 get nodestroy
nodestroy = false

NAS:shares (pool-0) replication source-001> destroy package-002
Destroying this package will cancel any ongoing replication updates from the
source appliance and permanently sever the replication connection for this
package. All data received as part of this package will be permanently
destroyed.

Are you sure? (Y/N)
NAS:shares (pool-0) replication source-001>

When there are numerous shares in a replicated project and one of the shares has had the 'Prevent destruction' box checked, it can be tedious to find a share preventing the destroy of a replication package.

The following example is for finding a share with nodestroy set in the project SAP in the pool DATA.

A support bundle has the information in the zfs/DATA.datasets.prop file. If the 'zfs get' timed out in the support bundle run it manually in the shell with:

# zfs get -r all DATA > /var/ak/dropbox/data.prop.out &

Then look for shares in the project that have nodestroy set to 1.

# grep SAP DATA.datasets.prop | grep "nodestroy 1"
DATA/nas-rr-f3d73318-1ab9-ce6b-aa27-9fa4fa84ffc2/SAP/clnexport com.sun.ak:nodestroy 1 ... local

Once we unchecked the 'Prevent destruction' box for the SAP/clnexport share the destroy command removed the replication package.

If the nodestroy property is set to false and the CU still cannot delete the replication package, then check whether the package(s) they are trying to destroy have been cloned.

If the package(s) have been cloned, the clone(s) must be destroyed before the package(s) can be destroyed.

If there are no clones, then the CU has two options:

Option 1 -- Recreate the replication configuration

Action plan:

1. From the source, disable the corresponding replication action and then destroy it.
2. From the target, destroy the corresponding project (i.e. Replica). (If "nodestroy=true", set "nodestroy=false".)
This will not affect other replication actions going to the same target or any other replication source.
3. When creating the new replication action on the source, DO NOT enable replication of snapshots until AFTER you have a successful initial replication.
Once the initial replication is complete and verified on both source and target, you can check the include snapshots.

Option 2 -- Engage Oracle Support by opening a Service Request.

Attachments

This solution has no attachment