Jacob Taylor, April 18, 2024, FileMaker Training Videos

Menu

1. Introduction
2. Pre-Emergency Setup: Building a Resilient Backup Strategy
   • Backup Frequency and Scheduling
   • Testing Backup Integrity
   • Ransomware Protection
3. Immediate Actions After a Crash
   • Confirm the Outage
   • Review the Admin Console
   • Avoid Using Crashed Files
4. Restoring from Backup: Key Steps
   • Identify the Last Good Backup
   • Copy the Backup Files
   • Restore the Backup
5. Post-Restoration Checks
6. Proactive Configuration for Future Protection
   • Disable Auto-Open of Files After a Crash
   • Conduct Regular Server Audits
7. Handling Complex Scenarios: What If Backups Fail?
   • Scenario: No Good Backup Available
   • Scenario: SSL Certificate Failure on macOS
8. Conclusion: Best Practices for FileMaker Server Emergency Response
9. Check List
10. Video

Introduction

To top

FileMaker Server is a critical tool for managing databases, but like all server systems, it is vulnerable to crashes, hardware failures, and software issues. To avoid operational disruptions, it’s vital to have a well-planned emergency restoration strategy in place. This detailed blog post will guide you through every step you need to take to secure your server, handle crashes, and recover efficiently without data loss.

Why It Matters:

• Data Integrity: A well-executed recovery process ensures that data remains intact and accessible.
• Business Continuity: Quick, reliable restoration minimizes downtime, preventing operational delays and financial losses.
• Proactive Measures: Preparing for an emergency in advance significantly reduces the impact when a crash occurs.

By the end of this post, you’ll know exactly what steps to take before, during, and after an emergency to ensure that your FileMaker Server is secure and recoverable.

Pre-Emergency Setup: Building a Resilient Backup Strategy

To top

One of the most important steps in any emergency restoration process is ensuring that you have a solid backup strategy in place. Backups are the lifeline for recovery, and without them, data loss is inevitable.

Backup Frequency and Scheduling

• Hourly Backups: Set up backups to occur hourly. This minimizes data loss to a maximum of one hour, ensuring that any lost work is recoverable.
  • Best Practice: If your system processes critical data throughout the day, consider more frequent backups (e.g., every 15-30 minutes).
  • Custom Scheduling: If your database operates 24/7, stagger backups to avoid performance lags. For example, schedule some backups at 15 minutes past the hour and others at 45 minutes.
• Different Backup Locations: Never rely on a single backup location. Utilize:
  • Primary Local Disk: The first line of defense should be a local backup stored on the same server.
  • Secondary Local or Network Attached Storage (NAS): Store a second backup on a different internal drive or NAS.
  • Remote/Cloud Storage: Use cloud services like Amazon S3 to store backups in a secure, off-site location.
  • Redundant Off-Site Backups: Maintain copies of critical data in geographically separate data centers to protect against natural disasters, fires, and theft.

Testing Backup Integrity

It’s not enough to simply create backups; you need to ensure they are viable. Regularly test backup integrity by restoring data to a test environment.

• Weekly Test Restorations: Perform restoration tests every week to ensure your backups are working as expected.
• Audit Logs: Maintain a log of backup tests, noting the time taken and any issues encountered.
• Differentiating Backups: Label each backup (e.g., hourly, daily, weekly, monthly) and ensure you’re not overwriting important data from long-term backups.

Ransomware Protection

Ransomware attacks have become more frequent, targeting backups as a first step. Here’s how you can protect your FileMaker backups from ransomware:

• Off-Site Backups with Immutable Settings: Use Amazon S3’s ransomware protection. This prevents any deletions or alterations of backups for a set period (e.g., 30 days), ensuring that even if an attack occurs, your backups remain intact.
• Network Segmentation: Avoid keeping backups on the same network or server that is used for your daily operations. Isolate the backup server to protect it from ransomware.
• Data Encryption: Always use Encryption at Rest (EAR) and Encryption in Transit for backups. This ensures that even if the backups are compromised, the data within them cannot be easily accessed.

Immediate Actions After a Crash

To top

When a crash occurs, immediate action is required to prevent further data corruption and restore service quickly. Follow these steps to minimize damage and recover efficiently.

Confirm the Outage

Before taking any drastic steps, confirm that the issue is indeed a server crash:

• Ping the Server: Use a ping command or network diagnostic tool to check if the server is still responding.
  • Ping Results: A successful ping response indicates that the hardware and operating system are still functional, and the problem might be within the FileMaker Server application itself.
  • No Ping Response: Indicates a total system failure, possibly due to hardware or power issues.

Review the Admin Console

• Access the Admin Console: If the server is accessible, log into the FileMaker Admin Console.
  • Check the Status: Are the databases still running, or have they been closed automatically? Closed databases are a good sign, as the system has likely preserved their integrity.
  • Review the Logs: Look through the server logs to identify the time of the crash, any unusual activity, and any related errors.

Avoid Using Crashed Files

• Never Reuse Crashed Files: If the crash occurred while the database was open, never attempt to reopen it directly. Using a corrupted or partially written file can lead to cumulative damage.
• Manually Close the Files: If the files are still shown as open, manually close them from the Admin Console or using a CLI command to ensure they are properly shut down before restoration.

Restoring from Backup: Key Steps

To top

Once you’ve confirmed the server crash and avoided using crashed files, the next step is to restore from the most recent, unaffected backup.

Identify the Last Good Backup

• Examine Server Logs: Review the logs to identify when the last successful backup occurred. Look for a “Completed Successfully” log entry close to the time of the crash.
• Backup Validation: Ensure that the backup you’re restoring is complete and contains no errors. If the server crashed during the backup process, that backup may be corrupted.

Copy the Backup Files

• Manual Copying: On macOS and Linux systems, avoid dragging and dropping files, as this can interfere with hard linking. Always use copy and paste or the appropriate CLI commands to ensure file integrity.
  • Hard Linking Explained: Hard links allow FileMaker Server to efficiently reference unchanged files between multiple backups. If you drag and drop files incorrectly, you risk breaking these links, resulting in incomplete backups.
• Permission Checks: After copying the backup files, ensure they maintain the correct file permissions, particularly on Windows systems with Active Directory settings.

Restore the Backup

• Move the Backup Files: Place the copied backup files in the designated FileMaker directory, ensuring they overwrite the crashed files.
• Server Reboot: Restart the server to ensure all FileMaker processes start fresh, with the newly restored files. Avoid reusing open files from the crash.

Post-Restoration Checks

To top

After restoring the server, it’s essential to verify that everything is functioning properly before allowing users back into the system.

• Open the Databases: Use the Admin Console to reopen the databases. Ensure that all files open without errors and are accessible to users.
• Monitor Logs: Keep an eye on the server logs for any new errors or warnings after the restoration. These can provide insight into lingering issues that need to be addressed.
• SSL Certificate Check: On macOS servers, crashes can sometimes corrupt SSL certificates. If users encounter security warnings or are unable to connect, verify that the SSL certificate is still valid, and re-import if necessary.

Proactive Configuration for Future Protection

To top

To prevent future incidents from escalating into major disruptions, implement these proactive measures.

Disable Auto-Open of Files After a Crash

• Auto-Open Setting: In the FileMaker Server Admin Console, ensure that the setting to automatically reopen files after a crash is disabled.
  • Why It Matters: If the files were not properly closed before the crash, reopening them automatically can cause further corruption. Disabling auto-open gives you time to assess the situation before any files are opened.

Conduct Regular Server Audits

• Health Checks: Schedule regular health checks for your FileMaker Server to monitor performance, backups, and overall system stability.
• Audit Backup Policies: Review backup policies regularly to ensure they are being followed and that backups are being stored in secure, separate locations.
• Test Restoration Processes: Simulate server crashes and test the restoration process at least once a month to ensure your team is familiar with the procedures.

Handling Complex Scenarios: What If Backups Fail?

To top

Sometimes, even with the best preparations, things can go wrong. Here’s how to handle the most complex scenarios.

Scenario: No Good Backup Available

If all available backups are corrupted or unusable:

• Contact Claris Support: In severe cases, where backups are unusable, reach out to Claris FileMaker support. They may be able to manually repair the database.
• File Recovery Tools: In some cases, using third-party file recovery tools or database repair software can help recover portions of the data. However, always consult an expert before attempting this.

Scenario: SSL Certificate Failure on macOS

If your SSL certificate fails after a crash:

• Navigate to SSL Storage: On macOS, go to /Library/FileMaker Server/SE Store/ and delete the existing SSL files.
• Re-Import SSL Certificate: Use the Admin Console to re-import the SSL certificate and restart the server.

Conclusion: Best Practices for FileMaker Server Emergency Response

To top

By following these detailed steps and maintaining a proactive approach, you can ensure that your FileMaker Server is prepared to handle any emergency. Remember:

• Backups are Essential: Ensure that your backups are frequent, stored in multiple locations, and regularly tested.
• Never Use Crashed Files: Always restore from the last known good backup to prevent further data corruption.
• Keep Your Server Updated: Stay current with FileMaker Server software updates to minimize security risks and system bugs.

By planning ahead and having a clear restoration plan, you can ensure that your FileMaker Server environment remains secure, reliable, and resilient in the face of unexpected disruptions.

Check List

To top

Emergency Restoration Considerations for FileMaker Server:

Additional Notes:

• Frequency of Checks: Critical systems should be checked more frequently. Systems that handle sensitive data should have multiple layers of backup, tested daily if necessary.
• Permissions on Windows Servers: Ensure that Active Directory permissions are correctly applied when restoring backups. FileMaker databases require specific access levels to function correctly on Windows servers.
• Restoration Testing: Ensure restoration tests are done in a non-production environment to avoid disrupting live operations.

This checklist covers all necessary steps to ensure the safe restoration and ongoing protection of your FileMaker Server.

Video

To top