A suggestion. You mention using DOS batch files to perform local backups,
which can also be used across a network for (semi-) remote backups. Consider
adding another line to your batch file to rename the files. For example: REN
C:\backup\*.102 *.10X or something like that. This will make the files
unrecognizable to FileMaker, changing Names_.102 to Names_.10X. It's an
alternative to zipping and leaves the backup files more accessible if needed
quickly. But it still meets the requirement of hiding them totally from
FileMaker/ebase.
Hiding backups is really important, since FileMaker will look around for any
file it needs to open. If it finds a copy nearby, it may choose to open that
rather then the original you had intended. You'll never know until you
reopen later. And maybe not even then. For example, you could open the
correct Names file but the Payments file from the backup set. You add
payments to current Names. Then you make another backup, overwriting the
first. Voila! Your new payments disappear permanently! Since FileMaker
locates files by name, the solution is never to have two copies of a file
with the same name. Renaming (or zipping or stuffing) the entire set solves
this problem. This is very easy with a batch file. I use an AppleScript to
accomplish the same thing when I archive.
Gary
> Subject: Re: How do you back up the database?
> From: Ashton Computing & Mgt Svcs <[EMAIL PROTECTED]>
> Date: Thu, 29 Mar 2001 10:11:35 -0500
> X-Message-Number: 9
>
> At 09:50 03/29/2001, you wrote:
> >What files do we need to back up in the database and where are they
> >located?
> >We will be backing up to network drive.
>
> I won't answer this question directly, since it will almost certainly
> bring
> on a flood of helpful suggestions. But this is a good opportunity to
> share
> a particularly dangerous and embarrassing mistake that could happen to any
>
> Windows user--and might well also apply to Macs, though that's just
> speculation on my part.
>
> Recently I organized my Ebase setup a little, moving all the data tables
> into a separate directory from the programs, which I named " Membership
> Current Data". Then I created another new directory called "Membership
> Backup Data". It was then very simple to perform backups by selecting all
>
> of the current files and dragging them to the backup directory.
>
> Where the trouble came was when I held down the wrong mouse button during
> this process, and inadvertantly *moved* the files instead of copying
> them. That didn't seem serious, I saw it immediately, and copied the
> files
> back where they belonged. Unbeknownst to me, however, MS Windows saw the
> move take place, and helpfully adjusted the location data attached to my
> desktop icon--but didn't see any need to reverse the process when I copied
>
> the files back. So my next couple of updates went into the backup
> files. I didn't realize this until the next backup, when a lot of
> messages showed up about "Do you really want to overwrite a file with a
> later creation date?" Naturally, I let a couple of them go by before
> realizing that this just *wasn't* right.
>
> Fortunately, we keep lots of levels of backup, and I was ultimately able
> to
> recover all but a dozen or so updates. I've now written a couple of MSDOS
>
> batch scripts to do these copies without involving my dubious thinking
> processes. These are short--3 or 4 lines each--and available to anyone
> interested.
>
> The moral is, stay awake when you're doing backups. They can really spoil
>
> your day.
>
> Barry
>
>
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
