Flash Archives
frogswallow
I have read through the information here on flash archives, and
haven't seen a reference to my question. So here we go...
I'm trying to run flash archives via crontab as a method for disaster
recovery. By shipping a repository disk of archives off site, we can
ensure that we have the OS configurations of all of our production
hosts quickly accessable. I'm using the automounter to dump all of
the archives to the central location, which works very well.
Since we have some large databases on these production machines,
usually several, we need to exclude multiple locations from our
archives. We don't have any machines running Solaris 9 yet, so we
have worked around the excludes problem with a wrapper script. It
runs a find command, pipes it through an egrep (using a file of
excluded locations), and then dumps the resulting paths to a file. We
then call flarcreate -n <name> -f <file> -F <archive name> from the
wrapper script.
So far everything is straightforward. We have worked hard to identify
all the locations where we can save space in our archive, and based on
our long list of excluded paths, we should have smallish archives.
However, some of our hosts are producing 10g archives not long after
they produces 1g archives. Something is squirrelly here, and I
haven't been able to track it down.
Can someone point me to an easier way to do this, or perhaps some bug
ID's or an infodoc that I haven't seen? I have thought about just
copying the Solaris 9 flarcreate script over to a Solaris 8 host for
testing, but I just haven't had the time to break and fix a machine a
couple times to test specific paths. I know there has to be a better
way.
I appreciate your time, thanks for the thought even if you don't
answer.
ted
Markus Gyger
> It runs a find command, pipes it through an egrep (using a file of
> excluded locations), and then dumps the resulting paths to a file. We
> then call flarcreate -n <name> -f <file> -F <archive name> from the
> wrapper script.
Doing essentially the same, e.g.:
# (find / ! -type D ! -type s -print \( ! -mount -o -fstype lofs \) -prune
> df -a | awk '{ print $1 }') |
> egrep -v '^/net/|^/var/tmp/|^/var/crash/|^/var/apache/logs/.*log|^/$' |
> sort -ru | flarcreate -n s9-1203 -S -H -c -f /dev/stdin -F s9-1203.flar
I think there is (was?) an 8 GB limit for a single flash archive
because of a limitation of cpio. You can look at an archive using:
$ (awk '/section_begin=archive/ {exit}' && gzip -fd) < s9-1203.flar |
> cpio -ictv | more
Markus
frogswallow
<clip>
> You can look at an archive using:
>
> $ (awk '/section_begin=archive/ {exit}' && gzip -fd) < s9-1203.flar |
> cpio -ictv | more
>
>
> Markus
Marcus,
Thank you very much for your help!! I think I have identified the
problem. We are using a find command, which then runs an egrep using
strings similar to:
^/opt/SUNWexplo/output/
However, in using your script, I found that flarcreate was recording
it's information a little bit differently:
-rwxr-xr-x 1 root other 1558 Dec 16 15:19 1999,
opt/SUNWexplo/output/explorer.8324146f.hostname-2004.03.12.09.46/init/rc2.d/S72autoinstall
-rwxr--r-- 1 root sys 7134 Jan 5 16:52 2000,
opt/SUNWexplo/output/explorer.8324146f.hostname-2004.03.12.09.46/init/rc2.d/S72inetsvc
We're looking to egrep out strings which start with a /, but the
flarcreate doesn't seem to be picking up these strings. I now need to
research why, but it's an excellent start. The funny thing about this
is that we're using
flarcreate -n <name> -f <path_to_file_list> -F <archive_name>
I would think that egrepping befire we even accessed the flarcreate
script should be eliminating these files. At any rate, thank you for
your input, I at least know where to look now.
Ted