FortiGate Backups: Encryption and Password Masking Serve Different Jobs

Short answer

Keep a private recovery backup and a separate review copy with different labels and custody rules. Encryption protects access to a backup file. Password masking replaces selected secrets in an exported configuration; it does not preserve those original values for recovery or make the entire configuration safe to share.

This workflow concerns the documented FortiOS 7.6.6 GUI on an owned or customer-authorized FortiGate. Confirm the installed build, administrator permissions and available options. The shell example runs on an Ubuntu 24.04 workstation, not on the firewall. No restore, reset or firmware change is part of this preparation.

Decide the purpose before downloading

Create two explicit destinations in the work record:

Artifact	Purpose	Acceptance question
Private recovery candidate	Retain the configuration needed for a separately approved recovery	Is the scope correct, and can the authorized custodian retrieve the file and required credentials?
Masked review copy	Let an approved reviewer inspect configuration structure	Have remaining private details been reviewed for that recipient?

Calling a file “backup” does not establish its suitability for recovery. Calling it “masked” does not authorize disclosure. Keep those decisions attached to the file rather than relying on memory.

Record the appliance identity, actual firmware build, export time, intended scope and responsible custodian privately. Use a filename that distinguishes purpose and version without embedding a password. Do not overwrite the only known-good earlier artifact during a new export.

Prepare the private recovery candidate

Open the username menu and choose Configuration > Backup. Select Local PC and the FortiOS format for this workflow. If VDOMs are enabled, explicitly choose Global or the intended VDOM; a VDOM export is not an entire-appliance record.

Enable Encryption, enter and confirm its backup password, then save the file to the approved private destination. Keep Password mask off for this recovery candidate. Retain the password through the organization's approved secret store, separate from the ordinary work-order text.

The backup password is a recovery dependency. Other requirements can depend on the actual appliance, version and configuration. Record the intended restore target, and resolve compatibility or additional key requirements under the appropriate vendor procedure before scheduling a restore.

A completed download proves that a file was obtained. It does not prove that every later recovery dependency has been satisfied.

Prepare the separate review copy

Return to the backup dialog and create a distinct YAML export with Password mask enabled. Review the warning before saving it under a purpose-specific name. The documented mask marker is FortinetPasswordMask.

The masked copy is unsuitable as a substitute for the private recovery candidate: it cannot supply the original values that were replaced. Treat it as material for an approved review, with its own retention and distribution rules.

Inspect the remaining contents before sharing. Interface addresses, topology, names, comments and other operational details can still matter to confidentiality even when selected secrets are masked. Confirm the recipient and transfer destination in the work order; do not attach the file to a public ticket.

If the expected option is absent, stop and check the installed version's GUI and permissions. Do not guess an equivalent command or enable a new transfer service to get around the difference.

Record file integrity without exposing contents

On the authorized workstation, calculate a digest of the downloaded private file. Replace the example filename with the actual file:

sha256sum -- protected-backup.conf

Retain the digest, byte size, export time and private storage reference. Recalculate the digest after an approved transfer and compare it with the original record. This checks whether the bytes changed; it says nothing about whether the configuration will restore successfully.

Do not paste either file into a terminal transcript intended for general distribution. Store the recovery password in the designated secret store rather than beside the digest.

Verification note: criteria for backup preparation

The preparation record passes only when the two purposes are clearly separated, the private candidate has the intended scope and protected custody, and the review copy has been checked for residual confidential details. The authorized custodian must be able to retrieve the required password without depending on the departing operator.

These are verification criteria, not a claim that a FortiGate backup was restored or tested. Actual recovery validation requires its own compatible target, authorized window, vendor procedure and post-restore checks.

Use the FortiGate USB auto-install guide when separately planning that recovery path, and retain the preparation checklist in the CliDeck workspace.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

• Several commands or checks must be repeated safely.
• Another engineer, customer, onsite technician, or vendor may need context.
• The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

• You do not own or have authorization to work on the device.
• The device is outside your approved change, recovery, or processing scope.
• The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
• The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

• Purpose
• When to use it
• When not to use it
• Target system or device
• Access path
• Read-only checks
• Change steps
• Expected output
• Stop conditions
• Rollback steps
• Verification steps
• Handoff notes
• Final summary format

Workflow

• Define the purpose, target device, access path, and approved scope.
• Run read-only checks first and record the expected healthy state.
• Execute commands from the runbook or handoff plan while watching for stop conditions.
• Verify the final state with independent checks.
• Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

• The target device or system is correct.
• Read-only checks were captured before the work.
• Stop conditions and rollback notes were available before changes.
• Final verification checks match the expected result.
• Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

• Starting commands before confirming the target device and scope.
• Skipping read-only baseline checks.
• Copying commands without expected output, stop conditions, or rollback notes.
• Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides

• FortiGate CLI Packet Capture: Use a Filter, a Count, and a Stop Condition - Run a narrowly filtered FortiGate CLI packet capture with a finite count, an operator deadline, private logging, and explicit offload limits.
• Junos Interface Down: Separate Admin State from Link State - Read Junos Admin and Link states separately, preserve physical interface detail, and choose the next investigation without changing the baseline.
• Cisco Catalyst Interface Errors: Measure the Change, Preserve the Baseline - Compare two Catalyst interface-counter snapshots without clearing the baseline; distinguish new receive errors, congestion, and counter discontinuities.
• Junos Configuration Diff: Review the Candidate Before You Commit - Review a Junos candidate diff against the active or rollback baseline, interpret changes, and avoid accidentally confirming a pending rollback timer.
• Junos Rescue Configuration: Save, Review, and Restore a Known Baseline - Save a reviewed Junos rescue baseline, inspect its contents, load it into the candidate, review the diff, and activate it through an approved commit.