[NTLUG:Discuss] Script question

[Rick Matthews]

Steve,

I appreciate your taking the time to explain this method of archiving
and its benefits. You build a convincing case! I'm going to review my
processes with this in mind.

Thanks!

Rick

-----Original Message-----
From: discuss-admin at ntlug.org [mailto:discuss-admin at ntlug.org]On Behalf
Of Steve Baker
Sent: Saturday, January 05, 2002 11:49 PM
To: discuss at ntlug.org
Subject: Re: [NTLUG:Discuss] Script question


Rick Matthews wrote:

> I can modify the naming convention, if that will help. How would you
> name them? Before you answer that question, you need to know a few
> additional facts:

Rather than rename the files, I'd create separate directories for each
backup level.  Naming the directories with a leading '.' (as in '.1',
'.2',
etc).

This has several benefits.

  * During normal operations you don't even have to *see* the backups.
    The directories and the files inside them don't clutter normal
operations
    but you can see them with 'ls -a' if you want to.

  * The whole backup 'aging' mechanism is very simple, extremely safe
and
    it doesn't depend on peculiarities of how your shell is set up:

       rm .3/*
       mv .2/* .3
       mv .1/* .2
       mv * .1

  * You can (probably) rerun your application on yesterday's data
without
    upsetting todays data. eg:

       cd .1
       run_my_application

  * Things don't screw up monumentally if you happen to somehow get
    more than one file with a '.1', '.2' or '.3' extension.  Nearly
    every script offered in the process of this discussion has had that
    problem.

  * If you later change your application such that it generated multiple
    files each day, you don't have to re-think your entire process.

  * Programs that understand particular filename extensions will work OK
    with the backed up files.

Also, I'd tend to let the OS's file time stamp do the job of keeping
track
of time rather than storing the date/time in the filename.  Using 'mv'
to
move a file into a different directory doesn't alter the date/time
associated
with the file.

The benefit of that is:

   * You aren't 'fighting' Linux - you are letting it's standard
features do
     the work for you.  Timestamps stored in the filename are
meaningless to
     programs you don't create yourself - but relying on the creation
date
     means that you can use programs like 'find' to do things like
finding all
     files more recent than a particular date, most tape backup programs
can be told
     to only back up and restore files that were written within in a
certain time range,
     etc, etc.

   * Having your file always have the same name (no matter what date it
was written on)
     will tend to simplify admin scripts too.  Having scripts that say
things like:

       rm myfile_*.dat

     ...(because the script doesn't want to parse the date)...leads to
problems.
     Suppose for some reason someone does something out of the ordinary
like:

       cp myfile_01-05-2002.dat  myfile_saved.dat

     ...he'll find to his suprise that the admin script removed the copy
he saved.
     It's better if the script be completely precise about the file it
removes:

        rm myfile.dat

     ...then there is absolutely no risk of problems.

All of this is largely a matter of personal taste though.  I bet you
could come up
with a list of reasons NOT to do what I suggest.

----------------------------- Steve
Baker -------------------------------
Mail : <sjbaker1 at airmail.net>   WorkMail: <sjbaker at link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

_______________________________________________
http://www.ntlug.org/mailman/listinfo/discuss