Snapshot file system aix

The snapshot appears as an exact image of the snapped file system at the time the snapshot was made. See Freezing and thawing a file system. Initially, the snapshot file system satisfies read requests by finding the data on the snapped file system and returning it to the requesting process.

When an inode update or a write changes the data in block n of the snapped file system, the old data is first read and copied to the snapshot before the snapped file system is updated. The bitmap entry for block n is changed from 0 to 1, indicating that the data for block n can be found on the snapshot file system. The blockmap entry for block n is changed from 0 to the block number on the snapshot file system containing the old data.

A subsequent read request for block n on the snapshot file system will be satisfied by checking the bitmap entry for block n and reading the data from the indicated block on the snapshot file system, instead of from block n on the snapped file system.

This technique is called copy-on-write. Subsequent writes to block n on the snapped file system do not result in additional copies to the snapshot file system, since the old data only needs to be saved once. All updates to the snapped file system for inodes, directories, data in files, extent maps, and so forth, are handled in this fashion so that the snapshot can present a consistent view of all file system structures on the snapped file system for the time when the snapshot was created.

As data blocks are changed on the snapped file system, the snapshot gradually fills with data copied from the snapped file system. The amount of disk space required for the snapshot depends on the rate of change of the snapped file system and the amount of time the snapshot is maintained. In the worst case, the snapped file system is completely full and every file is removed and rewritten.

External snapshot: starting with AIX 5. Internal snapshot: starting with AIX 6. Backsnap: it uses the snapshot command and does everything automatically, holds the backup in an archived file As I saw External snapshot is the preferred method by most administrators, as an external snapshot can be mounted separately on its own mount point.

One big advantage of using JFS2 snapshot is that not the whole filesystem is copied to the snapshot image, just a fraction of it, so we can save time and storage space with this procedure. The JFS2 snapshot command will create an image of a filesystem at a point in time, allowing the user to back up data from the snapshot rather than from the original filesystem.

With snapshot, the file system is frozen, ensuring you get a full copy, and avoid 'open file', 'running process' or 'file not found' issues. There is no need to shut down an application, but it is better to do the snapshot in a quiet time. You can have up to 15 external snapshots of a JFS2 file system and using the rollback utility, external snapshots can be rolled back to the point when a snapshot was taken. The concept used in the snapped filesystem is "copy on write", which is at first only the filesystem structure is created and when any modification is done on the original fs write or delete , the original data is copied into the snapped filesystem.

Monitoring the usage of a snapshot is a good practice, as if it runs out of space all snapshots become unusable. Checking free space can be done, if we mount the snapshot and check it with df. Database file systems are usually not a very good subject for creating snapshots, because all database files change constantly when the database is active, causing a lot of copying of data from the original to the snapshot file system.

If it is on 'no', fs has to be recreated. When you make an internal snapshot a special directory called. This directory is read-only and contains a link to the location of the snapshot image.