Remote backup...?

[AliB]

Currently, our database files are stored on a secondary volume in our Xserve with scheduled backups to the 'default' backup folder (within the Filemaker Server folder on the main drive).

It's high time we added an offsite backup, and I'd like to implement something slick and simple....

1. Client user inserts USB stick into their Mac

2. Client clicks 'backup' script in FMPro

3. Server runs script to mount shared stick over network

4. Server runs backup script to store files on the stick

5. Server ejects network volume

6. Client receives confirmation that backup is complete

Is this possible?

Any thoughts on how I might achieve this....?

Thanks in advance!!

[AliB]

It looks like you can't specify a networked volume for backup...right?

OK, so I'd still like to achieve the above "easy-peasy" backup to USB stick – is it possible to:

1. Insert USB stick into client machine (as above).

2. Click "backup" script in FMPro (as above).

3a Server runs backup to default location on Xserve

3b Server mounts shared volume (USB stick)

3c Server runs Applescript to copy backup to stick

3d Server unmounts USB stick

4. Filemaker reports progress of step 3 to client, and informs when it is safe to eject.......

Thoughts?

[IdealData]

It looks like you can't specify a networked volume for backup...right?

Correct - in fact only drives that are mounted internally can be used for DIRECT FM SERVER BACKUP.

Why not try your procedure - it should work. you may need to give allow a little time for the FMS backup to complete before initiating the AppleScript copy.

Your memory stick on its own is not really a sustainable backup procedure. Got any other networked hardware you can backup to?

[AliB]

Why not try your procedure - it should work. you may need to give allow a little time for the FMS backup to complete before initiating the AppleScript copy.

Because I'm not 100% sure how... What script steps are needed to instruct Filemaker Server to run the backup (when running a script on a client)?

Your memory stick on its own is not really a sustainable backup procedure. Got any other networked hardware you can backup to?

Plenty actually. As mentioned, the data is 'live' from a secondary internal volume (second drive in Xserve), and the backup copy is within the Filemaker Server folder on the main drive. We have a drobo too which is used for network TimeMachine backups and dropbox storage.

I'd like that third backup copy on stick, so that the powers that be can have a copy with them, offsite.

I'm now thinking of another possible solution – I could use Automator (and/or Applescript) to do this the other way (i.e. from the clients side):

1. Client inserts USB stick

2. Client clicks 'backup' workflow, stored on stick

3. Client Mac mounts Xserve volume with database backups

4. Client Mac updates file(s) on stick

5. Client Mac ejects remote Xserve volume (and stick)

I don't see why this wouldn't work, and perhaps be easier to implement... I'm just not sure how to set this up!

[AliB]

Correct - in fact only drives that are mounted internally can be used for DIRECT FM SERVER BACKUP

Can you explain why I can use the drobo (i.e. external Firewire 800) as a backup destination – it's definitely not an internally mounted drive!!

[AliB]

Sorted.

I've created an Automator application that uses a bit of Applescript to mount (and subsequently eject) the shared network volume on our Xserve, and copy the backup from there to USB stick.

Works a treat!

[IdealData]

Can you explain why I can use the drobo (i.e. external Firewire 800) as a backup destination

Are you sure? If that's the case then you should also be able to define the USB stick as a target for FMS backups.

[Steven H. Blackwell]

All of this sounds to me as if you're not running FileMaker Server at the logout as a background daemon. That is how it is intended to be run.

Take a look at the Backups and More Backups White Paper on Wim Decorte's website. It has a lot of good information about backups of FileMaker Server data.

Steven

[AliB]

Yes....

The drobo is connected to Xserve via Firewire 800;

A folder on the drobo was shared using Server Admin;

The fmsadmin user was given read/write privileges for this folder;

Filemaker Server (10) then lets me use filemac:/drobo/sharedfolder/backup as a 'validated' backup destination.

Can't see where I'm doing anything wrong here...?

[AliB]

All of this sounds to me as if you're not running FileMaker Server at the logout as a background daemon. That is how it is intended to be run.

..eh? What do you mean Steven.... you have me concerned.

Are you suggesting that there should be no users logged in to our Xserve at all...? The Filemaker Server administration panel tells me everything is working normally.

[Wim Decorte]

Doing a remote backup directly adds vulnerability to the process and may leave you without valid backups. It's a risk that you need to think about. How bad would it be to not have a valid backup?

The better approach is to backup directly to the FMS hard disk (faster, more robust) and then use OS-level scripting to copy the backup files to a remote volume.

[AliB]

OK, hang on...I'm confused.

Why would my daily FMS validated and scheduled backup to external FW800 drive be "invalid"? I don't understand that. Why would this be any different to a backup to an internal disk? Why would FM Server allow the creation (and validation) of alternative backup destination paths in the first place, if they would result in dodgy, unreliable backups...?

The better approach is to backup directly to the FMS hard disk (faster, more robust) and then use OS-level scripting to copy the backup files to a remote volume

..is that not what I'm doing? FMS isn't backing up to a network or remote volume – it's doing it's thing on the Xserve system. Automator/applescript combo on the client then creates a 'local' clients backup, either on hard disk or USB stick.

I really do want to ensure that we have reliable backups, and also that I'm following 'best practice' as much as possible.

[Steven H. Blackwell]

Are you suggesting that there should be no users logged in to our Xserve at all...?

Exactly. That's the way it's supposed to be run.

Steven

[AliB]

But surely the Xserve has to be started up for services to be available? That means at least one user (preferably non-admin capable) has to be logged in, no?

[John May - Point In Space]

The Xserve has to be started up, but a user doesn't have to be logged in for daemon services to run.

- John

[AliB]

..and you learn something new every day!!

Presumably the Server Admin panel will still work? I must give this a whirl over the festive break.

[Wim Decorte]

If your backup is validated then you're fine. But backing up to a remote volume is and remains:

- slower (thus impacting the users longer)

- more prone to errors (extra hardware that can fail, mounts failing, permissions not set properly,...)

If you don't verify your backup and don't enable email notifications on backup complete then you might not now that your backup is invalid or simply didn't happen.

So FMI does not disallow it but it is not best practice (as cleary stated in the FM 10 certification training material).

It all comes down to understanding the risk, evaluating those risks for your environment and making a decision. (And ideally documenting that decision so that whoever comes after you can understand the what and the why).

[IdealData]

Never knew that myself either. I run VNC so I can otherwise admin my FMS - sometimes it's necessary.

How would you login on an Xserve that was waiting at the login point if there were no attached terminal and your only method of connection is through screen sharing?

[John May - Point In Space]

Screen sharing remains available when no user is logged into the local machine. So you'd connect via screen sharing, then log in as if physically in front of the machine.

- John