source: gpfs_3.1_ker2.6.20/share/man/man8/mmrestorefs.8 @ 122

.TH mmrestorefs 03/23/06

mmrestorefs Command

.SH "Name"

.PP

\fBmmrestorefs\fR - Restores a file system from a GPFS

snapshot.

.SH "Synopsis"

.PP

\fBmmrestorefs\fR \fIDevice\fR \fIDirectory\fR

[\fB-c\fR]

.SH "Description"

.PP

Use the \fBmmrestorefs\fR command to restore user data and attribute

files to a file system using those of the specified snapshot.

.PP

Prior to issuing the \fBmmrestorefs\fR command, you must unmount the file

system from all nodes in the cluster. The file system may not be

remounted until the \fBmmrestorefs\fR command has successfully completed,

unless you have specified the \fB-c\fR option to force the restore to

continue even in the event errors are encountered. Automatic quota

activation upon mounting the file system is \fInot\fR restored by the

\fBmmrestorefs\fR command. You must issue the \fBmmchfs -Q yes\fR command to restore automatic quota

activation.

.PP

Snapshots are not affected by the \fBmmrestorefs\fR

command. Consequently, a failure while restoring one snapshot may

possibly be recovered by restoring a different snapshot.

.PP

When the

\fBmmsnapdir -a\fR (add a

snapshots subdirectory to all subdirectories in the file system) option is in

effect, the snapshots subdirectories may no longer show the complete list of

snapshots containing the parent directory, if the file system was restored

from a snapshot that was not the latest. Since the root directory is

contained in all snapshots, its snapshots subdirectory will always show the

complete list of snapshots.

.PP

For information on how GPFS policies and snapshots interact, see

\fIPolicy-based data management for

GPFS\fR in

\fIGeneral Parallel File

System: Advanced Administration Guide\fR.

.PP

Because snapshots are not copies of the entire file system, they should not

be used as protection against media failures. For protection against

media failures, see

\fIGeneral Parallel File

System: Concepts, Planning, and Installation Guide\fR and search

on \fIrecoverability considerations\fR.

.SH "Parameters"

.PP

.RS +3

\fB\fIDevice\fR

\fR

.RE

.RS +9

The device name of the file system for which the snapshot is to be

created. File system names need not be fully-qualified.

\fBfs0\fR is just as acceptable as \fB/dev/fs0\fR.

.PP

This must be the first parameter.

.RE

.PP

.RS +3

\fB\fIDirectory\fR

\fR

.RE

.RS +9

The snapshot with which to restore the file system.

.RE

.SH "Options"

.PP

.RS +3

\fB-c

\fR

.RE

.RS +9

Continue to restore the file system in the event errors occur.

.PP

Upon completion of the \fBmmrestorefs -c\fR command, the file system is

inconsistent, but can be mounted to recover data from the snapshot. If

necessary, the command may be issued to recover as much data as

possible. The

\fBmmfsck\fR command may

be run on an inconsistent file system.

.PP

After the \fBmmrestorefs -c\fR command has been issued, use the

\fBmmfsck\fR command to clean up the files or

directories that could not be restored.

.RE

.SH "Exit status"

.PP

.PP

.RS +3

\fB0

\fR

.RE

.RS +9

Successful completion.

.RE

.PP

.RS +3

\fBnonzero

\fR

.RE

.RS +9

A failure has occurred.

.RE

.SH "Security"

.PP

You must have root authority to run the \fBmmrestorefs\fR

command.

.PP

You may issue the \fBmmrestorefs\fR command from any node in the GPFS

cluster.

.PP

When using the \fBrcp\fR and \fBrsh\fR commands for remote

communication, a properly configured \fB.rhosts\fR file must exist

in the root user's home directory on each node in the GPFS

cluster. If you have designated the use of a different remote

communication program on either the

\fBmmcrcluster\fR

or the

\fBmmchcluster\fR command, you must

ensure:

.RS +3

.HP 3

1. Proper authorization is granted to all nodes in the GPFS cluster.

.HP 3

2. The nodes in the GPFS cluster can communicate without the use of a

password, and without any extraneous messages.

.RE

.SH "Examples"

.PP

We have a directory structure similar to:

.sp

.nf

/fs1/file1

/fs1/userA/file2

/fs1/userA/file3

/fs1/.snapshots/snap1/file1

/fs1/.snapshots/snap1/userA/file2

/fs1/.snapshots/snap1/userA/file3

.fi

.sp

.PP

If the directory \fBuserA\fR is then deleted, we would have:

.sp

.nf

/fs1/file1

/fs1/.snapshots/snap1/file1

/fs1/.snapshots/snap1/userA/file2

/fs1/.snapshots/snap1/userA/file3

.fi

.sp

.PP

The directory \fBuserB\fR is then created using the inode originally

assigned to \fBuserA\fR. We take another snapshot:

.sp

.nf

mmcrsnapshot fs1 snap2

.fi

.sp

.PP

The output is similar to this:

.sp

.nf

Writing dirty data to disk

Quiescing all file system operations

Writing dirty data to disk again

Creating snapshot.

Resuming operations.

.fi

.sp

.PP

After the command is issued, the directory structure would appear similar

to:

.sp

.nf

/fs1/file1

/fs1/userB/file2b

/fs1/userB/file3b

/fs1/.snapshots/snap1/file1

/fs1/.snapshots/snap1/userA/file2

/fs1/.snapshots/snap1/userA/file3

/fs1/.snapshots/snap2/file1

/fs1/.snapshots/snap2/userB/file2b

/fs1/.snapshots/snap2/userB/file3b

.fi

.sp

.PP

If the file system is then to be restored from \fBsnap1\fR:

.sp

.nf

mmrestorefs fs1 snap1

.fi

.sp

.PP

After the command has been issued, the directory structure would appear

similar to:

.sp

.nf

/fs1/file1

/fs1/userA/file2

/fs1/userA/file3

/fs1/.snapshots/snap1/file1

/fs1/.snapshots/snap1/userA/file2

/fs1/.snapshots/snap1/userA/file3

/fs1/.snapshots/snap2/file1

/fs1/.snapshots/snap2/userB/file2b

/fs1/.snapshots/snap2/userB/file3b

.fi

.sp

.SH "See also"

.PP

mmcrsnapshot Command

.PP

mmdelsnapshot Command

.PP

mmlssnapshot Command

.PP

mmsnapdir Command

.SH "Location"

.PP

\fB/usr/lpp/mmfs/bin\fR