Back Up Your Linux VPS with Plakar

10 min read·Matthieu·DebianMySQLDeduplicationUbuntuPlakarEncryptionBackupPostgreSQL|

Install plakar on Debian 12 or Ubuntu 24.04, create an encrypted deduplicated backup store, back up filesystem paths and databases via stdin piping, schedule automated backups, and restore files or full database dumps.

What is plakar and why use it for VPS backups?

Plakar is an open-source backup tool written in Go. It ships as a single binary with built-in encryption, deduplication, a web UI, and a native scheduler. Encryption is on by default when you create a repository. Plakar backs up filesystem paths, database dumps via stdin piping, and S3 buckets. The project joined the Linux Foundation and CNCF in January 2026.

If you already use restic or borgbackup, here is where plakar differs. Restic requires an external tool like rclone for remote sync and cron for scheduling. Borgbackup needs a borg server on the remote side and has no built-in web UI. Plakar handles all of this natively: plakar sync replicates between stores, plakar scheduler runs backups on intervals, and plakar ui launches a browser interface for snapshot browsing.

Both restic and plakar support stdin backups for piping database dumps. Borgbackup does not. All three deduplicate. Plakar enables encryption by default when creating a repository, while restic and borgbackup let you create unencrypted repos.

This guide covers local backups on a single VPS. For offsite replication to a remote server, see Offsite Backup and Replication with Plakar.

What do you need before starting?

You need a VPS running Debian 12 or Ubuntu 24.04 with root or sudo access. A Virtua Cloud VPS works well for this. You also need SSH access configured with key-based authentication and at least 10 GB of free disk space for the backup store.

If you plan to back up databases, install MySQL or PostgreSQL first. Those installations are not covered here.

All commands in this guide run as root. If you use a sudo user, prepend sudo to each command.

How do you install plakar on Debian 12 or Ubuntu 24.04?

Add the official plakar apt repository, import the GPG signing key, and install the package. The same steps work on both Debian 12 and Ubuntu 24.04. The apt package handles updates automatically through your normal system upgrade cycle.

Install the prerequisites:

apt update
apt install -y curl gnupg2

Import the GPG key and add the repository:

curl -fsSL https://plakar.io/dist/keys/community-v1.1.0.gpg | gpg --dearmor -o /usr/share/keyrings/plakar.gpg
echo "deb [signed-by=/usr/share/keyrings/plakar.gpg] https://plakar.io/dist/repos/deb/ stable main" | tee /etc/apt/sources.list.d/plakar.list

The GPG key is pinned to the repository via signed-by. Apt only trusts packages signed with that specific key. This prevents a compromised third-party repository from injecting packages into your system.

Install plakar:

apt update
apt install -y plakar

Confirm the installation:

plakar version

plakar/v1.0.6

How do you create an encrypted Kloset store?

A Kloset store is plakar's storage backend. It holds all snapshots in deduplicated, encrypted form. Every data block is encrypted before it hits disk. The Kloset engine deduplicates before encryption, so identical blocks across different snapshots are stored only once while still being fully encrypted at rest.

Create a store at /var/backups/plakar:

mkdir -p /var/backups/plakar
plakar at /var/backups/plakar create

Plakar prompts for a passphrase:

repository passphrase:

Generate a strong passphrase:

openssl rand -base64 32

Save this passphrase in a password manager or a separate secure location. If you lose it, you lose access to every snapshot in the store. There is no recovery mechanism.

Set permissions on the store directory so only root can access it:

chmod 700 /var/backups/plakar
ls -la /var/backups/

drwx------  5 root root 4096 Mar 20 10:00 plakar

The default store location is ~/.plakar if you omit at <path>. On a server, use a dedicated path like /var/backups/plakar so it does not depend on a user's home directory.

How do you back up filesystem paths with plakar?

Back up the directories that matter on a VPS: /etc for system configuration, /home for user data, and /var/www for web content. Each plakar backup command takes a single path. Run one backup per directory, or group them under a common parent. Unchanged files between snapshots are stored only once thanks to deduplication.

plakar at /var/backups/plakar backup /etc

Each backup creates a snapshot identified by a short hex ID. The output lists every file processed and a summary:

a5bcf13b: OK ✓ /etc/hostname
a5bcf13b: OK ✓ /etc/ssh/sshd_config
...
info: backup: created unsigned snapshot a5bcf13b of size 1.4 MiB in 210ms (wrote 1.7 MiB)

The second backup of the same path runs faster because only changed blocks get stored. Back up additional paths the same way:

plakar at /var/backups/plakar backup /home
plakar at /var/backups/plakar backup /var/www

Tagging snapshots

Use the -tag flag to label snapshots. This helps when you have many snapshots and need to filter them later:

plakar at /var/backups/plakar backup -tag "daily,filesystem" /etc

Excluding files

Log files, caches, and build artifacts waste space in backups. Use -ignore for inline patterns:

plakar at /var/backups/plakar backup -ignore "*.log" -ignore "cache/" /etc

For a longer list, load patterns from a file. The syntax follows gitignore rules:

cat > /etc/plakar-excludes <<EOF
*.log
*.tmp
*.swp
cache/
.cache/
node_modules/
__pycache__/
.git/
EOF

chmod 600 /etc/plakar-excludes
plakar at /var/backups/plakar backup -ignore-file /etc/plakar-excludes /etc

Scan mode

Preview what plakar would back up without writing anything to the store:

plakar at /var/backups/plakar backup -scan /etc

This lists every file that matches the backup criteria. Useful when tuning exclusion patterns.

Verify on backup

Add -check to run an integrity verification immediately after the backup completes:

plakar at /var/backups/plakar backup -check /etc

This costs a few extra seconds but catches corruption early.

How do you back up a MySQL database with plakar?

Pipe mysqldump output directly into plakar using the stdin: source. No intermediate dump file touches the disk. The SQL stream goes straight from mysqldump into plakar's encryption and deduplication pipeline.

For a single database:

mysqldump --single-transaction \
  --routines \
  --triggers \
  --events \
  myapp_db | plakar at /var/backups/plakar backup stdin:myapp_db.sql

What each flag does:

  • --single-transaction: takes a consistent snapshot of InnoDB tables without locking them. Other queries keep running.
  • --routines: includes stored procedures and functions.
  • --triggers: includes table triggers.
  • --events: includes scheduled events.

For all databases on the server:

mysqldump --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --set-gtid-purged=OFF | plakar at /var/backups/plakar backup stdin:all_databases.sql

--set-gtid-purged=OFF omits GTID metadata. This makes the dump portable across different MySQL instances without GTID conflicts during import.

The snapshot stores the SQL dump as a single file named after the stdin: label. You reference this name when restoring.

How do you back up a PostgreSQL database with plakar?

The approach is the same: pipe pg_dump into plakar via stdin:. PostgreSQL authentication typically uses peer auth for the postgres system user, so run the dump command under that account.

For a single database:

su - postgres -c "pg_dump --format=plain myapp_db" | plakar at /var/backups/plakar backup stdin:myapp_db.sql

For all databases and roles, use pg_dumpall:

su - postgres -c "pg_dumpall" | plakar at /var/backups/plakar backup stdin:all_pg_databases.sql

pg_dumpall includes global objects like roles and tablespaces that pg_dump skips. Use it when you need a full cluster backup. pg_dump --format=plain produces a plain SQL file that pipes directly into psql during restore.

How do you list and browse plakar snapshots?

List all snapshots in the store with plakar ls. Each line shows the timestamp, snapshot ID, compressed size, backup duration, and the source path.

plakar at /var/backups/plakar ls

2026-03-20T10:05:12Z   a5bcf13b   1.4 MiB        0s /etc
2026-03-20T10:06:01Z   5fc17459       0 B        0s /home
2026-03-20T10:06:15Z   7ed22fb8      24 B        0s /var/www
2026-03-20T10:10:45Z   ec916c75   2.0 KiB        0s /
2026-03-20T10:12:03Z   08ee9b7e   1.2 MiB        0s /

Stdin backups appear with / as the source path in the listing. The snapshot ID is what you use to distinguish them.

Filter by tag:

plakar at /var/backups/plakar ls -tag daily

Browse the contents of a specific filesystem snapshot:

plakar at /var/backups/plakar ls a5bcf13b

Narrow it to a subdirectory:

plakar at /var/backups/plakar ls a5bcf13b:/etc/ssh/

Web UI

For a visual interface, launch the built-in web UI. On a headless server, add -no-spawn to prevent it from trying to open a browser:

plakar at /var/backups/plakar ui -no-spawn -addr localhost:8080

The UI lets you browse snapshots, view file contents, and download individual files. Plakar generates an authentication token automatically and prints the URL with the token appended.

To disable token authentication (not recommended for production):

plakar at /var/backups/plakar ui -no-spawn -no-auth -addr localhost:8080

Stop it with Ctrl+C when done. For persistent access, put a reverse proxy with TLS in front of it and keep the token authentication enabled.

How do you verify backup integrity with plakar?

Run plakar check against a snapshot ID to verify every block. Plakar reads back each block from the store, decrypts it, and recomputes checksums. If any block has been corrupted or tampered with, the check fails.

plakar at /var/backups/plakar check a5bcf13b

info: a5bcf13b: ✓ /etc/hostname
info: a5bcf13b: ✓ /etc/ssh/sshd_config
info: a5bcf13b: ✓ /etc/apt/sources.list.d/plakar.list
...
info: check: verification of a5bcf13b:/etc completed successfully

Every file gets a checkmark if its checksum matches. Corrupted files show an error marker.

To verify every snapshot in the store at once:

plakar at /var/backups/plakar check

For a faster structural check that skips digest verification on individual blocks:

plakar at /var/backups/plakar check -fast a5bcf13b

Run integrity checks regularly. Weekly is a reasonable cadence for most VPS workloads. A backup you never verify is a backup you cannot trust.

How do you restore files from a plakar backup?

Restore an entire snapshot to a target directory with plakar restore. Plakar recreates the full directory tree under the target path. Original permissions and timestamps are preserved.

mkdir -p /tmp/restore
plakar at /var/backups/plakar restore -to /tmp/restore a5bcf13b

info: restore: restoration of a5bcf13b:/etc at /tmp/restore completed successfully

To restore a single file, use plakar cat and redirect the output:

plakar at /var/backups/plakar cat a5bcf13b:/etc/hostname > /tmp/hostname.restored

To restore just one directory from a snapshot:

plakar at /var/backups/plakar restore -to /tmp/restore 7ed22fb8:/var/www

This extracts only /var/www and its contents. Everything else in the snapshot is untouched.

Always restore to a temporary location first. Compare the restored files against the current server state before overwriting anything in place. A careless restore to / can overwrite config files that have changed since the snapshot was taken.

How do you restore a database dump from plakar?

Use plakar cat to stream the SQL dump from a snapshot directly into the database client. No intermediate file on disk. Use the snapshot ID of the stdin backup you want to restore.

MySQL

Restore a single database:

plakar at /var/backups/plakar cat ec916c75:myapp_db.sql | mysql myapp_db

Restore all databases from a full dump:

plakar at /var/backups/plakar cat 08ee9b7e:all_databases.sql | mysql

PostgreSQL

Restore a single database:

plakar at /var/backups/plakar cat f86ce26a:myapp_db.sql | su - postgres -c "psql myapp_db"

Restore the full cluster:

plakar at /var/backups/plakar cat c09e650e:all_pg_databases.sql | su - postgres -c "psql"

Test restores on a non-production database or a fresh test server. A backup strategy without tested restores is not a backup strategy. Schedule a restore test at least once a quarter.

How do you automate backups with plakar's scheduler?

Plakar has a built-in scheduler that runs backup tasks at defined intervals. No cron needed. You define tasks in a YAML file and plakar handles timing, execution, and optional post-backup integrity checks.

First, register the store with saved credentials so the scheduler can access it without interactive passphrase prompts. Create a passphrase file with restricted permissions:

mkdir -p /etc/plakar
openssl rand -base64 32 > /etc/plakar/passphrase
chmod 600 /etc/plakar/passphrase
chown root:root /etc/plakar/passphrase
ls -la /etc/plakar/passphrase

-rw-------  1 root root 45 Mar 20 10:20 /etc/plakar/passphrase

Use this passphrase when creating the store (or update the store if you already created one with a different passphrase). Register the store by name:

plakar store add mybackups \
  location=/var/backups/plakar \
  passphrase_cmd="cat /etc/plakar/passphrase"

Now create the scheduler configuration. Each task backs up one path:

mkdir -p /etc/plakar
cat > /etc/plakar/scheduler.yaml <<'EOF'
agent:
  tasks:
    - name: backup etc
      repository: "@mybackups"
      backup:
        path: /etc
        interval: 24h
        check: true
    - name: backup home
      repository: "@mybackups"
      backup:
        path: /home
        interval: 24h
    - name: backup www
      repository: "@mybackups"
      backup:
        path: /var/www
        interval: 24h
EOF
chmod 600 /etc/plakar/scheduler.yaml

Test it manually first:

plakar scheduler start -tasks /etc/plakar/scheduler.yaml

The scheduler runs in the foreground and logs task execution. Stop it with Ctrl+C. To run it as a background daemon, use the systemd service described below.

The scheduler handles filesystem backups natively. Database dumps that need piping through mysqldump or pg_dump require a wrapper script. Create one:

cat > /etc/plakar/backup-databases.sh <<'EOF'
#!/bin/bash
set -euo pipefail

# MySQL
if command -v mysqldump &>/dev/null; then
  mysqldump --all-databases \
    --single-transaction \
    --routines \
    --triggers \
    --events \
    --set-gtid-purged=OFF | plakar at @mybackups backup -tag "daily,mysql" stdin:all_databases.sql
fi

# PostgreSQL
if command -v pg_dump &>/dev/null; then
  su - postgres -c "pg_dumpall" | plakar at @mybackups backup -tag "daily,postgresql" stdin:all_pg_databases.sql
fi
EOF
chmod 700 /etc/plakar/backup-databases.sh

How do you run the plakar scheduler as a systemd service?

Wrap the scheduler in a systemd unit so it starts on boot, restarts on failure, and integrates with journalctl for logging.

cat > /etc/systemd/system/plakar-scheduler.service <<EOF
[Unit]
Description=Plakar Backup Scheduler
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/plakar scheduler start -tasks /etc/plakar/scheduler.yaml
ExecStop=/usr/bin/plakar scheduler stop
Restart=on-failure
RestartSec=30
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

If you also run the database backup script, create a separate timer for it:

cat > /etc/systemd/system/plakar-db-backup.service <<EOF
[Unit]
Description=Plakar Database Backup
After=network.target mysql.service postgresql.service

[Service]
Type=oneshot
ExecStart=/etc/plakar/backup-databases.sh
User=root
EOF

cat > /etc/systemd/system/plakar-db-backup.timer <<EOF
[Unit]
Description=Run Plakar Database Backup Daily

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

Enable and start everything. enable --now makes the service survive reboots and starts it immediately:

systemctl daemon-reload
systemctl enable --now plakar-scheduler.service
systemctl status plakar-scheduler.service

● plakar-scheduler.service - Plakar Backup Scheduler
     Loaded: loaded (/etc/systemd/system/plakar-scheduler.service; enabled; preset: enabled)
     Active: active (running)

For the database backup timer:

systemctl enable --now plakar-db-backup.timer
systemctl list-timers plakar-db-backup.timer

NEXT                         LEFT          LAST  PASSED  UNIT                    ACTIVATES
Fri 2026-03-21 02:00:00 UTC  15h left      n/a   n/a     plakar-db-backup.timer  plakar-db-backup.service

Monitor the scheduler logs:

journalctl -u plakar-scheduler.service -f

How do you delete old snapshots?

Remove a snapshot by its ID. By default, plakar rm performs a dry run and shows what would be deleted. Add -apply to actually remove the snapshot:

plakar at /var/backups/plakar rm a5bcf13b

rm: would remove these 1 snapshot(s), run with -apply to proceed
2026-03-20T10:05:12Z   a5bcf13b   1.4 MiB        0s /etc

plakar at /var/backups/plakar rm -apply a5bcf13b

info: rm: removal of a5bcf13b completed successfully

Plakar's deduplication means removing a snapshot only frees space for data blocks not referenced by any remaining snapshot. If two snapshots share 90% of their data, removing one frees only the unique 10%.

Something went wrong?

"repository passphrase" on every command. Plakar requires the passphrase each time you access the store interactively. Register the store with plakar store add and a passphrase_cmd as shown in the scheduler section. Then reference the store by name:

plakar at @mybackups backup /etc

You can also use the -keyfile flag to point to a passphrase file for one-off commands:

plakar -keyfile /etc/plakar/passphrase at /var/backups/plakar backup /etc

Never export PLAKAR_PASSPHRASE in your shell profile or .bashrc. It ends up in shell history and process lists. Use the passphrase_cmd pattern or the -keyfile flag instead.

"permission denied" when backing up. Plakar needs read access to the source files. Running as root avoids this. If running as a dedicated backup user, grant read permissions on the target directories with ACLs or group membership.

Snapshots are larger than expected. You are likely backing up log files, caches, or build artifacts. Use -ignore or -ignore-file to exclude them. Run a -scan first to see what gets included.

"no space left on device" during backup. The backup store and temporary packfiles need disk space. Check with df -h. The store grows over time as you add snapshots. Monitor it.

Reading plakar logs. Plakar writes output to stdout. Redirect both stdout and stderr to a file for review:

plakar at /var/backups/plakar backup /etc > /var/log/plakar-backup.log 2>&1

For verbose output, use the -trace global flag (it goes before at):

plakar -trace all at /var/backups/plakar backup /etc > /var/log/plakar-debug.log 2>&1

Next steps

Your backups are now running on a schedule, but they live on the same disk as the data they protect. A disk failure, ransomware, or a compromised server takes both out at once.

Get your backups offsite. Offsite Backup and Replication with Plakar covers replicating snapshots to a remote server or S3-compatible storage with plakar sync.

Copyright 2026 Virtua.Cloud. All rights reserved. This content is original work by the Virtua.Cloud team. Reproduction, republication, or redistribution without written permission is prohibited.

Ready to try it yourself?

Deploy your own server in seconds. Linux, Windows, or FreeBSD.

See VPS Plans

Related Articles