Filemaker Server 8.0 Crashes and Backup

1. Is hosting on FileMaker server inherently more corruption-proof
than serving from a standard copy of FileMaker Pro?
Here's why I'm asking the question. I've got called in to my client
three times over last year. Each time it was after a power failure.
Each time a few of the files were not able to be shared out by
FileMaker server 8 as they failed the consistency check. I get things
running each time by exporting the data and importing it into clean
clones. I think that even these clones may be harbouring some latent
corruption as the system has a murky history. But putting that issue
to one side; does FileMaker server cope better with sudden crashes of
the Operating System/Power outages than a standard copy of FileMaker?

2. A warning about corruption to FileMaker server application.
Yesterday, when I went to the client after a power failure, not only
were some of the files corrupted but FM Server 8 had stopped backing
up four months ago! I got the backup working only after re-installing
FileMaker server. My advice: it's important to check your backup files
every so often to make sure they have a recent date on them.

This got me thinking. I always talk about backup with clients. I also
check that their system is backing up. What I don't do is give them
some written statement detailing their backup situation. This might be
along the lines of "All your Filemaker files are backed up daily at
12:00. These are saved to the FileMaker server hard disk. Retrospect
Remote backup software copies this data across to the cntral file
server at 13:00 every day blah blah..." Any thoughts about this?

Regards
Kevin Smith

Re: Filemaker Server 8.0 Crashes and Backup

On 2007-10-03 07:01:09 -0700, KevinSmith
said:

>
>
> 1. Is hosting on FileMaker server inherently more corruption-proof
> than serving from a standard copy of FileMaker Pro?
> Here's why I'm asking the question. I've got called in to my client
> three times over last year. Each time it was after a power failure.
> Each time a few of the files were not able to be shared out by
> FileMaker server 8 as they failed the consistency check. I get things
> running each time by exporting the data and importing it into clean
> clones. I think that even these clones may be harbouring some latent
> corruption as the system has a murky history. But putting that issue
> to one side; does FileMaker server cope better with sudden crashes of
> the Operating System/Power outages than a standard copy of FileMaker?

Not necessarily. Power failures aren't good for any active set of
files. It can be touchy setting up a UPS with software to PROPERLY
close FM Server upon power out, but worth it, if the data is important
and the downtime for restoring or importing is long.

The clone/import is the way to go if the client has 24/7 operation or
work has been done since the last backup. Otherwise, returning to the
last backup is generally faster than importing into clones.

Consider having your clients back up more frequently. That way a backup
done at 5:30pm after close of business would be the best replacement
for a power-failure corrupted set at 2am. Depending on the downtime,
sometimes even re-creating a couple of hours of work is faster than
importing.
>
> 2. A warning about corruption to FileMaker server application.
> Yesterday, when I went to the client after a power failure, not only
> were some of the files corrupted but FM Server 8 had stopped backing
> up four months ago! I got the backup working only after re-installing
> FileMaker server. My advice: it's important to check your backup files
> every so often to make sure they have a recent date on them.

Sage advice. Backups should be checked for functionality monthly, if
not weekly. That means taking a set of backed-up files and actually
OPENING them to see if they're functional. I've had clients tell me all
backups were happening properly, only to find out that (contrary to
what they were told) they'd been backing up the open files, corrupting
the backups and endangering the working files.
>
> This got me thinking. I always talk about backup with clients. I also
> check that their system is backing up. What I don't do is give them
> some written statement detailing their backup situation. This might be
> along the lines of "All your Filemaker files are backed up daily at
> 12:00. These are saved to the FileMaker server hard disk. Retrospect
> Remote backup software copies this data across to the cntral file
> server at 13:00 every day blah blah..." Any thoughts about this?

It's never a bad idea to inform the client what is going on with their
data. You might consider including protocols for checking backups
periodically and taking backups off-site. I've even warned clients in
writing that they needed to prepare a disaster-recovery plan, in case
of fire or flood, or as has happened to one client, repeated theft of
machinery.

Most clients won't listen. But at least you'll have done your part properly.

--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA

Re: Filemaker Server 8.0 Crashes and Backup

On Wed, 03 Oct 2007 07:01:09 -0700, KevinSmith
wrote:

>
>
>1. Is hosting on FileMaker server inherently more corruption-proof
>than serving from a standard copy of FileMaker Pro?
>Here's why I'm asking the question. I've got called in to my client
>three times over last year. Each time it was after a power failure.
>Each time a few of the files were not able to be shared out by
>FileMaker server 8 as they failed the consistency check. I get things
>running each time by exporting the data and importing it into clean
>clones. I think that even these clones may be harbouring some latent
>corruption as the system has a murky history. But putting that issue
>to one side; does FileMaker server cope better with sudden crashes of
>the Operating System/Power outages than a standard copy of FileMaker?
>
>2. A warning about corruption to FileMaker server application.
>Yesterday, when I went to the client after a power failure, not only
>were some of the files corrupted but FM Server 8 had stopped backing
>up four months ago! I got the backup working only after re-installing
>FileMaker server. My advice: it's important to check your backup files
>every so often to make sure they have a recent date on them.
>
>This got me thinking. I always talk about backup with clients. I also
>check that their system is backing up. What I don't do is give them
>some written statement detailing their backup situation. This might be
>along the lines of "All your Filemaker files are backed up daily at
>12:00. These are saved to the FileMaker server hard disk. Retrospect
>Remote backup software copies this data across to the cntral file
>server at 13:00 every day blah blah..." Any thoughts about this?

I've run FM Server 8.0 for over a year now with no problems. In fact,
I've deliberately crashed the system several times (including just
pulling the plug from the AC socket) in order to see how FM Server
would recover. It's always come back 100 percent, every time. IMO
FileMaker Server is a very stable app.

When possible, I set up several automated backup protocols. I don't
rely on the FM Server backup alone. I back up both to the box Server
runs on, and also to another box on the network. For the latter I use
Windows Scheduled Tasks to invoke xcopy on the DESTINATION (or client)
box (I'm an old DOS hand), so I'm pulling the files from the server
(as opposed to pushing them to the client). This, with FM Server's
own backup set, creates a multiply redundant backup scheme.

As you probably know, backing up data is only one half of the process.
For any backup to be effective the restore protocol must function as
well. Too many times have clients insisted they were "fully backed
up", yet they had never attemped a restore from their backups.
Unfortunately, in some cases the restored files are unusable for
whatever reason[s]. And those "fully backed up" clients are screwed.
So doing a mock disaster recovery by backing up, restoring, and then
testing your files is a must.

Another must is getting your user to leave unchanged the backup
protocol set up by the developer. This is not always that simple. I
suggest you verify the backup path that FM Server is using, and
compare it with the current directory tree. Chances are your user has
changed the tree, thereby unwittingly rendering the backup path
invalid. This has happened to me more than once. It's a possibility
that would explain the failure to backup for so long.

hope this helps

--
FW

FM Pro 8.5 under Windows XP Pro, and
FM Server 8.0 under Windows 2003 Server