Full support for append-only storage (ransomeware protection)

Can tardigrade please provide full support for append-only backups to protect a server from being able to delete all its own backups in the event that the server is compromised?

I’d really love to switch my org’s backups over to using Tardigrade, but we can’t unless it has full support for append-only backups. This would require:

  1. The access keys granted to the server would permit the server to be able to add new files to our backups, but not delete existing files on tardigrade and

  2. There would need to be some system in-place on tardigrade’s side to set a retention policy for files matching some regex – since [a] we necessarily won’t let our servers have the rights to delete our backups (to protect us from ransomware), and [b] we also don’t want to have to do this manually

In the past few years, countless government organizations and private companies have become infected with ransomware, which did three things:

  1. they (the attackers) encrypted the disks of all the victim organization’s servers,

  2. they deleted all of those organization’s backups since their servers had the ability not only to write backups, but also delete previous backups, and

  3. they demanded hundreds of thousands or millions of dollars worth of bitcoin in exchange for the disk encryption keys, which they held for the ransom.

The obvious solution to this is to have good backups that cannot be deleted. For large organizations, this means using a tape library and some physical tape rotation kept offline. But for small non-profit organizations like ours, this is not possible. Instead, one option is to use a cloud storage provider that supports append-only permissions.

Currently we use backblaze b2, and we’d love to switch to tardigrade. It does appear possible to set an access key in tardigrade to have permission to write but not delete files. If that’s the case, then tardigrade is half-way there.

The next step is to allow users to define a set of retention policies matching a user-defined regex so that, for example, files matching /.*daily.*.tar.gz$/ should be kept for 10 days, files matching/.*monthly.*.tar.gz$/ would be deleted only after 2 years, and files matching /.*yearly.*.tar.gz$/ would never be deleted.

Without full support for append-only backups for ransomware protection, our org cannot switch from Backblaze B2 to Tardigrade. Please consider adding this very important, security-critical feature.

Hello @maltfield,
Welcome to the forum!

This is easy to make it happen right now without any developer involved.

  1. Create a limited access grant for your backup software with only write permissions to the specific bucket either via web UI of the satellite, or in the CLI with an uplink:
uplink share --readonly=false --writeonly --disallow-deletes sj://backup
  1. Import this serialized access grant to your backup software.

If your backup software is able to configure a backend only by using an API key and secret phrase, then you can use the web UI only:


It will give you a token, compatible with the deprecated API keys.

When your backup software is configured it can only write backups but not delete. It even could not be able to list them!
If your backup software is need to have a read access too, then you can give it the same way.

If you would use an uplink for upload files you also can specify a timeframe after which the file should be deleted automatically: https://documentation.tardigrade.io/api-reference/uplink-cli/cp-command#flags (see the flag --expires).

1 Like

@Alexey great info, thanks!

Just to confirm: if the “limited access grant” was created with the command you provided

uplink share --readonly=false --writeonly --disallow-deletes sj://backup

…then will that access grant be able to change the expiration of existing files – which would effectively allow them to “delete” files after some delay?

I’m new here, and I’m unfamiliar with the notion of “API key” vs “serialized access grants”. Can you please link me to the docs that explains the difference? And does rclone support both?

If you would use an uplink for upload files you also can specify a timeframe after which the file should be deleted automatically: https://documentation.tardigrade.io/api-reference/uplink-cli/cp-command#flags (see the flag --expires).

What exactly does this mean? The link you provided just shows the syntax for the cli, but what is an uplink specifically, and how does it differ from a normal file upload?

No, it’s only access permissions. The object deletion after expiration date is applied on objects level only.
But you can generate an access which would expire after some date, however the object will still be there.

Yes sure, there is guide to create a serialized access grant, it can be used with software which is able to accept the access grants:
via Satellite Web UI:


or via uplink CLI:

For example, you can import a serialized access grant with uplink import command:


or with gateway setup --non-interactive --access if you use an Tardigrade S3 Gateway to interact with the network with any s3-compatible tool.

The second variant - is to generate a token for the access grant, it’s suitable, when your software is able to consume only API key and secret phrase and generates access grant itself:


For example, you need such a token if you would configure a current version of the FileZilla, the next version should support a serialized access grant too.

Yes. When you configure the rclone you can select either:

  • Use an existing access grant - for this way you will generate the access grant with the Continue in the Browser of the Satellite Web UI or with the uplink share command;
  • Create a new access grant from satellite address, API key, and passphrase - for this way you will generate a token with Continue in the CLI of the Satellite Web UI and use it as an API key.

The uplink is a command line interface for the Tardigrade. It have plenty of options to rule your buckets, objects and accesses. You also can use it to revoke any generated access, if you have enough rights (you should use an access grant with full rights to the project to be able to do so).
It can be used for uploads and downloads too.

1 Like

as i understand it is not posible itself to append files. you need to download existing file then change it and upload back to network, but it will be already new file. So it is esier to make new backup already. But what is the positive side of this, that you will have every variation of your backup, if file is broken, just take litlee bit older.

There are incremental backups. This exactly why Duplicati is exist - it can add a difference to the backup and this is a separate “small subbackup” and it depends on the parent “big” backup. So actually you do not need to download a full backup to make an increment - the backup solutions store this metainformation separately from the backup itself, as a separate file for example or as an database.
Thus you also do not need an append function at all.

@maltfield you can take a look on Duplicati by the way


It can be as simple as a docker container (I used exactly a docker container - it’s working the same way on any OS).
1 Like