FortiWeb Lesson 15: Production Rollout, Backups and High Availability
FORTIWEB CLASSROOM • LESSON 15
Level: Advanced · Study and lab: 90 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP
FortiWeb course guide · FortiWeb training block
Make the change recoverable
A successful lab request is not a complete production-readiness test. The bookshop needs browsing, login, checkout, administrative, mobile, and API workflows to work. Protection must also survive failure and recovery.
Write the rollout plan
Record the firmware, licensed capabilities, server-policy scope, active profile, rule actions, shared objects, exceptions, learning status, and regression results. Define service indicators such as transaction success and latency alongside security detections. Identify the operator, application owner, monitoring destination, and rollback trigger.
Observe representative business activity before enforcing a newly introduced check. A quiet period does not prove coverage of batch jobs or uncommon workflows. Use limited exposure where the architecture supports it and verify that the intended population really receives the change.
Back up more than a rule
FortiWeb backup workflows cover configuration and protection-profile artifacts, with additional dependencies to consider. Keep certificates/private keys, application keys where required, and other recovery components according to the release's documentation. Configuration backups are not log/report archives. Encrypt sensitive backup artifacts and restrict access.
Guided recovery lab
- Create a baseline backup and a record of all required recovery components.
- Make one small, documented lab change and verify it.
- Restore the baseline in an appropriate isolated recovery environment using the supported procedure.
- Verify the server policy, profile associations, certificates, dependencies, and response behavior.
- Rerun normal and negative traffic tests and check logging.
Expected result: recovered behavior matches the intended baseline. A successful upload/import message is only an intermediate result.
High availability is a separate design
HA modes, member compatibility, licensing, heartbeat links, synchronization, and traffic routing must be designed together. Read the requirements for the selected platform; do not assume a trial VM supports the intended cluster. Configuration synchronization is not equivalent to preserving every connection.
In a supported HA lab, verify member health and configuration consistency, perform a controlled failover, then test the application and security behavior on the new traffic owner. Check event destinations and recovery paths. Record which sessions may be disrupted.
Knowledge check
Does an HA pair replace a tested backup?
Instructor answer
No. A mistaken configuration can propagate to a peer. Availability, synchronization, and recovery address different failure scenarios and must each be validated.
Official reading
Independent training, not affiliated with Fortinet. Examples use an authorized isolated lab with synthetic data. The lab steps and expected outcomes have not been executed on a FortiWeb appliance for this publication. Firmware, platform, operating mode, licensing, and subscriptions affect behavior; follow the documentation for your exact build. References use 8.0.x examples and do not constitute an upgrade recommendation.
← Previous FortiWeb lesson · FortiWeb course guide · Next FortiWeb lesson →
Comments
Post a Comment