Disaster Recovery Planning with FortiAuthenticator: Backup, Restore, and Testing Essentials

Theres’s something about that third cup of coffee — the one that snaps me out of my mid-morning daze — that always gets me in a lather about disaster recovery. Especially with FortiAuthenticator, a key puzzle piece when it comes to cybersecurity. I have been in and out of business since the early 90s — started as a network admin in ’93… you know, those days when voice and data over PSTN, plus some Slammer on them was the nightmare. While I run P J Networks today and assist banks in upgrading to zero trust architectures, I keep returning to our basic: backups and restores. You’d think it’s straightforward — but nope, it’s where the majority of people get tripped up, especially when the proverbial hits the fan.

Scheduling Backups: Your Primary Line of Defense

Here’s the thing – if you’re not automating the backup of your FortiAuthenticator config and user data, you might as well be leaving the keys under the mat. Your entire authentication logic resides within that config file: your authentication policies, your user groups, as well as the all-important certificates – if you lose it, the whole of your authentication infrastructure might be regarded as something tasting of burnt bread.

We automate backups at PJ Networks and run them nightly. It’s not glamorous or sexy, but regular scheduling is a must. I remember, for example, years ago, during some network downage caused by a bad patch, the crew running around trying to execute backups the old fashioned way. It was a mess. So, do not wait for that mythical quiet period to learn your last good backup was three months ago.

• Daily/Twice daily for config and user data
• Automated Exports using the built-in CLI commands/API of FortiAuthenticator
• Add timestamps to filenames when backing up — you need to know when those files are from.

Bonus tip: and don’t forget to backup config—include your user DB exports. This is something that a lot of people forget — they go, “the config’s enough.” But user data (i.e. group memberships, settings) can change daily, especially in larger orgs.

Off-Site Storage: Not All Eggs in One Forti Basket

The analogies won’t quit, but you can sort of think of a backup as bags of flour: If you keep all of your flour in one pantry and your house burns down, there go your biscuits.

It is important to keep your backups off site. At P J Networks, the nightly backups are sent to a secure offsite server, physically removed and encrypted, under strict access control. Because if there’s a flood in your data center, or if, God forbid, ransomware holds everything on your local network hostage, that’s how you’ll get back on your feet.

Remember: Cloud storage is all well and good — but don’t entrust just any “AI-powered” backup service that promises magic and zero effort with your digital life. Most of the time? They’re marketing fluff. You need transparency and control, not a black box.

Important information about offsite retention:

• Encrypt your transfers (i.e. use SCP/SFTP)
• Rotate backups and keep a few versions
• Check that the security policies are enough in your offsite storage

Restore Procedures: Backups Aren’t Enough On Their Own

This is the point where a lot of admins start to sweat. It’s not just a matter of popping in a backup file and crossing your fingers.

Just a few weeks ago, I assisted with zero-trust upgrades at three different banks. You know what kept throwing them off? Bringing back FortiAuthenticator authentications with no impact was a huge pain. If your restore process means hours of downtime, you’re doing it wrong.

A good restoration approach goes something like this, at a high level:

• Ensure you have backups of config and user DB.
• Have backup copies of both config and user db.
• Go to GUI and delete all packages / remove them.
• Disconnect serial.
• You can turn the power on to the 64-factory.
• Load up your VM with the 2.1 image.
• Re-install/spin up a new FortiAuthenticator appliance/VM approximately the same as production dimensions.
• Bring your backup back using CLI or GUI.
• Verify that services are running and that user authentications work correctly – do NOT skip this step.

If you have federated identity providers, or are integrating with multi-factor authentication (MFA), things just got a little more challenging. A restore that fails part way could leave the users locked out or unable to authenticate.

Pro tip: keep a FortiAuthenticator ‘warm standby’ that recent backups are restored to regularly – this allows you to ‘passively’ test restore and limit the blast radius.

DR Testing: Not a Choice. It’s Survival.

Look, I get it. I can think of few things as thrilling as Disaster Recovery Testing. But to skip it is to be forever driving your car without checking the brakes.

In PJ Networks we do restore drills every quarter. Every quarter, we select backups at random, fire up test environments and perform full restores. The result? But when the true test comes, we remain steady. We execute.

Common pitfalls I’ve seen:

• Corrupt or incomplete backup files
• Test recovery was only on paper, not in fact environments
• Restored ACLs and integrations breaking down after restoration

Key learning from DR testing rounds:

• Record everything that occurs in restoring the database.
• Train multiple team members — it shouldn’t be a one-person show.
• Maintain logs and feedback loops for ongoing improvements.

Quick Take — For Those Short On Time:

• Automate FortiAuthenticator nightly backups (config + user db).
• Keep encrypted backups offsite, rotating them out.
• Periodically, verify that the restore process is working as expected on same hardware/VM.
• Do quarterly DR exercises for confidence and incident discovery.

One last ranty thing before I call it a night — A password policy a solution does not make. I’ve seen banks with 30-character complexity rules still get fished or tricked into handing over a credential. Fology FortiAuthenticator chimes in here for MFA and identity validation, but the bottle-neck is the human element? Still the weakest link.

One thing I’ve learned — you have pretty much got to protect your identity infrastructure with decent backups and the kind of disaster-preparedness stuff that isn’t “just IT hygiene” and actually feels more like mission-critical. Because when the network is dark, your users still need to get in. No compromises.

So, whether you are running security at a mom-and-pop shop or overseeing protection for a bank, don’t leave it to a disaster to put these tactics to work. Because by that time, it’s jeopardy on your watch. And to be honest, nobody needs that kind of heartburn.

Alright, enough from me. Time for coffee number four. But if you’d like to banter about FortiAuthenticator, DR plans, or some random “AI-powered” snake oil, well you know where to find me.