Identifying and removing a left-over snapshot

NetBackup ordinarily removes snapshots after the &newProductName; backup completes, unless the Keep snapshot after backup parameter was set to Yes. However, as a result of some system failures, such as a system crash or abnormal backup termination, the snapshot may not be removed.

To identify and remove a left-over snapshot

Use the bpfis command with the query option to list the current snapshots. Enter the following on the client or alternate client, depending on the type of backup:
```
   /usr/openv/netbackup/bin/bpfis query
```
This command returns the IDs (FIS IDs) of all current snapshots. For example:
```
INF - BACKUP START 3629
INF - FIS IDs: 1036458302
INF - EXIT STATUS 0: the requested operation was successfully 
completed
```
In this example, the snapshot ID is 1036458302.
If the bpfis output shows the ID of the snapshot, delete it as follows:
```
   bpfis delete -id snapshot_id
```
If bpfis removed the snapshot, you can skip the rest of this procedure.
Solaris, HP, AIX, Linux: if bpfis could not remove the snapshot, enter the following (on the client or alternate client) when no backups are running:
```
   df -k
```
This command displays all mounted file systems, including any snapshots of a mounted file system.
If a snapshot backup is currently running, the snapshot should not be deleted. NetBackup deletes it when the backup completes.
Here are two snapshots from a df -k listing:
```
/dev/dsk/c1t3d2s4  1048800  73076  914742  8%  /tmp/_vrts_frzn_img__wil_vxfs_1299000
/dev/vx/dsk/clone_qes_clone/ufs 38383 21678  12867  63%  /tmp/_vrts_frzn_img
__mix_ufs_1299000
```
The snapshot appears in the following form:
```
/tmp/_vrts_frzn_img__filesystemname_pid
```
Solaris, HP, AIX, Linux: unmount the unneeded snapshot file systems (on the client or alternate client, depending on the type of backup).
The next step depends on the type of snapshot.
For nbu_snap (Solaris only):
- Enter the following to display leftover snaps:
```
   /usr/openv/netbackup/bin/driver/snaplist
```
- To remove a leftover snap, enter
```
   /usr/openv/netbackup/bin/driver/snapoff snap1 ... snapn
```
  More information is available on snaplist and snapoff.
  See About managing nbu_snap.
For VxVM (Solaris, HP, AIX, Linux) and VVR (Solaris and HP):
Do the following on the client for VxVM, and on the alternate client for VVR:
- Enter the following to display unsynchronized mirror disks:
```
   vxprint -g diskgroup
```
- Enter the following to resynchronize the mirror disks:
```
   vxassist -g diskgroup -v volume snapback
```
For VxVM (Windows):
- Enter the following to display unsynchronized mirror disks:
```
    vxdg -g diskgroup dginfo
```
- Enter the following to resynchronize the mirror disks:
```
vxassist snapback \Device\HarddiskDmVolumes\diskgroup\snap_volume
```
For VxFS_Checkpoint (Solaris, HP, AIX, Linux):
- Enter the following VxFS command to display the name of the checkpoint:
```
   /usr/lib/fs/vxfs/fsckptadm list /file_system
```
  Note:
  file_system is the mount point of the primary file system that was backed up, NOT the snapshot file system that was unmounted in a previous step.
  For example, if the snapshot file system that was unmounted is the following:
```
   /tmp/_vrts_frzn_img__vm2_1765
```
  the original file system, which should be specified on the fsckptadm list command, is the following:
```
   /vm2
```
  Example entry:
```
   /usr/lib/fs/vxfs/fsckptadm list /vm2
```
  Output:
```
/vm2
NBU+2004.04.02.10h53m22s:
    ctime                =  Fri Apr 02 10:53:23 2004
    mtime                =  Fri Apr 02 10:53:23 2004
    flags                =  removable
```
  In this example, the name of the checkpoint is NBU+2004.04.02.10h53m22s.
- Remove the checkpoint by entering the following:
```
/usr/lib/fs/vxfs/fsckptadm remove name_of_checkpoint /file_system
```
  For example:
```
/usr/lib/fs/vxfs/fsckptadm remove NBU+2004.04.02.10h53m22s /vm2
```
- If the checkpoint cannot be removed, unmount it (umount) and retry the following:
```
/usr/lib/fs/vxfs/fsckptadm remove name_of_checkpoint /file_system
```
- For more detail on removing VxFS clones, refer to the recommended actions for NetBackup status code 156 in the NetBackup Troubleshooting Guide.
For TimeFinder, ShadowImage, BusinessCopy (Solaris or HP only):
Do the following on the client or alternate client, depending on the type of backup:
- To discover and remove any VxVM clones:
  See Removing a VxVM volume clone.
- Enter the following to resynchronize the mirror disks:
  For EMC arrays (TimeFinder):
```
   symmir -g device_group establish LdevName
```
  where LdevName is the logical device name of the standard device. For Hitachi and HP arrays (ShadowImage, BusinessCopy):
```
   pairresync -g groupname -d dev_name
```
  For more information about EMC, Hitachi, and HP arrays and resynchronizing disks, see the NetBackup Snapshot Client Configuration document:
  http://www.veritas.com/docs/000081320
For VxFS_Snapshot (Solaris or HP only):
Using the mounted file system from a previous step, unmount the snapshot as follows:
```
   umount -F vxfs /tmp/_vrts_frzn_img__filesystemname_pid
```
For FlashSnap (Solaris, HP, AIX, Linux):
Do the following on the client or alternate client, depending on the type of backup:
- Find the VxVM disk group:
```
   vxdg list
```
- The format of the disk group name is as follows:
```
   SPLIT-primaryhost_diskgroup
```
  If vxdg list does not show the disk group, the group might have been deported. You can discover all the disk groups, including deported ones, by entering:
```
   vxdisk -o alldgs list
```
  The disk groups in parentheses are not imported on the local system.
- Deport the VxVM disk group:
```
   vxdg deport SPLIT-primaryhost_diskgroup
```
- On the primary (original) client, import and join the VxVM disk group:
```
   vxdg import SPLIT-primaryhost_diskgroup
    vxrecover -g SPLIT-primaryhost_diskgroup -m
    vxdg join SPLIT-primaryhost_diskgroup diskgroup
```
- On the primary (original) client, start the volume and snap back the snapshot volume:
```
vxvol -g SPLIT-primaryhost_diskgroup start SNAP-diskgroup_volume
vxassist snapback SNAP-diskgroup_volume
```
  Example:
  In this example, chime is the primary client and rico is the alternate client. 1hddg is the name of the original disk group on chime.
  chime_lhddg is the split group that was imported on rico and must be rejoined to the original group on the primary chime.
  On alternate client rico, enter:
```
vxdg deport chime_lhddg
```
  On primary client chime, enter:
```
vxdg import chime_lhddg
vxrecover -g chime_lhddg -m
vxdg join chime_lhddg lhddg
vxvol start SNAP-lhddg-vol01
vxassist snapback SNAP-lhddg-vol01
```

For FlashSnap (Windows):

Find the VxVM disk group:
```
   vxdg list
```
The format of the disk group name is as follows:
```
   SPLIT-primaryhost_diskgroup
```
Deport the VxVM disk group:
```
   vxdg -g split_diskgroup deport
```

On the primary (original) client, import and join the VxVM disk group:

   vxassist rescan
    vxdg -g split_diskgroup import
    vxdg -g split_diskgroup -n diskgroup join

On the primary (original) client, snap back the snapshot volume:

vxassist snapback \Device\HarddiskDmVolumes\diskgroup\snap_volume

More Information

Logging directories for UNIX platforms

Logging folders for Windows platforms

Customer support contact information

Latest patches and updates

Important notes on &newProductName;

&newProductName; installation problems

Snapshot provider information

Removing a VxVM volume clone

Identifying and removing a left-over snapshot

Feedback

Feedback