The backup policy of the cluster is described below. There are 2 different mechanisms. NetApp snapshots are taken and provide a convenient way to restore 'point-in-time'. Snapshots store the changes at the block level. Tivoli incremental backups store files when metadata of those files has changed. It serves as a backup for file restorations and deleted files.

The disk space used for snapshot backups involves the space used on the LUNs, the volume occupied by the snapshots themselves, and the Fractional Reserve. The latter two reduce the available disk space of the volume that holds the LUNs. It breaks down like so. I'll update the stats periodically so we can measure growth.

<hi #ffff00>We do not have LUNs anymore but one large NFS volume that we'll keep track of.</hi> The LUNs have used up: (includes filesystem overhead).

At this point in time, the NetApp snapshots chew up:

Note: This has completely changed. Snapshots have been deleted as we're running out of space. So we only have TSM file level backups. Since snapshotting is turned of the fractional reserve is not implemented.

So, puttting LUNs and Snapshots usage together we get.

That may surprise you, it is explained like this … The “Fractional Reserve” is the space set aside for the first snapshot which equals the size of all the LUNs. Think of this as the initial backup. You can then think of the “Snapshots” as the delta, the incrementals. The reserve can be set to less than 100% with some risk. For now, we'll leave it at this setting since we have no usage patterns yet.

Note: snapshots and fractional reserves are disabled.

The backup process copies data from client workstations to server storage to ensure against loss of data that is regularly changed. The server retains versions of a file according to policy, and replaces older versions of the file with newer versions. Policy includes the number of versions and the retention time for versions. A client node can restore the most recent version of a file, or can restore earlier versions.

1. If a backup is an incremental type (always) :
   1. Back up the file only if the file or its attributes changed since the previous backup (date, size, ownership, permissions).
2. If a file is being modified during backup, the program should do the following:
   1. Retry, and back up the file only if the file is no longer being modified.
3. How many different versions of the file should be kept? 1.
4. Number of days to keep inactive versions? 30.
5. For backup files that a user has deleted from the client node:
   1. Number of file versions to keep? 1.
   2. Number of days to keep the last file version? 30.

A version becomes inactive when the client node stores a more recent backup version. Policy determines how many inactive versions of files the server keeps, and for how long. When files exceed the criteria, the files expire.

Swallowtail Usage. I'll update the stats periodically so we can measure growth.

Back