A team workspace becomes more useful as it gathers real work: tasks, Docs, support conversations, emails, meetings, forms, database rows, CRM records, and internal posts. That also means the workspace becomes more important to protect.

Aamu.app supports daily team backups to S3-compatible storage. A team can connect its own object storage bucket, enable backups, and let Aamu export changed workspace data as structured JSON files once per day.

The goal is simple: your team should have a practical copy of its operational data outside the primary application database, in storage you control. Backups are not only for emergencies. They are also a way to keep ownership of your data, understand what is stored, and avoid being locked into one product just because your work history lives there.

Why S3-compatible backups

S3-compatible storage is a useful backup target because it is widely supported. The same basic integration model works with AWS S3 and many compatible platforms such as object storage from cloud providers, infrastructure hosts, and self-hosted S3-compatible systems.

For a small team, this matters because backups should not require a custom export workflow. The team chooses a bucket, stores credentials in Aamu, and Aamu writes backup objects there on a schedule.

The bucket can be managed with the team's normal storage policies: retention rules, replication, access logging, lifecycle rules, or whatever the chosen platform supports.

What gets backed up

Aamu's daily backup focuses on the workspace data that teams usually need if they want to inspect, migrate, audit, or recover operational context.

The current backup set includes:

  • Projects, including basic project metadata and users.

  • Docs, including searchable document content.

  • Tasks, including title, content, owner, status, tags, comments, and timestamps.

  • Posts, including content, author, comments, and timestamps.

  • Helpdesk, including tickets, chats, chat messages, customers, comments, status, tags, participants, and timestamps.

  • Emails, including message title, content, recipients, contact, type, comments, and timestamps.

  • Chats, including rooms and chat messages.

  • Meetings, including invitees, participants, owner, comments, name, status, tags, start time, and timestamps.

  • Databases, including databases, tables, columns, and row data.

The backup also follows selected nested objects. For example, a database backup can include its tables and rows. A chat backup can include its chat messages. A Helpdesk chat backup can include the related chat messages.

Incremental by default

Daily backups do not need to upload the entire workspace every time. Aamu tracks the latest successful backup timestamp for each backed-up object and uses that to decide which documents have changed.

When a task, Doc, ticket, row, meeting, or other backed-up object has not changed since the last backup, it can be skipped. When it has changed, Aamu writes a fresh JSON object to the backup bucket.

This makes the daily run faster and keeps object storage quieter, while still producing readable backup files for changed data.

Readable JSON, organized by object path

Backup files are written as JSON, not as an opaque database dump. The object key reflects the Aamu object path.

projects/PROJECT_ID.json
docs/DOC_ID.json
tasks/TASK_ID.json
helpdesk_tickets/TICKET_ID.json
dbs/DB_ID/dbtables/TABLE_ID/dbrows/ROW_ID.json

That layout is intentionally boring and inspectable. If someone needs to look at a backed-up task, Doc, ticket, database row, or meeting, the file can be opened directly from object storage.

It also makes downstream use easier. A backup bucket can feed an audit process, a data lake, a migration tool, or a custom recovery script without first unpacking a monolithic archive.

Portable data, including AI-assisted migration

Readable JSON makes the backup useful outside Aamu. A team can inspect the files directly, write scripts against them, import selected records into another system, or transform the data into whatever shape the next tool expects.

This is especially important now that AI can help with migration work. If a team wants to move task history, support tickets, CRM rows, Docs, or meeting notes into another service, an AI-assisted script can read the backup files, map fields, normalize content, and prepare imports for the target system.

The key point is control. The team is not asking the application for a one-time export in a proprietary format. It has a daily, structured copy in its own object storage, ready to be searched, transformed, archived, or moved elsewhere when needed.

Media referenced from content

Workspace content often includes images or file references. During backup, Aamu can process image references in HTML content and copy those media objects into the backup bucket under a stable media path.

That means backed-up Docs, posts, tasks, or other HTML content are less dependent on the original media location. The JSON can point to media stored alongside the backup data.

How the storage connection works

A backup connection is configured per team. Aamu needs the S3-compatible endpoint, bucket name, access key, secret key, and optionally region and path-style mode.

Path-style mode is useful for providers that expect bucket names in the URL path instead of as a virtual host. Region is optional because some S3-compatible providers require it and some do not.

Before writing backup objects, Aamu checks access to the configured bucket. If the bucket cannot be reached, credentials are wrong, or the provider rejects the request, the backup run records an error instead of silently pretending everything worked.

Daily schedule

The backup worker runs automatically for enabled teams. On server start it performs a backup run, and then it repeats the backup process every 24 hours.

Each enabled team's backup is queued during the run. Teams with incomplete storage configuration are skipped until the endpoint, bucket, and credentials are present.

Operational safety details

Backup systems should fail loudly enough to be useful. Aamu records backup errors on the team's backup configuration when a run fails. The backup process also limits repeated errors so one broken object or storage problem does not cause an uncontrolled failure loop.

Uploads are logged with progress during larger runs. If there are no changed objects, the run completes without uploading new JSON files.

A full backup can also reset the stored backup timestamps for a team, which forces Aamu to treat existing objects as needing to be exported again.

What this is not

Daily S3-compatible backups are not a replacement for every reliability layer. They do not remove the need for primary database backups, application monitoring, access control, or retention planning.

They serve a different purpose: giving the team an application-level, structured, portable copy of important workspace data in external object storage. That copy can support inspection, migration, AI-assisted transformation, selective recovery, and long-term archiving.

That distinction matters. A database snapshot is useful for restoring infrastructure. A structured JSON backup is useful when a team wants to inspect its work, move data, recover specific records, or keep a long-lived archive outside the main application.

The bottom line

Aamu.app's daily backup feature is built for a practical kind of data ownership. Enable a team backup, point it at an S3-compatible bucket, and Aamu exports changed workspace data as readable JSON files every day.

For teams using Aamu for tasks, Docs, support, email, meetings, forms, databases, and CRM work, that creates a second copy of the operational memory they are building inside the workspace.

That second copy belongs in storage the team controls. If the team later wants to audit it, analyze it, archive it, or move it to another service with the help of scripts or AI, the data is already there in a format that is possible to work with.