Remote backup

[tigergirl]

Hello all,

My company is working with an FM developer who is not very responsive to our needs. Unfortunately the politics of the situation are such that we are unable to extract ourselves from this particular developer, so I'm looking for ways around some of the major problems.

Our database will be served remotely on FileMaker Server and we would like to run a local backup (in our office) periodically - probably two to three nights a week. Our developer has decided this is absolutely unnecessary so she won't be setting up any scripting to make it happen from her end. Is it possible for us to set up a file with a script that would access the remote database and grab all the information we need to have backed up locally? Is it possible to do this without involving the developer so we don't have to fight about it? How do we do things like "Find all" inside the remote database so we know the backup is complete?

Thank you in advance for any help you can give!!

Best,

Tiger

[Vaughan]

The developer should be telling you that:

1) It's a *very* bad idea having multiple copies of databases around the network. If somebody opens up one of these rogue copies, users may accidentally connect into the rogue instead of the main system. This will lead to users adding and changing records in the wrong file, then complaining later (when they open the main system) that they cannot find the records or changes. It's very hard to work out what's going on, too, if the rogue is opened for a short while then shut down.

2) Once a file is hosted by FileMaker Server, the Save a Copy As command (the command you'd use to create the remote backup) becomes disabled. So even if they wanted, a developer couldn't make the backup scripts anyway. One of the reasons for doing this is to ensure that no rogue copies of the files can be created around your network, because if they are opened users could connect into the wrong ones. Which is reason number 1.

On this issue, they are 100% correct.

However, you could create scripts that *export* the data out of all the files. These text files contain only the data, and aren't the actual databases themselves. They could be used to recover a crashed or corrupted system but would require re-importing into empty shells of the files, serial numbers reset etc (ie, a high level of technical knowledge required) but that process too could be scripted somewhat.

However, I'd again discourage any system like this from being developed, and instead put the resources into ensuring the FM Server computer was setup to perform regular local and remote backups to secure locations.

[tigergirl]

Thank you, Vaughan. I understand what you're saying.

It is important that we have a local copy of the backed up information because the server thus far has proved unreliable and we don't have any access to the backed up data should the server go down. This is a situation we're stuck with, so I'm trying to make the best of it.

If we set up scripted exports, would we set up shells and import data into the same shell every time - i wouldn't want to be creating a new file every time we export.

Thanks again,

Tiger