Why protecting NFS exports matters
An NFS export is rarely one team’s data. It is mounted by application servers, build agents, and user workstations at the same time, which means a single export often holds the working state of an entire environment.
The protections usually assumed to be in place cover less than expected:
- An export has no history: NFS serves the current state of a directory tree and nothing else. A file overwritten by a job that ran with the wrong arguments is simply the file now.
- Filer snapshots stay on the filer: appliance snapshot schedules are useful for quick rollbacks, but they live on the same device as the export. A failed controller, a wiped aggregate, or a decommissioned appliance takes both.
- Every client is a risk surface: an export is only as safe as the least maintained machine that mounts it. One compromised or misconfigured client can damage data that dozens of well-managed systems depend on.
- Deletions propagate instantly: a mistaken recursive delete on a mounted path is not a local mistake. It removes the data for every client at once.
For shared storage this central to daily operations, the export needs a copy that does not depend on the appliance serving it.
What happens when an export is compromised
NFS authorization is built on numeric user and group IDs supplied by the client. The server generally trusts what it is told, and access is controlled by which hosts are allowed to mount which exports.
If a client is compromised or an export is left too permissive:
- Claimed identity is granted identity: a host that can reach a permissive export can present whatever user ID it likes and read or write files as that user.
- Ransomware at mount speed: malware on one client encrypts files across every export that client has mounted, well beyond the machine it landed on.
- Root access to the tree: an export configured with
no_root_squashhands full control of the exported data to root on any permitted client. - Nothing to roll back to: once the live export and the appliance snapshots are both gone, there is no independent copy to recover from.
Plakar mitigates this by reading exports over NFS into a Kloset stored outside the file server. If the export or the appliance serving it is compromised, the snapshot history stays intact and recoverable.
How Plakar secures your NFS exports
Plakar uses NFSv3 directly, with no kernel mount and no need for root privileges or mount capability on the host, so it can back up an export from wherever it runs:
- Source Connector: walk an entire export or a single subtree, capturing files and directories with their size, mode, ownership, and modification time. Plakar encrypts and deduplicates the contents before writing them to a Kloset Store, independent of the server the export came from.
- Destination Connector: restore a verified snapshot to the original export, a replacement appliance, or a different environment, recreating the directory hierarchy and file contents.
This makes it possible to:
- Back up NAS appliances and Unix file servers without mounting anything or running as root
- Present a specific user and group ID to the server, so backups run with exactly the access they need
- Migrate shared storage to new hardware by restoring a snapshot onto the replacement
- Protect home directories and project trees that no single team has taken responsibility for
Plakar also lets you browse, search, and verify a snapshot before restoring, so recovering one deleted directory does not mean restoring an entire export.
Instead of trusting an export to the appliance that serves it, Plakar gives you an independent, encrypted, and verifiable history of the shared storage your infrastructure depends on.
