How ProBackup backs up your data: API pulls, daily snapshots, revisions and what the API cannot give us

In short: ProBackup reads each cloud app through its public API, one collection at a time, on a 24-hour cycle. Every record is hashed and a new revision is written to encrypted AWS S3 only when that hash changes, so a snapshot is a point-in-time view built from revisions; deletions are tracked, attachments stored alongside, and restores write back through the same API.

This is the engineering-level description of the backup engine behind every ProBackup integration. It exists so that our platform guides and recovery articles have something concrete to cite when they say "restore from a snapshot".

What is a ProBackup backup, technically?

A ProBackup backup is a per-account, per-platform archive of API JSON. The unit of work is the collection: one data type inside one parent, for example the tasks in one Asana project, the items on one monday.com board, or the records in one Airtable base. A backup of a 40-project Asana workspace is therefore a few hundred collections, each with its own schedule, its own change tracking and its own files on S3.

Key facts:

• Source: the platform's official REST API, authorised through OAuth 2.0 (or the marketplace app for monday.com and HubSpot).
• Unit: one pull job per collection (data type × parent × backup).
• Frequency: every collection is pulled once every 24 hours, which is what a daily snapshot is built from. There is no manual "back up now" button; the schedule is the product.
• Storage: JSON records and attachments in AWS S3, in the region you chose at signup. AES-256 at rest, TLS in transit.
• Change tracking: a murmur3 checksum per record; a new revision is stored only when the checksum changes.
• Deletions: tracked as dated tombstones, so a deleted record still appears in earlier snapshots.
• Restore: through the same API, as new records (default) or as a field-level overwrite of existing records (HubSpot, ClickUp, Asana, monday.com, Airtable and Attio).

How does the daily schedule work?

Each collection has a row in our scheduler with an enqueue_at timestamp. When ProBackup first discovers a collection, that timestamp is set to a random moment in the next 24 hours. This spreads a customer's collections across the day instead of hitting the platform with everything at once. After each successful run the job is bumped forward by exactly one day, keeping the same time of day.

A scheduler poll runs continuously and picks up every job whose time has come. Before it queues a data type it checks the depth of that platform's queue; if the workers are already behind, it waits rather than piling up more requests. Within a poll, jobs are spaced out by a few seconds each so that a burst of due jobs still arrives at the platform as a steady stream.

Two consequences worth knowing:

1. "Daily" means "within any 24-hour window", not "at midnight". Your Asana tasks might be pulled at 03:14, your Asana users at 17:52. The "last backup" timestamp in the vault is per collection.
2. You cannot trigger an ad-hoc backup. This is deliberate: the schedule keeps every account inside the platform's rate limits, and a manual button would let one account starve the others. If you need an urgent snapshot, support can force a poll for a single backup.

Full pull versus incremental pull

The first run of a collection is a full pull: ProBackup paginates through every record the API will return. Each page is its own job, and the job re-queues itself with the next page cursor until the API says there is nothing more. A very large collection can legitimately take longer than a day on its first pass; a heartbeat prevents the scheduler from starting a second copy of it.

After the initial pull the collection switches to incremental. Where the API offers a "modified since" filter (Asana's task search, for instance), ProBackup asks only for records changed since the last stored modification time. Where it does not, the integration uses the cheapest reliable alternative: a minimal-field listing to detect changed IDs and a full fetch for those IDs only, or webhooks (see below).

Every 14 days the incremental state is reset and the collection is re-pulled in full. This is a safety net against filters that miss edge cases (a platform that does not bump updated_at when an attachment is added, for example) and it is what guarantees the backup converges on the truth even if a webhook was lost.

Why a revision is stored only when the checksum changes

When a pull returns records, ProBackup does not write them straight to S3. For each record it computes a murmur3 hash of the record's JSON. Fields that change on every request without meaning anything (a platform-side "fetched at" value, for example) are excluded from the hash by the integration's data model, so they do not create phantom revisions.

The hashes are compared against the last known hash for every record ID in that collection. Only records whose hash is new, or that have never been seen, are written. Those records are grouped into a JSON file whose S3 key encodes the backup, the collection, the date and the time of the pull, plus a compact index of the record IDs inside.

This design has three effects that matter to you:

• Storage grows with change, not with size. A 100,000-record board that nobody edits produces no new files after its first pull.
• Every revision is an immutable file. Nothing is overwritten on S3 during a pull; a bad pull cannot damage an earlier one.
• A snapshot is a query, not a copy. When you open a collection "as of 12 March", the vault reads every revision file dated on or before 12 March, keeps the latest revision per record ID, and removes any record with a tombstone dated on or before that day.

The revision history you can go back to is set by your plan: 6 months on Plus, 2 years on Pro, unlimited on Premium. A clean-up job removes revisions older than the window. Native trash and version history behave very differently from this, as the retention windows app by app show.

How deletions are detected

The API rarely tells you what is gone. ProBackup uses three mechanisms, depending on the data type:

A deletion is written as a tombstone: a small file whose key carries the deleted IDs and the date. Tombstones are what let the vault show a "deleted records" view and what stop a restored-then-deleted record from reappearing in later snapshots.

How attachments and files are backed up

Attachments are not pulled inline with records. When a pull sees a file reference, it hands the file to a dedicated attachments service, which:

1. Skips the file if the same attachment ID was already stored for this backup (files are content-addressed per backup; an unchanged file is never downloaded twice).
2. Every 10 minutes, takes the next batch to download. Capacity is shared equally across all accounts with pending files, with a per-backup cap, so one account with 200,000 files cannot monopolise the queue or exhaust its own API rate limit.
3. Downloads the file from the platform's private URL using auth headers obtained from the platform's OAuth service, and uploads it to S3 in your backup's region.
4. Retries twice on failure and re-schedules "frozen" downloads up to three more times over 45 minutes.

There is no fixed attachment size limit. Account owners can set a maximum file size and an excluded-extension list for their own backups; files skipped for either reason are recorded as skipped rather than silently dropped. On Premium, every downloaded file is scanned by the virus scanner and flagged files are reported.

Files that live in a third-party store (Google Drive, Dropbox, Box, OneDrive, SharePoint) and are merely linked from the platform are not downloaded: the platform API hands us a link, not the bytes.

What the API cannot give us

ProBackup backs up all API-available data. The limits below are the platform's, not ours; when a platform opens an endpoint we add the data type.

Two constraints apply on every platform:

• Text fields are captured up to 2,000 characters. Longer descriptions and comments are truncated at that point.
• Permissions follow the connecting account. ProBackup sees what the authorising user sees. A private project the admin cannot open is not in the backup, unless the platform's admin API grants broader read access.

Does ProBackup consume my API quota or slow my workspace?

ProBackup runs under its own registered app on each platform, so its calls count against ProBackup's allocation rather than against integrations you have built yourself.

On our side, the scheduler spreads jobs across the day, spaces requests within a job, honours each platform's Retry-After headers through a per-platform rate limiter, and backs off when a platform reports it cannot process all requests at once. If a platform throttles an account, the affected collections are spread over the following 24 hours and the vault shows a warning rather than a failed backup.

How a restore works

A restore reads the record's JSON from the chosen snapshot and writes it back through the platform's write API. Two modes exist:

• Create (default). ProBackup creates new records, leaving the originals untouched. Related objects are restored in dependency order: for a ClickUp list, the list first, then its custom fields, then tasks in parallel, then each task's comments and attachments. ProBackup keeps a map from every original ID to its restored ID, so a restored task points at the restored custom field, not the old one.
• Overwrite (rollback). For HubSpot, ClickUp, Asana, monday.com, Airtable and Attio, you choose which fields to roll back and ProBackup updates the existing records in place. Calculated fields (system fields, formulas, relations) are excluded because the API does not accept writes to them. There is no per-restore record limit.

Every restore is tracked task by task in a restore log you can follow in the app; a task that fails on a platform error is retried, and the rest of the restore continues.

Restores go back to the original account only. ProBackup is not a migration tool.

If you have never run one, test a restore on a low-risk collection before you need it.

Where the data lives and how it is protected

• Region: one of nine AWS regions, selected at signup and applied to every backup in the account: Europe (Ireland), Europe (Germany), United Kingdom, United States, Canada, Brazil, Australia, Singapore and Israel. Changing region later goes through support, which moves all of the account's backups.
• Encryption: AES-256 at rest on S3, TLS in transit between the platform, ProBackup and your browser.
• Compliance: SOC 2 Type II (latest report period 1 April 2026 to 30 June 2026), GDPR. Reports and controls are published at trust.probackup.io.
• Access: two-factor authentication on every plan; SSO on Premium. Invited users can be limited to view, export or restore.
• Retention: revisions are kept for 6 months (Plus), 2 years (Pro) or without limit (Premium), then removed by a scheduled clean-up.

FAQ

How often does ProBackup back up my data?

Every collection is pulled once in every 24-hour window. The exact time is fixed per collection and spread across the day; it is not a single nightly job.

Does ProBackup store a full copy every day?

No. It stores a new revision of a record only when the record's checksum changes. A daily snapshot is rebuilt on demand from those revisions plus deletion tombstones.

Can I see a record as it was three months ago?

Yes, within your plan's retention window (Plus 6 months, Pro 2 years, Premium unlimited). Open the collection, pick the date, and the vault reconstructs that day's state.

Why is a deleted task still missing from the "deleted" view an hour after I deleted it?

Deletion detection runs on the same daily cycle, unless the platform sends a deletion webhook (Asana, ClickUp, monday.com, HubSpot, Jira, Confluence, Trello, Airtable and others do). The tombstone appears after the next sweep at the latest.

Does ProBackup back up comments and attachments?

Comments: yes on every platform that exposes them (see the per-platform list). Attachments: yes, downloaded to S3 in your region, with no fixed size limit; files linked from Google Drive, Dropbox, Box, OneDrive or SharePoint are not downloaded.

Can ProBackup restore to a different workspace?

No. Restores target the original account and, for overwrite mode, the original records.