Jump to content

FMS Backup Strategy Best Practices


This topic is 2219 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

hello. I am extremely new to FMS. Is there a document anywhere that has best practices on server setup and Backup strategy in particular? Weekly full? daily? hourly; incremental backups? are there transactional backups? What are the issues, corruption issues? mistakes to avoid?

We need this urgently. Believe that the server was not initially set up properly and now, of course, I have inherited the issue :) We are running FMS 14

any help would be appreciated,

Link to comment
Share on other sites

In the server control panel you will see Schedules; that's where you configure scheduled backups.

 

As for white paper I have not yet seen a good one.

 

Personally I prefer ZFS for storage as this allows for system snapshots, rollback, compression, and separate backups rooted in the snapshots. ZFS has a mac implementation named o3x.

Edited by ggt667
Link to comment
Share on other sites

Your backup strategy needs to be set based on the answers to these two questions:

- how much data are you willing to lose?  This determines your 'restore points', how many backups you need to make

- how much down-time are you willing to incur?  This determines your 'restore time', your procedure for how quickly you need to be able to restore the files

The answers also determine obviously how much effort and money you'll need to invest in making this so.  

 

Incremental backups are as close to 'transactional' backups as we have in FM.  In FM they are called "progressive backups" and they keep 2 backup sets only.  Progressive backups are meant to be part of the overall backup strategy, and not to be the only backup used (mainly because it offers that limited number of restore points).

 

Link to comment
Share on other sites

  • Newbies

thank you ggt667. I will take a look. but still hoping for documentation that I can point to as recommendations.

thank you Wim Decorte. I am going to get those 2 questions answered as soon as possible. But let's guess, this is marketing, so the answer will be none and 0. what would be the best strategy? Full daily, incremental hourly or more frequently? to a local drive. then multiple times a day move the backups to the SAN?

 

 

Link to comment
Share on other sites

Good server deployment.

RAID for Live database (recommended not required)
RAID for backups (recommended not required) 
these are for uptime operations when drive does fail you can get thru the day and can replace drives at end of day, or swap with a spare drive ( but rebuilding array may degrade services - depending on how complex your solution and how many users you have)

Progressive Backups for rolling back faster to a good state to should a user or developer accidentally trashes some records - most likely this would be the least in terms of lost data. But does require that you are informed as close to the discovery as possible - your full backup may actually may have the desired restore state.

Full backups - Backing up hourly, weekly, monthly will require more storage to maintain files - and if you have many backups thru the work hours a second device on its own controller may be best for performance. 

Retention - This is depended on your company policy and preference - you may wish to go way back in time because someone did something and are just now coming forward where, you may need to restore layouts or data, or just want to take a trip down memory lane.

Offsite - you are not really backed up unless you have an offsite backup - You can use services / software that "backup a backup" to another offsite location - either controlled by you or a trusted backup company. - For third party backups you should really have all your files using Encryption at Rest (EAR)

Spot check - Drive failures, and data losses don't call you up and schedule an appointment they can and will happen - usually when you have other plans. However you can't just set up your backups and believe everything is working - the day you restore only to find out the file is corrupted or didn't backup a file - or remote containers etc. You need to be proactive and schedule at least a quarterly spot check where you pull backups from your different locations and open the files up and spend some time to review that your data and schema is indeed recoverable. 

 

Link to comment
Share on other sites

  • Newbies

thank you Ocean West. I've also read all the articles for "backing up your data Overview" Knowledge Base article https://support.filemaker.com/s/answerview?language=en_US&anum=13793  and all the related links shown there.  I now know just enough to be dangerous!

Link to comment
Share on other sites

I manage a Windows 2K8 R2 FM16 server. Full backups are done nightly (daily: Mo/Tu/We/Th, weekly on Fr, none on Sa/Su as no data gets changed then), with progressive enabled. C: drive is the OS drive and holds the Applications. D: drive is where the databases live. E: drive is where the backups are stored. C:, D: and E: are partitions on a RAID drive. A batch script copies backups nightly to a NAS. The NAS copies FM backups (along with other backups) to another NAS. The other NAS backs up to AWS. Everything is fully automated and requires no human intervention, aside from the checks. If backups fail, I get alerted. Generally, no news is good news, but the system is still regularly checked.

Link to comment
Share on other sites

  • Newbies

Thank you OlgerDiekstra. That is a good plan. I appreciate all the replies I have received. All have excellent info for me. Thank you!

Link to comment
Share on other sites

This topic is 2219 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.