The Artica File Server appliance can act as its own backup NAS.
It embeds Plakar, an engine that writes versioned, deduplicated and encrypted snapshots into a store called a Kloset.
Three objects make up the whole model, and it is worth learning them in this order:
- Repository
Where snapshots are written.
It is a Kloset store, held either on a local directory of the appliance or on a remote backend (SFTP, Amazon S3, S3-compatible storage, an rclone remote). - Source
What gets backed up: a directory tree of the appliance, or a database. - Job
The pairing of one source and one repository, with a schedule.
¶ A repository
A repository is created once and then reused.
Everything else — sources, jobs, retention, restores
Is built on top of it, which is why creating your first repository is the first thing to do.
¶ Why use it
- The data leaves the appliance encrypted.
A repository is protected by a passphrase; the appliance seals that passphrase in its own secret store and passes it to the engine through the environment only
Never on a command line, never in a log.
A stolen disk or a compromised remote bucket yields ciphertext.
- Deduplication and compression are on by default.
Repeated content is stored once.
A daily snapshot of a file share that barely changes costs close to nothing.
- Snapshots are verifiable.
Each one can be checked on demand, and the check tells you whether the snapshot is actually readable not merely present.
- Restores are selective.
You can browse a snapshot and restore a single path instead of the whole tree, into a destination you choose.
- Retention is a dry run first.
The policy always shows you the exact list of snapshots it would remove before anything is deleted, and automatic deletion is disabled until you enable it.
- It is driven from the web console.
No shell is required for day-to-day operation: repositories, jobs, snapshots, restores and logs each have their own page.
¶ Use cases
- Protect the shares of the file server.
The appliance backs up its own share directories on a schedule, to a repository held on a dedicated disk or volume.
- Keep an off-site copy.
The same content can be written to a repository on Amazon S3, on an S3-compatible service (MinIO, Wasabi, Scaleway…), on a remote SFTP host, or on any rclone remote already configured on the appliance.
- Serve as a backup target for other machines.
The Plakar service can expose one repository over the network, so other hosts push their snapshots into the appliance.
- Recover a single file.
A user deleted a document three weeks ago: browse the snapshot of that date and restore just that path to a temporary directory.
- Bound the storage cost.
A retention policy keeps the last N snapshots, or the last N days, weeks and months, and reclaims the rest.
¶ Before you start
- The backup service must be installed — see Install the backup service.
- You need a directory or a volume with enough free space for the snapshots.
It does not have to exist yet, but its parent must. - You need to choose a passphrase and keep it outside the appliance.
It protects everything the repository holds.
¶ Next steps
- Create your first repository and bucket
The storage area, the bucket, the passphrase — and the check that initialises the store. - Repository pools
Group several repositories under one name and declare the storage intent for them.