Tag: snapshots

How do filesystem snapshots work in AIX?

To perform valid backups of your database, it is important to suspend the database. This prevents modifications of files during the backup process. By taking a point-in-time snapshot of your database files, your backup program will be capturing a “frozen” database instead of an “in motion” database.

Eclipse has an updated backup script that uses database suspension with snapshots to create point-in-time images of your database files. If you would like this script installed on your AIX server, please submit a service request for the support team to review your system’s configuration, validate that it meets the appropriate requirements, and implement the changes.

The snapshot script is typically scheduled to run at regular intervals via crontab to create new filesystem snapshots.

After running the script, the snapshot filesystems are mounted under /snap, allowing read-only access by backup software. For example, the snapshot of the /u2/eclipse/LEDGER file would be located at /snap/u2/eclipse/LEDGER. When configuring backup software, it is recommended to backup every file under /snap/u2.

Since every change (delta) between the snapshot and the “live” filesystem must be recorded, the snapshots have a finite lifespan. By default, the snapshot script is configured to hold 1GB of changes before requiring a refresh. On busier systems, or on systems where the snapshots must be retained for a longer period of time to accommodate a slow backup process, the snapshot volume size may be increased by editing the snapshot backup script.

When the snapshot volume has reached its maximum capacity for tracking changes, it must be recreated by running the snapshot script again.

For troubleshooting purposes, a log of the snapshot backup script is kept at /tmp/snapsave.log.

For more information, refer to the following resources:

Why can’t I remove a Linux logical volume?

If you are unable to unmount or lvremove a logical volume, verify that there are no processes holding the LV.

Locate the major/minor numbers for the logical volume you’re trying to remove (ie lvol0):

dmsetup info -c | grep lvol0

Take note of the 5th column, which indicates if a volume is “open,” and the 2nd and 3rd columns, which are the major and minor IDs, respectively. For example:

[root@eclipse ~]# dmsetup info -c | grep lvol5
datavg-lvol5         253  24 L--w    1    1      0 LVM-4WlscxDDEw5R9IvjgZYpu5FQeW9h835ADtQzXFr3cJ6SHEcgS4NFMxzaSKjUkedy
datavg-lvol5-cow     253  27 L--w    1    2      0 LVM-4WlscxDDEw5R9IvjgZYpu5FQeW9h835ADtQzXFr3cJ6SHEcgS4NFMxzaSKjUkedy-cow

Find any process attached to this volume by searching on the major and minor IDs discovered above:

lsof | grep "major,minor"

For example:

[root@eclipse ~]# lsof | grep "253,24"
beremote  14524      root   15r      BLK             253,24                1835186 /tmp/filehRrCD8 (deleted)

Shut down or kill any process still accessing the volume to continue unmounting and removal.

If no processes show as accessing the volume in lsof, check to make sure nothing is sharing the filesystem (i.e. rsync, nfs, or samba).

If you have verified that no processes are holding the LV open, verify that the LV is not mounted somewhere:

cat /proc/mounts

If the volume appears in the output, unmount it using the umount command.
For further assistance, please contact Red Hat for support