| Q: If a file is open when vdump attempts to copy it exactly what will get
copied, is it a "snapshot" of the file or what? When that file is
restored what state will it be in? Will it be usable?
A: Since vdump uses normal POSIX open() and read() calls, it will not get
a snapshot of any kind. It will simply get, for every block in the
file, the current data that is in that block. This implies that vdump
should not be used while another application is writing to the file since
vdump might save application-inconsistent data. If vdump saves a file
in such a way that it is inconsistent from an application perspective,
vrestore will restore it in the same state and you're in trouble. Running
vdump on clones is different, as explained below.
Q: Conversely what happens if vdump has a file open and some other
application attempts to open it?
A: Since vdump opens the file only for reading, it will not interfere with
another application's opening the file for reading. If that application
is going to write to the file, though, you could end up with inconsistent
data in the saveset (the term used to describe the output of vdump) as
described above.
Q: What difference is there (if any) between the way vdump interacts with
an open file and the way a vdump of a clone copy of the fileset
interacts with an open file. It is my understanding that the clone is
simply a metadata copy and so when you vdump the clone the actual
blocks on disk that contain the file's data still need to be read so if
the file is in use by another application there is still potential for
conflict. Is this right?
A: No, that is not right. When you clone a fileset, only the metadata is
copied at that time. But, if you then modify a file in the original
fileset,
say by modifying block X of file Y, AdvFS will first save the original
block X of file Y to the clone fileset and then write your new value for
block X of file Y to the original fileset. This is known as copy-on-write.
So it is quite safe to have applications modifying files in the original
fileset while you run vdump on the clone fileset. That is, what you will
always get in your saveset is a snapshot of what the original fileset
looked
like at the time that the clone was made. This is one of the primary uses
of clone filesets.
Having said this, two points should be made regarding clone filesets and
24x7 environments:
1. Until you have the backup safely on tape, you don't have it. That is,
if the tape backup is your only way of getting back to a consistent state,
be careful. Having simply cloned the fileset is NOT a guarantee that
you can restore the fileset if, say, a disk goes bad while you are running
vdump on the clone fileset. Hopefully, you have other technologies such
as RAID and LSM in place to avoid scenarios like that. If not, you
probably
should wait to resume activity on the original fileset until after the
tape backup is complete. That sounds unacceptable given your requirements
so let's hope that RAID and/or LSM is in place.
2. AdvFS clone filesets do not provide true on-line backups. That is, it
is necessary to stop all applications from writing to the original fileset
long enough to run 'clonefset' and make a clone. This should only take
a few seconds or up to a few minutes and is a big win over the UFS model
of stopping all applications, running backup, and restarting applications.
Nonetheless, if your requirements are such that you can not stop your
application(s) from writing to the original fileset long enough to make a
clone, you need to consider alternatives to AdvFS clones and vdump for
your backup requirements.
[Posted by WWW Notes gateway]
|