Backup and Recovery

FlexFS stores metadata and block data separately, each with its own durability characteristics and backup strategies.

Data durability model

Data type	Storage location	Durability
Block data (file contents)	Cloud object storage (S3, GCS, Azure, OCI)	Provided by the cloud provider’s SLA (typically 99.999999999% / 11 nines for S3).
Metadata (inodes, directory entries, attributes, ACLs)	Metadata server local database	Depends on the local disk and your backup strategy.
Configuration (volumes, tokens, accounts, stores)	Admin server local database	Depends on the local disk and your backup strategy.

Block data stored in cloud object storage is inherently durable — you rely on your cloud provider’s durability guarantees. The primary backup concern is the metadata database on the metadata server and the configuration database on the admin server.

Metadata backup

Database folder

The metadata server stores its database in the folder specified by --dbFolder (default location set during init). To back up the metadata:

Filesystem-level copy: Stop the metadata server, copy the entire database folder, then restart.
Terminal window
```
sudo manage.flexfs stop
cp -r /path/to/meta/db /backup/meta-db-$(date +%Y%m%d)
sudo manage.flexfs start
```
Filesystem snapshots: If the database resides on a volume that supports snapshots (LVM, ZFS, EBS snapshots), take a snapshot while the server is running. The database is crash-safe and will recover on startup.
Cloud instance snapshots: For cloud-hosted metadata servers, use your provider’s instance or disk snapshot feature (e.g., AWS EBS snapshots, GCP persistent disk snapshots).

Admin server backup

Apply the same strategies to the admin server’s database folder. The admin server stores volume definitions, accounts, tokens, block stores, and metadata stores.

cp -r /path/to/admin/db /backup/admin-db-$(date +%Y%m%d)

Time-travel recovery

FlexFS supports time-travel mounting via the --atTime flag, which lets you mount a volume at a specific point in time. This is powered by data retention — both metadata and block data are preserved for the configured retention period.

Mounting at a point in time

mount.flexfs start my-volume /mnt/recovery --atTime 2026-03-15T10:30:00Z

The --atTime flag accepts an RFC 3339 timestamp. The mount is automatically set to read-only mode.

Use cases

Scenario	How time-travel helps
Accidental deletion	Mount at a time before the deletion, copy the files to the current mount.
Data corruption	Mount at a known-good time and compare or restore files.
Auditing	View the exact state of the filesystem at a specific date and time.
Compliance	Demonstrate data state at a particular point for regulatory requirements.

Retention configuration

Time-travel range depends on the volume’s retention setting, which controls how long deleted data is preserved. Configure retention when creating or updating a volume in configure.flexfs.

Disaster recovery procedures

Scenario: Metadata server disk failure

Provision a new server.
Install flexFS binaries (manage.flexfs download meta --install).
Restore the metadata database from your most recent backup.
Run meta.flexfs init creds with the same admin server address and token.
Start the metadata server.
Mount clients will reconnect automatically.

Scenario: Admin server disk failure

Provision a new server.
Restore the admin database from backup.
Start the admin server.
Metadata servers and mount clients will reconnect.

Scenario: Block data loss in object storage

Block data loss in a major cloud provider’s object storage is extremely rare. If it occurs:

Files referencing lost blocks will return I/O errors on read.
Use analyze.flexfs to identify affected files.
Restore from external backups if available.

Backup schedule recommendations

Component	Backup frequency	Retention
Metadata server database	Daily (minimum), hourly for critical data	30 days
Admin server database	Daily	30 days
Block data	N/A (cloud provider durability)	Per your data lifecycle policy