Skip to content
EN
Русский English
Connect a server

Backups with encryption, rotation and restore.

Site files and databases go to your SFTP storage on a schedule — compressed, encrypted and verified. Rotation clears out old copies, and a restore starts from the panel.

Connect a server All features
  • 7 days free
  • No card required
  • Payment in rubles
Copies by day
shop.example.comprod-01 · daily at 03:00
Verified
17 18 19 20 21 22 23 24 25 26 27 28 29 30 1

Keep last: 1414 / 14

Today, 03:00

  1. Dump and archive
  2. Compression and encryption
  3. Upload to storage
  4. Verification after upload
storage.example.comSFTP · zstd · age
1.24 GBverified
Site restored from the copy of the 28thRestore
2
profile types: site files and a database dump
14
schedule presets — plus your own cron expression
3
channels for a failure alert: email, Telegram and the panel inbox
9
MCP tools: from creating a profile to a restore

Backup profiles

Files and databases — each on its own schedule.

A profile is a rule: what to back up, where to, how often and how long to keep it. One site can have several: files once a day, the database every six hours.

  1. Site files

    A full backup of the project directory: source code, uploads, configs. A separate profile for each site on the server.

    Excludes, for examplenode_modulesstorage/logs*.log

  2. Database dumps

    A separate profile for each database. Support for mysqldump, mydumper, compressed and encrypted formats.

    Dump enginemysqldumpmydumperup to 32 threads

  3. Schedule

    14 presets — from every 10 minutes to once a month — or your own cron expression. The panel shows the next three runs right away.

    For exampleevery 6 hoursdaily at 03:000 4 * * 1-5manual

  4. gzip / zstd compression

    Choose between gzip (default) and Zstandard — a modern algorithm with a better compression ratio. Configurable compression level.

    Compression levelgzip 1–9zstd 1–19

  5. Stream upload

    The archive is never built on the server disk: compression, encryption and upload run as one stream. If the connection to the storage is flaky, pick a local archive — the panel checks in advance that there is enough room for it.

    Upload mechanismstreamlocal archive
Rsync mirror

For very large sites: only changed files are transferred, and the storage keeps a single up-to-date mirror of the directory instead of dated archives.

Not available in this modecompressionencryptionverificationrestore from the panel

Reliability

Four conditions without which a backup is not a backup.

The copy lives off the server, is verified after upload, is closed to prying eyes and does not eat up the whole storage.

Storage BoxBackup provider · SFTP
3 profiles
Host
storage.example.com:22
User
backup
Base path
backups

Profile folder

studio/prod-01/shop.example.com
Storage testPassed just now
Test

Copies live on your SFTP storage

Connect any storage with SFTP access: a separate VPS or a ready-made Storage Box from a hosting provider. The server uploads archives there directly — Deploykin does not keep them.

  • One provider for any of the team's profiles
  • A separate folder for every site and database: team / server / source
  • Storage test from the panel: a trial file upload
  • The storage password is stored encrypted
Backup profilesprod-01 · 3 profiles
Create
ProfileLast copy
Backup shop.example.comsite files · daily at 03:00
1.24 GB
Backup shopdatabase · every 6 hours
34 MB
Backup blog.example.comsite files · on Sundays
410 MB
Copy verifiedStart

A failure will not go unnoticed

After the upload the panel reads the archive right on the storage and makes sure it is intact. If a run fails, the profile turns red in the list and you get an alert.

  • Integrity check: gzip -t, zstd -t or tar -tf
  • Encrypted archive — presence and size check
  • SHA-256 and copy size — in the run record
  • Failure alert: email, Telegram, panel inbox
Encryptionprod-01 · age
Key generated
Encrypted profiles3
Keys per server1 pair

Public key

age1qy8m3c7e…xk4w2f9r

Recovery key

recovery-key-prod-01.txtSaved
Download

The storage only ever sees ciphertext

The archive is encrypted with age on your server — before it is sent. The key pair is generated on the server itself, one per server: the public half encrypts the copies, the private half is stored encrypted in Deploykin and is sent to the server only for a restore.

  • The recovery key is a file with the private key and instructions: copies can be decrypted without Deploykin
  • Save it in 1Password or download it and keep it offline
  • Downloading the key again requires your account password
  • Private keys are encrypted at rest with AES-256-CBC
RotationBackup shop.example.com
Keep last3
Not older than, days30

Copies in storage

3 days ago, 03:00
removed
2 days ago, 03:00
1.23 GB
yesterday, 03:00
1.24 GB
today, 03:00
1.24 GB
Rotation: oldest copy removed3 / 3

Old copies clear themselves out

Set how many copies to keep and how old they may be — after every successful run the panel removes the extra ones. The storage never fills up, and you keep the history depth you need.

  • Keep the last N copies
  • Delete copies older than N days
  • The rules work together or separately
  • Only archives uploaded by Deploykin are deleted — the fresh copy always stays

Restore

Restore — with a rollback on failure.

Restore of site files and databases on the original server. A database can be restored into another database on that server. For site files a pre-restore copy is created, and on error — an automatic rollback of the files.

  • Any stored copy, not just the latest
  • Pre-restore copy of site files: .deploykin-pre-restore-TIMESTAMP
  • Automatic rollback of site files if the restore fails
  • A database — into the original, another or a new one on the same server
Restoreshop.example.com
Rolled back
Site files copySize
yesterday, 03:00tar.zst.age
1.24 GB

Restore progress

Downloading the archive
1.24 GB
Copy of current files
pre-restore
Unpacking the archive
no space left on disk
Putting previous files back
rollback
The site runs on its previous files

And more

A backup has to work on a bad night too.

The server was rebooting, the storage is almost full, the archive has been uploading for three hours — the panel is built for nights like these too.

  • A run is never lost

    If the server was unreachable at night, the profile fires as soon as it is back online.

  • Free space is checked up front

    On the storage before an archive is uploaded, on the server when the archive is built locally first.

  • A long backup does not get cut off

    The run works in the background on the server and reports the result to the panel itself.

  • Manual run

    The Run now button — before an update or a migration, without waiting for the schedule.

  • Changes need confirmation

    Editing an existing profile or storage requires confirming your identity: with a password or a passkey.

  • Passwords stay out of the process list

    Database and storage credentials are passed through temporary files, not the command line — and wiped after the run.

In the panel 203.0.113.21 Connect done in 4 min 52 s

Backups you can trust.

Encryption, rotation, verification and restore — all out of the box. Set it up once and forget it.

Start for free Databases
  • 7 days free
  • No card required
  • Human support

We use cookies and the Yandex Metrica web-analytics service (including Session Replay) to improve the site. Details are in the privacy policy.