TNS Panel
Get started

Backups & restore

TNS Panel backs up with restic: encrypted, incremental and deduplicated. This page covers what is backed up, how to restore, and how to point copies at a destination of your own.

What the node does

  • The node backs up every account, whether or not the client has a backup plan, and including suspended accounts. Losing a client's data is the worst possible incident, so this never depends on a plan.
  • One repository per node. Its key belongs to the operator; clients never receive access to the repository.
  • A backup contains the client's home directory and its databases (MariaDB and PostgreSQL, dumped consistently), plus the database identities as hashes so passwords survive a restore. Mail is part of the home directory.
  • Mounted external storage (~/storage) is not included in home backups or malware scans.
  • Retention on the node is set by the operator on the destination. Each client's backup plan only limits how far back that client can see and restore (0 means no limit). Without a plan a client can neither browse nor trigger backups; the page says so.

Set up the destination (admin)

Backups → Destinations (CLI: panel destino-guardar). The node needs at least one destination before any backup exists: local disk, SFTP, S3, B2, Azure, GCS, Swift or REST directly, or FTPS and consumer cloud storage through rclone. Both restic and rclone are installed by the installer with pinned checksums.

  • Credentials are stored encrypted with the node's master key and never appear in logs.
  • A destination's repository key cannot be changed from the panel: restic would stop reading the existing copies. To change it, create another destination.
  • A destination that points at loopback, private networks, link-local or cloud-metadata addresses is refused.
  • Removing a destination only stops using it; the data in the repository is never deleted by that action.
  • For SFTP, the server fingerprint is confirmed by a person before the first copy (see below).

Restore by item (client)

Backups → Restore:

  1. Browse a snapshot and choose files or folders, or one database.
  2. Choose the mode. The default is next to the original: nothing is overwritten and the files appear in a new folder in your home (a database dump is left as an .sql file there). Over the original puts the files back in place and covers what is there.
  3. Confirm.

Rules worth knowing:

  • A restore is refused if it would not fit in the client's disk quota. An item that is not in the snapshot is an error, not a success.
  • A database is restored whole, never partially.
  • Restored files are always owned by the client and the panel never follows links the client placed.
  • Only one restore per client runs at a time, and it excludes the client's own backup run.
  • An admin or reseller can restore for a client from the client's account, without time-window limits.

Large archives: Download builds a .tar.gz of a snapshot in the background. It expires, and a client can have one at a time.

Back up now

Allowed for clients with a plan, with a wait of one hour between manual runs. If it is refused with "backup in progress, retry", another backup or restore of that account is running.

Your own destination (client)

Backups → My destination adds a second, independent repository owned by the client:

  • Types: SFTP, S3 or B2 directly; FTPS and Google Drive, OneDrive, Dropbox or Box through rclone. FTP always uses explicit TLS. Being a separate repository, it does not deduplicate against other clients.
  • SFTP: the panel generates a key pair for the destination and shows the public half. Add it to your server, then confirm the server fingerprint the panel shows. The destination is not used until you confirm it, and if the fingerprint later changes the copy fails with an explicit message instead of silently trusting the new key.
  • Cloud tokens can expire or be revoked by their owner, and the copies then stop until the token is refreshed. The advisor (Server → Recommendations) reports destinations that have not run recently.
  • Runs have a time limit of a few hours and back off after repeated failures; editing the destination resets the back-off.

Verify your backups

A backup that was never restored is a hope. Restore a file next to the original from time to time, and check Server → Recommendations for destinations that stopped running or whose last good run is older than 48 hours.

See also