Although backup and read-only filesets are created in a similar manner, they serve a different purpose. Backing up a fileset does not make data available from multiple sites or reduce the load on a machine, as replication does. However, backing up a fileset is an efficient way to make previous versions of data such as user files available for restoration.
When you create a backup fileset, the backup fileset is filled with an array of pointers to the data housed in the read/write source. Then, the identities of the read/write source and the backup fileset are switched; the backup fileset becomes the read/write source, and the read/write source becomes the backup fileset. The sharing of data between the read/write and backup versions of a fileset results in significant disk space savings. (See Data Sharing Among the Different Types of DCE LFS Filesets .)
A backup version preserves the exact state of its read/write source at the time the backup is created. For example, if you make a new version of each user's fileset every day at the same time, data that was deleted a week ago cannot be restored from the backup version because that backup version will have been overwritten six times since then. Similarly, if you make a new version of each user's fileset every day and a user revises a file three times during the same day, there is no way to access the first and second revisions the next day; the backup version records only the third and final version of the file, which is the version that existed in the read/write fileset when the backup fileset was made.
A backup fileset must reside at the same site (File Server machine and aggregate) as its read/write source. It has the same name as the read/write version, with the addition of a .backup extension.