Send your calendar backups to Amazon S3, Backblaze B2, Wasabi, Cloudflare R2 or Azure

You can have each night's calendar backup delivered to your own Amazon S3 bucket, or to Backblaze B2, Wasabi or Cloudflare R2 (all four use the same form), or to an Azure Blob Storage container. You give GetCalendario an access key, ideally one that can only upload files, press Test connection, and from then on each night's file lands in your storage. We keep no copy.

Do this from Daily Backups, then Setup, by choosing Your storage, locked (recommended) or Your storage, not locked, and then Amazon S3 or Azure. Daily Backups is on paid plans and during the 14-day trial. For the full picture, see how Daily Backups work.

What do I set up on the storage side?

Amazon S3 and the S3-compatible services. Create a bucket, then create a user for GetCalendario whose only permission is to add files under a GetCalendario/ folder. On AWS, the page's own guide gives this policy, with your bucket name in place of YOUR-BUCKET:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::YOUR-BUCKET/GetCalendario/*"
  }]
}

Make an access key for that user. The policy above is AWS wording. On Backblaze B2, Wasabi and Cloudflare R2, check what each service lets you restrict, because not every one can issue an upload-only key. The connection test shows whether the key you made can read back, whichever service you use.

Azure. Open your storage account, then the container, then Shared access tokens. Tick only Create and Write, pick an expiry date, and copy the Blob SAS URL.

What does the connect form ask for?

For S3 and the S3-compatible services:

• Access key ID and Secret access key
• Region
• Bucket
• Endpoint (Backblaze, Wasabi or R2 only), optional. Leave it empty for Amazon S3.

For Azure, one box: Upload link (SAS URL).

The endpoint and link must be a storage provider's own address over https. GetCalendario refuses addresses that are not an Amazon, Backblaze, Wasabi, Cloudflare R2 or Azure Blob address.

What happens when I press Test connection?

We write a small file called GetCalendario-test.txt into a GetCalendario/ folder in your storage. A failure is shown right there, not discovered the next night. The Save button appears only after the test file has been written. You can delete the test file afterwards.

Then we try to read that file back with the same key, expecting to be refused. You see one of two results:

• Write-only: "we just put GetCalendario-test.txt in your storage, and this key cannot read it back." This is what you want.
• Not write-only: the key works, and either it can read your bucket or container or we could not confirm that it cannot. You can still save it, and the page shows the narrower policy or link to switch to.

How does GetCalendario check that a key is write-only?

Only S3 (and the S3-compatible services) and Azure are tested like this, because they are the ones where a key can be limited to uploading. The check asks for the new file's details, and then for a listing of its folder. Either one succeeding needs read access, so it counts as a read. Nothing is downloaded.

It runs again after every delivery. If your key later gains more access, GetCalendario emails you once, and the connection card changes from Write-only to GetCalendario can read this with a warning until the key is set back to upload-only. The warning clears after a delivery in which the key cannot read.

Where do the files land?

Under GetCalendario/<calendar name> (<calendar id>)/, one file per calendar per night, named for the day, such as 2026-10-04.gcb for a locked file or .zip for a locked zip. The id keeps two calendars with the same name apart. To restore, you download the file yourself, because our key cannot fetch it: see how to restore a calendar from a backup.

What to know

• We never delete files in your storage. To keep 30 days, add a lifecycle rule on the bucket, or lifecycle management rule on the container, that expires files after 30 days.
• Azure links expire. The card shows the date, and we email you two weeks before. A new link is needed after that; backups stop when it runs out.
• If a key stops working, the card says backups have stopped and offers Reconnect. A full or unreachable storage is reported too, and we try again the next night.
• Locking is separate from where files go. See lock your backups.
• Disconnecting removes our copy of the key and stops backups until you connect storage again.