Backing up LitArbi Server to Amazon S3, step by step

Before you start

You need three things: an Amazon Web Services account you can sign in to as its administrator, an administrator account on your LitArbi Server, and a safe place for the backup kit — the firm’s password manager or a printer and a safe. Set aside 20 minutes; the first backup then runs on its own.

These are the five things you create, in this order:

Everything the server sends is encrypted before it leaves the server, with a key only your firm holds. Amazon stores data it cannot read; LitArbi cannot read it either.

Costs. Amazon charges a few cents per gigabyte per month for storage in Frankfurt, plus tiny amounts per request. A server with 20 GB of exhibits costs well under one euro a month.

Step 1 — Create the bucket

1. Sign in to the AWS Management Console. In the region menu at the top right choose Europe (Frankfurt) eu-central-1 — or another EU region; note which one.
2. Open S3 (type “S3” into the search box) and click Create bucket.
3. Bucket type: General purpose. Bucket name: something unique, for example litarbi-backup-yourfirm — lowercase letters, digits and hyphens; the name must not be taken anywhere in AWS.
4. Leave the defaults: ACLs disabled, Block all public access ticked, default encryption SSE-S3.
5. Open Advanced settings. Under Object Lock choose Enable and tick the box that acknowledges objects can be locked permanently. Bucket versioning is switched on with it.
6. Click Create bucket.

Object Lock can only be switched on now, while the bucket is created — and never off again. AWS then suggests setting a “default retention”: skip that. LitArbi locks each file itself, for the number of days you enter in step 5.

Step 2 — The cleanup rule

Object Lock needs versioning, and with versioning a deletion only hides a file. When LitArbi removes an old restore point, the rule deletes the hidden copy for good 30 days later.

1. Open the new bucket, tab Management, and click Create lifecycle rule.
2. Lifecycle rule name: litarbi-cleanup. Choose a rule scope: Apply to all objects in the bucket, and tick the acknowledgement.
3. Under Lifecycle rule actions tick Permanently delete noncurrent versions of objects and Delete expired object delete markers or incomplete multipart uploads.
4. Days after objects become noncurrent: 30. Leave “Number of newer versions to retain” empty.
5. Tick Delete expired object delete markers and Delete incomplete multipart uploads, Number of days: 7.
6. Click Create rule.

Do not tick “Expire current versions of objects” — that would delete the backups themselves.

Step 3 — The policy: what the server may do

1. Open IAM (type “IAM” into the search box), then Policies and Create policy.
2. Switch the policy editor from Visual to JSON, select everything in it and replace it with the policy below. Put your bucket name in both places where it says litarbi-backup-yourfirm.
3. Click Next. Policy name: LitArbiServerBackup. Click Create policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBackupBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm"
    },
    {
      "Sid": "ReadWriteBackupFiles",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:PutObjectRetention", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::litarbi-backup-yourfirm/*"
    }
  ]
}

With this policy the server can list, read, write and delete the current files in that one bucket. It cannot remove old versions — s3:DeleteObjectVersion is missing on purpose. Someone who takes over the server can therefore only hide files, never destroy them; the hidden copies stay recoverable for 30 days.

If the editor doubles brackets or quotation marks while you type, paste the policy instead of typing it.

Step 4 — The server’s user and its access key

1. In IAM open Users and click Create user. User name: litarbi-server-backup. Leave “Provide user access to the AWS Management Console” unticked. Next.
2. Permissions options: Attach policies directly. Search for LitArbiServerBackup, tick it, Next, then Create user.
3. Open the new user, tab Security credentials, and under Access keys click Create access key.
4. Use case: Application running outside AWS. Next, optionally the description “LitArbi Server”, then Create access key.
5. AWS shows the Access key (it starts with AKIA) and the Secret access key — the secret only this once. Leave the page open for step 5.

Lost the secret? Delete the access key and create a new one, then enter the new pair in LitArbi. Nothing else changes.

Step 5 — The Backups page in LitArbi Server

In LitArbi Web open Administration ▸ Backups. The page has three numbered parts.

1 · Backup key

Click Create the backup key. The page shows the backup kit once: a key LABK-… and its fingerprint. Print it or store it in the firm’s password manager, keep it apart from the server, and make sure a second person knows where it is. The server keeps only the public half: it can write backups but never read them. Without the kit nobody can open them — not you, not your host, not Amazon, not LitArbi.

2 · Backup place

Choose S3-compatible storage and fill in:

Enter your own LitArbi password to confirm and click Test and save. The server writes, reads and deletes a test file first, so a mistake shows up at once (see “When something goes wrong” below). The access data are stored encrypted on the server.

3 · Keep restore points for

14 days, 8 weeks and 12 months is a good start: the newest restore point of each day, week and month is kept. Professional retention duties may call for more months.

Finally click Back up now. The first backup sends everything and can take a while — it carries on in the background. Later backups send only what is new.

Step 6 — Check that it works

• On the Backups page Last backup shows today’s date and At the backup place your bucket with “Object Lock 30 days”.
• The Overview no longer says that no backups are set up.
• Enter the key from your kit under Check the kit. It opens the newest restore point once and is not stored — proof that the kit works before you need it.
• Check the backups compares the newest restore point with what was sent; the server repeats this every week by itself.

The backup runs in the background in short slices while LitArbi is in use. On hosting with cron jobs it is more reliable to start it every night at a fixed time — the installation guide that comes with the server package shows the line.

When something goes wrong

If Test and save fails, the page shows Amazon’s reason. The usual ones:

Other S3 providers

Any S3-compatible storage works the same way — for example Hetzner Object Storage, IONOS S3 Object Storage, Backblaze B2 or Wasabi. Three things matter wherever you go:

• Switch on Object Lock (and with it versioning) when the bucket is created, if the provider offers it.
• Create an access key that may only use this one bucket, if the provider allows that.
• Take the endpoint and the region from the provider’s documentation and enter them in step 5.