Read our blog

In short: Confluence Cloud moves deleted pages to a space trash that any space admin can purge, after which the page "and all its versions and attachments, are gone for good". Deleted spaces are permanently removed after 60 days. ProBackup snapshots your Confluence spaces, pages, blog posts, attachments and comments every 24 hours and restores deleted pages under their original parent.

Why Confluence's trash is not a backup

Confluence holds the documentation your organisation runs on: runbooks, policies, meeting notes, product specs. Atlassian protects the platform. It does not protect a page from the person who deletes it.

Atlassian's documentation (checked 2026-09-16) describes the native safety net:

• Pages: a deleted page "moves to the space's trash" and "can be restored, until or unless it is manually purged from the trash." Purging means "the item, and all its versions and attachments, are gone for good."
• Restored pages lose context: "a previously deleted item will lose its inherited permissions as well as its location in the sidebar." It is placed at the same level as the space home page, so it is invisible in the sidebar until you move it.
• Spaces: since 6 January 2025 Atlassian will "permanently delete spaces that have been in the trash for at least 60 days." Only a Confluence admin can restore a trashed space, and permanent deletion "cannot be undone".

Trash therefore protects against a single accidental deletion noticed quickly. It does not protect against a purge, an offboarded admin's clean-up, a space deleted three months ago, or a page rewritten by a bulk find-and-replace or an AI assistant.

How to back up Confluence with ProBackup

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account.

Setting it up for Confluence Cloud:

1. Start a trial. Go to app.probackup.io/onboarding, choose Confluence and create your account. The 7-day trial needs no credit card.
2. Connect via OAuth. Click Connect Confluence and sign in to Atlassian. Choose the Confluence site to protect and grant ProBackup read access. ProBackup never stores your Atlassian password; it holds an OAuth token you can revoke from your Atlassian account settings.
3. Choose the scope. Select the spaces to include. Only content the connected account can see is backed up, so connect a user with view permission on every space that matters. Advanced scope control is available on Premium.
4. Check restricted pages. Pages with restricted access cannot be read through the Atlassian API unless the connected account is granted access. Update the page restrictions to include the ProBackup user, or those pages stay outside the backup.
5. Wait for the first snapshot. The first snapshot is taken within 24 hours; large sites with many attachments take longer. You receive an email when it completes. After that, a new snapshot every 24 hours, with no scheduling required.

Snapshots are stored on AWS S3, encrypted with AES-256 at rest and TLS in transit, in one of nine AWS regions you select at signup. ProBackup is SOC 2 Type II certified (May 2025) and GDPR compliant.

What is and is not backed up

ProBackup backs up what the Confluence Cloud REST API exposes:

• Spaces
• Pages, including page hierarchy and body content
• Blog posts
• Attachments
• Comments

Not backed up:

• Pages with restricted access the connected account cannot see. This is an Atlassian API constraint, not a ProBackup choice; grant access to the connected user and they are included from the next snapshot.
• Site configuration: permissions schemes, templates, macros settings and app data are outside the backup scope [verify].

ProBackup captures the first 2,000 characters of a text field for table display; page bodies are stored in full [verify]. Snapshots are retained for 6 months on Plus, 2 years on Pro and without limit on Premium.

How to restore deleted Confluence pages

ProBackup supports two restore modes across its platforms: create new duplicates (originals left untouched) or overwrite existing records field by field. For Confluence, the help centre documents the duplicate mode [verify: overwrite mode availability for Confluence]:

1. Open the Confluence backup in ProBackup and pick the snapshot date before the deletion or the bad edit.
2. Browse to the space and select the page or blog post. Use Compare to check the content against a later snapshot if you are unsure which version you need.
3. Click Restore. A duplicate is created under the original parent page or, for top-level content, in the original space. Your live pages are never overwritten.
4. Review the restored page and move it in the page tree if needed.

Restore is documented for pages and blog posts. Comments and attachments are stored in every snapshot and can be viewed and downloaded [verify: whether comments and attachments are restored together with the page].

Restores go back to the original Confluence site only. ProBackup is a backup tool, not a migration tool.

Global Search (unlimited on Pro and Premium; 3 free uses per month on Plus) finds a page across every snapshot when you only remember a phrase from it. Smart Alerts (Pro and Premium plans) flag unusual deletions in the daily report.

Frequently asked questions

How often is Confluence backed up?

Every 24 hours, automatically. Each snapshot is a full copy of the API-available content, so you can browse any day in your version history, compare two snapshots and restore from the one you want.

Where is my Confluence backup stored?

On AWS S3, in the AWS region you select at signup (nine regions are available). Changing region after the first backup requires support assistance. Data is encrypted with AES-256 at rest and TLS in transit. On Pro and Premium plans you can also sync a copy to your own Google Drive.

Can I back up Jira and Confluence together?

Yes. Jira and Confluence are separate integrations in ProBackup, each connected via OAuth to the same Atlassian site. One licence covers your whole team on each platform; there is no per-seat pricing.

Protect your Confluence data today

ProBackup is trusted by 4,000+ teams and rated 4.8 on G2. Plans start at $25 per month, billed yearly.

Start your free 7-day trial - no credit card required.

In short: To back up Basecamp, connect ProBackup to your Basecamp account via OAuth, choose the projects to protect, and the first snapshot runs within 24 hours. To-dos, messages, documents, uploads, events, comments and people are then copied daily to independent AWS storage. Deleted to-dos, messages, uploads, attachments and table cards can be restored back into Basecamp from any snapshot.

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account. For Basecamp, that means a dated copy of every project that does not expire when the Trash does.

Why Basecamp's Trash is not a backup

Basecamp's Trash is well designed for the "oops, undo" case. It is not designed for anything else (checked 2026-09-16):

Twenty-five days is short. It is shorter than most quarterly reviews, shorter than a typical notice period, and shorter than the time it takes many teams to notice that a customer's project has gone quiet because someone trashed it. "Until you empty the Trash" is shorter still: one tidy-up by a well-meaning admin and the window is zero.

And Trash only catches deletions. A to-do list overwritten by a bulk edit, a message body replaced, a schedule wiped by an integration or an AI agent acting at machine speed: none of that lands in Trash, because nothing was deleted.

How to back up Basecamp with ProBackup (step by step)

Setup takes about three minutes.

1. Create your ProBackup account. Go to app.probackup.io/onboarding. The 7-day trial needs no credit card. Choose the AWS region for your snapshots; nine regions are available and you pick at signup (changing it after the first backup requires support assistance).
2. Connect Basecamp via OAuth. Select Basecamp from the platform list and authorise ProBackup in Basecamp. ProBackup never sees your password; tokens are stored encrypted with AES-256.
3. Choose the scope. Select the Basecamp account and the projects and teams to include. [verify: exact scope-picker behaviour for Basecamp in the current app]
4. Wait for the first snapshot. It starts automatically and finishes within 24 hours, then repeats every 24 hours with nothing to schedule.
5. Browse the vault. Open any snapshot to see each project's lists, to-dos, messages, documents, uploads and events as of that date.

Snapshots sit in AWS S3 with AES-256 encryption at rest and TLS in transit. ProBackup has been SOC 2 Type II certified since May 2025 and is GDPR compliant.

What is (and is not) backed up for Basecamp

ProBackup backs up all data the Basecamp API exposes within its scope:

• Projects and Teams
• Lists and To-dos
• Messages
• Documents
• Uploads (files)
• Table cards
• Events (schedule entries)
• Automatic check-ins
• Comments
• People

Not backed up today:

• Campfire (chat)
• Pings (direct messages)
• Templates
• Chatbots
• Client approvals, correspondences and replies

These are not available through Basecamp's API; ProBackup will add them as soon as they become available. If your team relies on Campfire for decisions, the safest habit is to summarise outcomes into a message or document, which is backed up.

Version history depends on your plan: Plus keeps 6 months of snapshots, Pro keeps 2 years and Premium keeps an unlimited history.

How to restore deleted Basecamp to-dos, messages and files

From any daily snapshot, ProBackup restores five item types straight back into Basecamp:

• A to-do. A duplicate is created in the related list, with its comments and files.
• A message. A duplicate is created in the related project.
• An upload. The file is added back to the related project.
• An attachment. The file is added back to the related item.
• A table card. A duplicate is created in the related project.

Restores for Basecamp create new copies; existing data is never overwritten. That makes a restore safe to run first and review afterwards: if the original turns up in Trash after all, delete the copy.

To run a restore: open the backup, pick the snapshot date from before the deletion, locate the to-do, message, upload, attachment or table card, and click Restore. The item appears in the same list or project it came from.

For a whole project that was trashed and then permanently deleted, restore the to-dos, messages, uploads and table cards individually or in bulk from the snapshot; the project container itself must exist (or be recreated) first. [verify: bulk-select behaviour for Basecamp restores]

FAQ

How long does Basecamp keep deleted items in the Trash?

Twenty-five days, or until someone empties the Trash, whichever comes first (Basecamp help, checked 2026-09-16). After that, items and whole projects are permanently deleted and Basecamp has nothing to restore. Account owners can view and restore trashed items across every project during that window.

Does ProBackup back up Basecamp Campfire chats?

No. Campfire, pings, templates, chatbots and client approvals, correspondences and replies are not exposed by Basecamp's API and are outside the backup scope. Projects, teams, lists, to-dos, messages, documents, uploads, table cards, events, automatic check-ins, comments and people are all included.

Will restoring a to-do overwrite the current one?

No. Basecamp restores always create a duplicate in the related list, project or item; live data is left untouched. Plans start at $25 per month, billed yearly, with 6 months of version history on Plus, 2 years on Pro and unlimited on Premium.

Start backing up Basecamp today

Connect Basecamp in three minutes and get your first snapshot within 24 hours. No credit card, no manual export, and a restore button that still works on day 26.

Start your free 7-day trial

In short: Most SaaS apps keep deleted items for 30 days (HubSpot 90, Airtable 7 at record level); Trello and Jira Cloud keep nothing. Version history is either absent or capped by plan. Every window below is taken from the vendor's own documentation, checked 16 September 2026, and set against ProBackup's retention: Plus 6 months, Pro 2 years, Premium unlimited.

Retention windows at a glance (checked 2026-09-16)

A trash window is how long a deleted item can be put back with a click; a version-history window is how far back you can see (and occasionally revert) changes to an item that still exists. Neither is a backup.

Asana

Deleted tasks and projects sit in the "Deleted items" view for 30 days, then are permanently deleted (Asana Help, checked 2026-09-16). Asana publishes no version-history window: the activity feed on a task shows that a value changed and who changed it, but there is no rollback of a field, task or project to an earlier state. Comments deleted directly and custom-field values removed when a field is deleted have no recovery path inside Asana.

ClickUp

Deleted Spaces, Folders, Lists, tasks and Docs stay in Trash for 30 days (ClickUp Help, checked 2026-09-16); Workspace owners and admins can restore them, and a member can restore items they both created and deleted. ClickUp has no field-level version history and no rollback: if a task still exists but its status, custom fields or description were overwritten, there is no earlier version to return to.

monday.com

monday.com's Trash retains deleted boards, items, columns, groups, docs and dashboards for 30 days (monday.com support, checked 2026-09-16). Change history lives in the activity log, and its depth depends on the plan: Basic 1 week, Standard 6 months, Pro 1 year, Enterprise 5 years (The Activity Log). The activity log is read-only; it tells you which column value changed and when, but it does not revert the change, and updates (comments) deleted directly do not pass through Trash at all.

Trello

Trello has no trash: a permanently deleted card, list or board cannot be recovered, while archiving is reversible. Atlassian's documentation states that "deleting a card is permanent, and deleted cards can't be restored" (Archiving and deleting cards, checked 2026-09-16) and the same for boards (Deleting a board). There is no version history: a card's activity log lists moves, due-date changes and comments but cannot restore a previous description, checklist or custom-field value.

HubSpot

Deleted records can be restored from the recycle bin for 90 days (HubSpot Knowledge Base, checked 2026-09-16); permanent and GDPR-related deletions bypass the bin and are gone immediately. HubSpot is the only platform in this table with a real rollback tool: Restore CRM changes lets a Super Admin roll records back to a point up to 14 days ago, undoing manual edits, imports, integration writes and workflow changes on Starter tiers and above (Restore CRM changes).

Airtable

Base trash keeps deleted records, fields and tables for 7 days; workspace trash keeps deleted bases and workspaces for 30 days, and Enterprise Scale admins can set 30, 60, 90 or 180 days (Managing trash in Airtable, checked 2026-09-16). Record revision history runs Free 2 weeks, Team 1 year, Business 2 years, Enterprise Scale 3 years (Record-level revision history). Revision history shows who or which automation, sync or API call changed a record; it does not offer a one-click revert, and changes to synced data are hidden from it.

Notion

Trash keeps deleted pages 30 days on all plans (Notion Help, checked 2026-09-16); Enterprise workspace owners can customise the setting. Page history is 7 days on Free and longer on paid plans: the same article lists Plus 30 days, Business 90 days and Enterprise "any number of days". Page history restores a whole page to an earlier version; it is not a per-property undo for a database, and anything emptied from Trash is not recoverable.

Jira Cloud

There is no trash: a deleted issue and its comments, attachments and subtasks are gone; only the audit log records the deletion. Atlassian's knowledge base states that a deleted work item "is removed from the database and can no longer be accessed or viewed", that "Atlassian backups cannot be used to restore work items", and that restoration is only possible "if you have an existing backup file to import" (Atlassian Support, checked 2026-09-16). The History tab on a live work item lists field changes but has no revert action.

What none of these windows cover

• Overwrites. A task, record or page that still exists but holds the wrong values is not in any trash. Only HubSpot (14 days) and, for whole pages, Notion offer a native way back.
• Bulk edits. A mis-mapped import or mass status change touches hundreds of records at once; logs list each change, but reverting them one by one is not practical.
• Integration and automation writes. Automations, AI assistants and API scripts write with a user's permissions and leave the same one-way trail.
• Departed-user data. Private tasks and projects of a person who leaves the platform leave with their account; in a ProBackup backup they stay and remain visible to the ProBackup admin.
• Anything older than the window. A deletion noticed on day 31 in Asana, ClickUp or monday.com, day 8 in an Airtable base, or day 91 in HubSpot has no native path back.

How ProBackup retention compares

ProBackup takes a snapshot of each connected app every 24 hours, with no scheduling required; a new revision of a record is stored only when its content changes. Retention depends on the plan: 6 months on Plus, 2 years on Pro and unlimited on Premium (pricing). Every past snapshot is a point-in-time view of the whole account, so a record overwritten in March can be read and restored as it was in February, whether the platform's own log still shows the change or not (daily snapshots).

Restores go back to the original account as new duplicate records or, for HubSpot, ClickUp, Asana, monday.com, Airtable and Attio, by overwriting the existing record field by field; calculated fields (system fields, formulas, relations) are excluded. Text fields are captured up to the first 2,000 characters. ProBackup is SOC 2 Type II certified (May 2025) and GDPR compliant, with AES-256 encryption at rest and TLS in transit.

Platform pages: Asana · ClickUp · monday.com · Trello · HubSpot · Airtable · Notion · Jira.

FAQ

How long do deleted items stay in the trash in Asana, ClickUp and monday.com? 30 days in each. Asana holds deleted tasks and projects in the "Deleted items" view for 30 days; ClickUp's Trash and monday.com's Trash both retain deleted items for 30 days. After that the item is permanently deleted and the vendor cannot recover it.

Which platforms have no trash at all? Trello and Jira Cloud. In Trello a permanently deleted card, list or board cannot be recovered (archiving is the reversible alternative). In Jira Cloud a deleted issue and its comments, attachments and subtasks are gone; only the audit log records the deletion.

Where does version history depend on the plan? monday.com (activity log: Basic 1 week, Standard 6 months, Pro 1 year, Enterprise 5 years), Airtable (record revision history: Free 2 weeks, Team 1 year, Business 2 years, Enterprise Scale 3 years) and Notion (page history: 7 days on Free, longer on paid plans). None of these is a rollback button except Notion's page-level restore.

Can HubSpot undo changes to records that were not deleted? Yes, for up to 14 days, with Restore CRM changes (Starter and above, Super Admin permissions). Deleted records are separate: they can be restored from the recycle bin for 90 days, unless they were permanently or GDPR-deleted.

How long does ProBackup keep snapshots? 6 months on Plus, 2 years on Pro and unlimited on Premium. Snapshots are taken every 24 hours, and any past snapshot can be browsed and restored, so the retention window is the only limit, not the type of change.

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.

In short: NIS2 (Directive (EU) 2022/2555) makes backup management a legal duty under Article 21(2)(c) for essential and important entities in covered sectors, generally those with 50 or more employees or over EUR 10 million turnover. The transposition deadline was 17 October 2024; Germany's law applied from 6 December 2025 with fines up to EUR 10 million or 2% of turnover.

The EU's cybersecurity directive turns backup management into a legal duty, and the enforcement phase has started.

For years, backing up business data was a best practice you could defer. NIS2 changes the category. For organisations in scope, backup management is now a legal obligation, with fines and personal liability for management attached to getting it wrong.

The transposition deadline passed in October 2024, and as of September 2026 the map has largely filled in. Most member states have national NIS2 laws in force. Germany's implementation took effect on 6 December 2025 with no transition period, and in July 2026 the European Commission referred the remaining laggards, including Ireland, Spain, France and the Netherlands, to the Court of Justice. The first national fines have already been issued.

Yet many operations and IT leads at mid-sized companies still treat NIS2 as an enterprise problem. The size thresholds say otherwise. This post covers who is in scope, where backups sit in the directive, and what a defensible backup posture looks like for the data your teams keep in SaaS platforms.

What is NIS2 and who is in scope?

NIS2 is Directive (EU) 2022/2555, the EU's network and information security directive. It entered into force in January 2023, replaced the original NIS Directive, and required member states to transpose it into national law by 17 October 2024. It sets minimum cybersecurity risk-management measures and incident-reporting duties for "essential" and "important" entities across sectors such as energy, transport, banking, healthcare, water, digital infrastructure, waste management, chemicals, food production, and manufacturing of machinery, vehicles, medical devices and electrical equipment.

The scope test is the part mid-sized companies underestimate. Under most national implementations, an entity in a covered sector is in scope if it has 50 or more employees or annual turnover above EUR 10 million. Reed Smith's January 2026 client alert on the German implementation notes that many organisations never previously regulated under EU or German IT security law are now captured, including medium-sized enterprises in key value chains.

Germany is a useful anchor for how national enforcement now works. Its NIS2 law applied immediately from 6 December 2025, without a grace period, and in-scope entities had to register with the BSI, the federal cybersecurity office, by 6 March 2026. Fines can reach EUR 10 million or 2% of annual turnover for large "very important" entities, and management bodies carry personal liability for culpable failures (Reed Smith, January 2026). Other member states differ in detail, so check the transposing act in each country where you operate.

Key takeaway: if your organisation operates in a covered sector anywhere in the EU and has 50 or more employees or more than EUR 10 million in turnover, assume you are in scope until a proper assessment says otherwise.

Where backups sit in the directive

Article 21(2) of NIS2 lists the minimum risk-management measures every in-scope entity must implement. Point (c) requires "business continuity, such as backup management and disaster recovery, and crisis management." Backup management is named in the directive's text, not inferred from it. An auditor or supervisory authority reviewing your Article 21 measures will expect to see a backup programme as a distinct, evidenced control.

Two neighbouring provisions widen the blast radius. Article 21(2)(d) requires supply chain security, which means in-scope customers must assess the security of their suppliers and service providers. Even if your company sits below the thresholds, expect NIS2-style backup and continuity questions to arrive through customer security reviews and contracts. And the management accountability rules mean continuity failures are no longer an IT problem alone: in Germany, management members must undergo regular cybersecurity training and can be held personally liable.

Incident reporting adds urgency. Under Germany's implementation, a significant incident triggers an initial notification within 24 hours, a detailed report within 72 hours, and a final report within a month (Reed Smith, January 2026). Meeting a 24-hour clock while also recovering operations is only realistic if restore procedures already exist and have been tested.

Important context: NIS2 does not prescribe a backup technology, frequency or vendor. It requires measures that are appropriate and proportionate to the risk. In practice that is a governance test: can you show what you back up, how often, where the copies live, and that restoring from them actually works?

Why SaaS data is the gap in most NIS2 backup programmes

Most NIS2 remediation work centres on infrastructure: servers, endpoints, databases, network equipment. The operational data your teams keep in cloud apps such as Asana, ClickUp, monday.com, HubSpot, Jira or Notion often never makes it into the backup inventory, because everyone assumes the vendor handles it.

The vendor does back up data, but for its own disaster recovery. If a team member deletes a project, an import overwrites the wrong field, or a third-party integration corrupts records, the vendor's infrastructure backup will not roll your account back. Under the shared responsibility model that governs SaaS, data inside your account is yours to protect, and if the business depends on that data, it belongs inside your Article 21 continuity measures.

Agentic AI sharpens the point. AI agents now create, edit and bulk-delete records inside these platforms autonomously. A misfired agent or a badly scoped instruction can corrupt thousands of records at machine speed, before anyone notices. A continuity programme written in 2023 that never contemplated this failure mode is due an update.

Five backup gaps that surface in NIS2 assessments

1. SaaS platforms missing from the backup inventory. The gap assessment maps servers and databases but skips the work management and CRM tools that actually run daily operations.
2. No restore testing. Backups exist, but nobody has restored a record, a project or a whole workspace from them. An untested backup is an assumption, and assumptions do not satisfy auditors.
3. Retention too short for slow-burn incidents. Data corruption is often noticed weeks or months later. If your version history only reaches back days, the clean copy is already gone.
4. Copies stored inside the system they protect. Periodic exports saved into the same workspace, or backups reachable with the same credentials, fail together with the source.
5. No evidence trail. Backups run, but there are no logs, status reports or documented procedures to show a supervisory authority or a customer's security review.

What good looks like

• Inventory every system the business depends on, cloud apps included, and record which ones hold data you could not afford to lose; a SaaS backup policy template gives you a structure to write it down in.
• Keep an independent copy outside the source platform, under separate credentials, encrypted at rest and in transit.
• Back up daily and keep version history long enough to survive incidents discovered late, which is worth checking against the retention options on each plan.
• Document a restore procedure that covers both granular recovery (one record, one file) and bulk recovery (a whole project or board), and test it on a schedule.
• Write the facts down: what is covered, what the platform API cannot expose, where copies are stored, and who owns the process. This documentation doubles as audit evidence, alongside artefacts such as a vendor's SOC 2 Type II audit report.
• Ask your own critical vendors the same questions your in-scope customers will ask you.

Where a SaaS backup service fits

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account.

For the SaaS slice of an Article 21 continuity programme, the relevant facts are these: daily automated snapshots with no scheduling required, two restore modes (safe duplicates or field-by-field overwrite), AES-256 encryption at rest and TLS in transit, a SOC 2 Type II report (certified May 2025), GDPR compliance, and storage in one of nine AWS regions that you select at signup, which keeps data residency under your control. Version history runs six months on Plus, two years on Pro and unlimited on Premium, which matters directly for the slow-burn incident problem above.

Good for: covering the cloud app portion of your backup inventory; demonstrating an independent, encrypted, residency-controlled copy to auditors and customer reviews; granular rollback after human or AI-agent error.
Not recommended for: your entire NIS2 programme (a SaaS backup tool says nothing about your network, endpoints or incident response); data a platform's API does not expose; a substitute for legal advice on whether and where you are in scope.

ProBackup Expert Note: a backup you have never restored from is a liability wearing the costume of a control. Restore one record and one full project each quarter, screenshot the result, and file it with your compliance evidence. It takes minutes and it is exactly the artefact an assessor asks for first.

Frequently asked questions

How does NIS2 define backup requirements?

Article 21(2)(c) requires business continuity measures, explicitly including backup management and disaster recovery. The directive does not prescribe tools or frequencies; measures must be appropriate and proportionate to the entity's risk, and demonstrable to the supervisory authority.

Why does NIS2 matter if my company is below the size thresholds?

Because of Article 21(2)(d) on supply chain security. In-scope customers must assess their suppliers' cybersecurity, so smaller vendors inherit backup and continuity expectations through security questionnaires and contract clauses even without a direct legal obligation.

Where should NIS2-relevant backups be stored?

Outside the system they protect, under separate access controls, encrypted at rest and in transit. If data residency matters to your obligations, choose a provider that lets you pick the storage region. ProBackup stores snapshots in the AWS region you select from nine options at signup.

How fast must incidents be reported under NIS2?

The directive sets a layered scheme that national laws implement: an early warning within 24 hours of becoming aware of a significant incident, a detailed notification within 72 hours, and a final report within a month. Germany's implementation follows this pattern (Reed Smith, January 2026).

The basics, evidenced

NIS2 does not ask for heroics. It asks organisations to prove that the basics work: know what you depend on, keep independent copies, restore on demand, and show the paperwork. The companies that struggle with enforcement will not be the ones missing exotic tooling. They will be the ones that cannot produce a tested restore when a regulator, an auditor or a customer asks.

If your gap assessment has not yet reached the data in your cloud apps, that is the cheapest item on the list to fix, and after the first incident it is the one you will be gladdest you did.

This article is written for IT managers and operations leads at organisations in or near NIS2 scope who are responsible for business data held in SaaS platforms. It is general information, not legal advice; scoping decisions belong with your counsel.

‍Which tool fits which stack, and where our own product isn't the right answer.

In short: the best SaaS backup tool depends on what you need to protect. ProBackup covers 20+ work apps (Asana, monday.com, ClickUp, HubSpot, Airtable and more) with daily snapshots, browsable history and item-level restore under a single licence. Rewind is the pick for e-commerce data, FluentPro for enterprise project portfolios, SysCloud for education suites, Skyvia for data teams, On2Air for Airtable-only teams and BackupLabs for developer tools.

Your SaaS vendor keeps its platform running. Under the shared responsibility model, that's where its job ends: the data you put into the platform is yours to protect. Recycle bins expire, version history is shallow, and a botched bulk import or an AI agent with write access can corrupt thousands of records without deleting a single one. Third-party backup tools exist to close that gap.

What to look for in a SaaS backup tool

Six questions sort most of the market:

• Does it cover your whole stack under one licence, or do you pay per app?
• Can you actually see what's in the backup? Some tools let you browse records, comments and files by date; others only tell you a backup ran and hand you a JSON file. Being able to search across every backup at once turns that browsing into a few seconds' work.
• How granular is the restore? Recovering a single task, record or file beats rolling back a whole board. Check whether restores create safe copies, overwrite existing records in place, or give you the choice.
• Where do the backups live? Outside the vendor's own infrastructure, encrypted, ideally in a region you choose.
• How far back can you go? Daily snapshots with months of history let you unwind slow-burning corruption, not just yesterday's mistake.
• What's the security posture? Look for SOC 2 Type II (an independent audit of security controls over time), GDPR compliance and AES-256 encryption at rest and in transit.

The seven tools, compared

1. ProBackup: one licence for 20+ work apps

ProBackup (that's us) runs daily automated backups for more than 20 SaaS apps, including Asana, monday.com, ClickUp, HubSpot, Airtable, Trello, Notion, Jira and Slack. CRM coverage goes beyond HubSpot, too: see our Attio CRM backup launch, and project tools beyond the big four, such as Teamwork.com. One licence covers all of them, priced by storage rather than per app or per seat; plans start at $25 per month, billed yearly.

The vault mirrors the source app: a tree of workspaces, projects and boards in the sidebar, tabs for tasks, comments and files, a date picker to step back through snapshots, and version history on each record so you can compare what changed. Global search runs across every app in the account. Restore works at whatever level the damage is at: a whole project or board, a single task or record with its comments and files, one comment, one file, or a deleted custom field. Restore has two modes: create a new copy alongside the original, which is the safe default for a test restore, or overwrite the existing record field by field when you want to roll one item back without cleaning up duplicates afterwards. Backups are encrypted with AES-256 and stored on AWS in one of nine regions you pick at onboarding. ProBackup is SOC 2 Type II certified and GDPR compliant, and an optional Google Drive sync keeps a second copy as live Google Sheets that update in place. For what a restore looks like in practice, see our success stories, and for what changed in ProBackup 3.0, our year in review.

Good for: teams running several work apps who want one backup layer across all of them, with browsable snapshots and item-level restore.

Not recommended for: e-commerce data such as Shopify stores (Rewind's home turf) or on-premise systems.

2. Rewind: the e-commerce specialist

Rewind built its name on Shopify and QuickBooks Online and has since added work apps such as Trello and monday.com. It's mature, widely reviewed and holds broader certifications than most of this list (SOC 2, ISO 27001, HIPAA). For work-management apps the model is simpler than the marketing suggests: you find records through text search, filter by type and compare a record to its current version, but you can't view all cards or items for one board at once. Restore, as of August 2026, is a whole board rolled back to a point in time. If one card went missing, you roll back everything on that board. Each app is a separate subscription, priced per board on Trello and per seat on monday.com. Its monday.com Sidekick integration lets you ask the AI assistant about backup status inside monday, which is neat, though we'd still do restores in Rewind's own app. We compare the two in ProBackup vs Rewind for monday.com and ProBackup vs Rewind for Trello.

Good for: Shopify- and QuickBooks-centric businesses that want one vendor for store and accounting data, or teams that need HIPAA.

Not recommended for: stacks built on project management and CRM apps, where board-only restore and per-app subscriptions add up.

3. FluentPro: enterprise project portfolios

FluentPro comes from the Microsoft Project and PPM (project portfolio management) world, and FluentPro Backup covers Asana, monday.com and Smartsheet among others. Its distinctive feature is scheduling: backups every 4, 8, 12 or 24 hours, with retention rules you set per day, week, month and year. That's more control than anyone else here offers. The trade-off is what you can do with the backups once they exist. The interface shows workspace and project names for each version, not the underlying tasks or files, and restore means putting an entire workspace back into Asana. There's no browsing, searching or item-level recovery. Pricing is storage-based, from $50 a month for 50 GB. See ProBackup vs FluentPro for Asana.

Good for: PMOs (project management offices) that need sub-daily backup frequency and are already on FluentPro's migration and governance tooling.

Not recommended for: teams that expect to open a backup, find one task and put it back.

4. SysCloud: productivity suites and education

SysCloud is built for Google Workspace and Microsoft 365, with strong traction in education, and also covers HubSpot, QuickBooks Online, Xero, Box and Slack. On HubSpot it's the closest match to ProBackup on this list: coverage of contacts, companies, deals, engagements and custom objects is comparable, you can browse records and related engagements in the interface, and it restores at record level. Like ProBackup, it can restore a record either as a new copy or by overwriting the existing one in place. Retention is unlimited. The catch is the commercial model: per seat, per app, with global search and change analytics sold as add-ons on a sales quote. See ProBackup vs SysCloud for HubSpot.

Good for: schools and IT teams protecting Google Workspace or Microsoft 365 at seat scale.

Not recommended for: teams whose critical data lives in Asana, monday.com, ClickUp or Trello, which SysCloud doesn't cover.

5. Skyvia: a data platform with backup included

Skyvia is first a cloud data-integration platform (ETL, meaning extract, transform and load, plus sync and query) where backup is one product among five. Its coverage of CRMs and databases is broad, you can trigger a backup manually whenever you like, exclude data types such as attachments to save storage, and sync to Google Drive, OneDrive or Dropbox. The interface is where the developer orientation shows. Every record of a given type lands in one flat table across all projects, with parent projects shown as ID numbers rather than names, so finding one task means filtering by reference rather than browsing a project. It doesn't back up Asana comments at all. Restore supports both insert and update. Pricing jumps from $7 a month for 20 GB to $79 for the next tier. We cover the differences in ProBackup vs Skyvia for Asana and for HubSpot.

Good for: data teams that already want integration pipelines and are comfortable working in flat tables and IDs.

Not recommended for: admins or project managers who need an app-shaped view of their data or comment history.

6. On2Air: the Airtable power tool

On2Air is built only for Airtable and is well known in the Airtable power-user community. It offers more scheduling choice than we do (hourly, daily, weekly or monthly, though hourly needs the $79.99 Premium plan) and syncs to Google Drive, Box, Dropbox or OneDrive. It's best understood as an export tool. You can see which bases and tables have been backed up, but not the records, comments or files inside them; to look at data you open the CSV and JSON files it drops into your storage, and it writes a fresh set every cycle, so folders fill up fast. Restore is a whole base or a whole table, which overwrites anything changed since the snapshot. The daily-backup Pro plan is $49.99 a month and includes five base restores. See ProBackup vs On2Air for Airtable.

Good for: Airtable-only teams whose main need is scheduled exports to external storage, especially if hourly frequency justifies the price.

Not recommended for: teams that want to browse a backup, recover one record or comment, or protect anything other than Airtable.

7. BackupLabs: simple per-app backups for dev tools

BackupLabs runs daily backups for a developer-leaning list: Trello, GitHub, GitLab and Jira among them. Setup is quick, it holds SOC 2, GDPR and ISO 27001, and pricing is simple, from $8 a month for 10 Trello boards. Like On2Air, it's export-first. There's no way to look at a card, file or comment in the interface; you download a board as JSON and read it there. Restore is board-level only. Each platform needs its own subscription. See ProBackup vs BackupLabs for Trello.

Good for: protecting one or two developer tools cheaply where a whole-board rollback is an acceptable recovery unit.

Not recommended for: multi-app stacks, or anyone who'll need to find and restore a single item under pressure.

How to choose

Match the tool to the shape of your stack:

• Several work apps (project management plus CRM plus docs): a multi-app tool with browsable snapshots and item-level restore, which is where ProBackup fits.
• Shopify or QuickBooks at the core: Rewind.
• Enterprise PMO that needs backups every few hours: FluentPro.
• Google Workspace or Microsoft 365 at seat scale, especially education: SysCloud.
• Data pipelines and backup in one platform: Skyvia.
• Airtable and nothing else, mainly for exports: On2Air, or ProBackup if you want to browse and restore individual records.
• One or two dev tools with board-level rollback: BackupLabs, or ProBackup for item-level restore across a wider stack.

For an outside view of the same criteria, read our interview with SafetyDetectives.

Frequently asked questions

Doesn't my SaaS vendor already back up my data?

Vendors back up their platform to survive their own infrastructure failures, not to recover your mistakes. If a teammate, integration or AI agent deletes or overwrites your records, recycle bins and version history rarely save you. Independent backups exist for that gap.

How often should SaaS backups run?

Daily is the practical standard. It caps your worst-case data loss (your recovery point objective, or RPO) at 24 hours without hammering vendor API limits. A few tools go hourly, at a price.

Can one tool back up my whole SaaS stack?

Multi-app tools such as ProBackup cover 20+ work apps under one licence; specialists such as On2Air or BackupLabs cover one app per licence. Count the apps that hold business-critical data before you choose. Per-app licences add up quickly.

How do I know my backup actually works?

Test it before you need it: restore a single item from a recent snapshot as a new record, verify fields, comments and attachments, then delete the copy. Our guide to testing SaaS backups walks through the 20-minute drill, and what a ProBackup snapshot actually contains explains what you should expect to find.

Ready to protect your stack? Start a free 7-day trial of ProBackup: daily automated backups and item-level restore for 20+ SaaS apps, no credit card required.

Written for IT admins, ops leads and founders choosing a backup layer for a multi-app SaaS stack.

Your CRM is probably the most commercially sensitive dataset your company owns. Pipeline, contacts, deal history, the notes your sales team took eighteen months ago that suddenly matter again. And yet CRM data sits under the same shared responsibility model as every other SaaS tool: the vendor keeps the platform running, but protecting your account data against accidental deletion, a bad import or a disgruntled leaver is on you.

That's why we're pleased to announce that ProBackup now supports Attio. With this launch, we cover three leading CRM platforms: HubSpot, Pipedrive and Attio.

Why Attio

If you haven't come across Attio yet, you will. Founded in London in 2021, it has positioned itself as an AI-native CRM built for what it calls "go-to-market builders": teams that want a flexible data model rather than the rigid objects of legacy CRMs. As of August 2025, over 5,000 companies build their go-to-market on Attio, including AI companies like Lovable and Granola, and the company raised a $52 million Series B led by GV (Google Ventures) that same month.

In short, Attio is where a growing share of fast-moving companies now keep their most valuable commercial data. Our customers asked for it, and we listened.

What we back up for Attio

ProBackup takes automated daily snapshots of your Attio workspace. As of August 2026, we back up:

• Companies, People and Deals (records)
• Users and Workspaces
• Lists
• Notes, Tasks and Comments
• Files

What we don't back up: Emails, calls, reports, sequences, workflows and chats aren't currently included, mostly down to what Attio's API exposes. We'd rather tell you that upfront than let you find out during an incident.

How restore works

Backups only matter if you can get data back out. When you restore Attio records, you choose between two options:

1. Restore as new records. Creates a copy of the selected records in the related Attio table. This is the safest option and doesn't touch any existing record.
2. Overwrite existing records. Updates existing records with the backed-up field values, with a field picker so you decide exactly which columns roll back. Useful when a record still exists but someone has mangled it, say through a bad bulk edit or a wrong CSV import.

Notes, tasks, comments and files are restored as duplicates in your Attio account, so nothing in your live workspace gets overwritten by accident.

Good for / not recommended for

• ✅ Good for: Teams that want daily, automated protection of Attio records, notes, tasks and files, with granular restore back into the same workspace.
• ❌ Not recommended for: Teams looking to back up Attio emails, calls or workflows, or to migrate data between CRM platforms. ProBackup restores to the original instance only.

Three CRMs, one backup layer

CRM data loss rarely announces itself. It's a rep tidying up "duplicate" companies that weren't duplicates, an integration writing garbage into a field overnight, or an offboarded admin whose deletions nobody notices for weeks. Native recycle bins help, but they're time-limited and they don't protect against overwritten field values at all.

Whether your team runs on HubSpot, Pipedrive or Attio, ProBackup now gives you the same safety net: daily snapshots, point-in-time recovery and restores granular enough to bring back a single record. Plans scale with data usage and start at $25/month (billed yearly).

Attio backup is available today on all plans. Connect your Attio workspace to run your first snapshot, or see which plan fits your team.

Written for IT admins, RevOps leads and founders responsible for protecting their company's CRM data.

‍

In short: A SaaS disaster recovery plan is a short, tested procedure for restoring data after an incident, distinct from a backup policy. Build it in six steps: define threat scenarios (bulk deletion, bad import, compromised account, malicious insider, provider outage, silent corruption), set RTO and RPO per app, map recovery resources and named people, write a runbook, assign roles, test it.

Your backup policy documents the rules. A disaster recovery plan documents what you actually do when things go wrong.

They're different documents for different moments. The backup policy sits in your internal wiki. It tells you what gets backed up, how often, who owns it. It's written when things are calm and consulted during audits. The disaster recovery plan is what you open at 11pm when your ops lead calls to say the project board is gone. It tells you, step by step, what to do in the next two hours.

Most teams have something resembling a backup policy. Almost none have a disaster recovery plan for their SaaS apps. They assume they'll figure it out when it happens. That assumption fails in two ways: you make worse decisions under pressure, and the person who needs to act might not be the person who knows where the backups are. And because your SaaS provider won't be doing this for you, the plan needs to exist on your side.

This post walks you through building one. It's structured as a sequence of steps because that's how a DRP works: you don't improvise, you follow the plan.

What a SaaS disaster recovery plan is (and isn't)

A DRP for SaaS apps is a documented, tested procedure for restoring data and resuming normal operations after an incident.

It is not a backup policy (that's the governance document), a business continuity plan (which covers broader operational resilience, not just data), or an IT incident response plan (which covers security breaches at the system level). Each of those is a different document with a different scope.

Your SaaS DRP is narrower and more operational. It answers: which specific scenarios might affect our SaaS data, who does what when they happen, and how do we restore things in the right order. For most teams it fits on two pages. It should be findable when the person who wrote it is unavailable.

Step 1: Define your threat scenarios

Generic "data loss" is not a useful planning unit. The actions you take after an accidental bulk deletion are completely different from the actions you take after a ransomware attack. Start by listing the specific scenarios your plan needs to cover.

The six most common for SaaS-dependent teams:

Accidental bulk deletion. A team member deletes a project, board, or significant set of records. The most frequent scenario. Usually discovered within hours. Recovery is typically straightforward if backups exist.

Bad import or integration error. A CSV import overwrites field values across hundreds of records. A third-party integration misfires and clears or corrupts data. Nothing was deleted, so the recycle bin won't help. These are among the most common data loss scenarios and among the hardest to detect quickly.

Compromised account. A team member's credentials are stolen. The attacker, or the compromised employee, deletes or exports data before the account is locked. The Snowflake breach in 2024 showed this pattern at scale: stolen credentials, no MFA, significant data loss across 160+ organisations. Your ransomware protection posture matters here.

Malicious insider. A departing employee with admin access systematically deletes data before leaving. This is different from an accident: the deletion is intentional and may include emptying the recycle bin to eliminate the most obvious recovery path.

Provider outage. Your SaaS app is unavailable for an extended period. This isn't a data loss scenario in the traditional sense, but if your team needs to access data during the outage (for client meetings, calls, ongoing work), your DRP should cover how to access it. Google Drive sync creates a readable copy of your backup data that's accessible even if the source app and ProBackup are both temporarily down.

Silent data corruption. Data is modified incorrectly over days or weeks before anyone notices. The recycle bin has long expired by the time the problem is found, and the clean snapshot needed may be weeks in the past.

For each scenario, document: how you'd detect it, the likely data impact, and the approximate time sensitivity (how long before the recovery window closes or the business impact becomes critical).

Step 2: Set your RTO and RPO per app

Before you can plan a recovery, you need to know what "recovered" means. That requires two numbers per app.

Recovery Time Objective (RTO) is how long the team can function without the data. Recovery Point Objective (RPO) is how much data loss is acceptable, measured in time since the last clean snapshot.

For a quick DRP, you don't need to calculate these for every app. Focus on your Tier 1 apps (the ones you identified in your SaaS data protection audit) and document a realistic RTO and RPO for each.

A practical format for setting these is to think about operational dependency: the tighter the RTO, the more the team is blocked without that data. CRM data tends to block client-facing work within hours. Project boards can usually wait a day. Knowledge bases rarely cause a crisis if they're down overnight.

AppRTORPONotesAsana4 hours24 hoursSales team blocked after half a dayHubSpot2 hours24 hoursClient calls require deal historymonday.com8 hours24 hoursCan reconstruct daily standup from memoryNotion24 hours72 hoursKnowledge base, non-urgent

These numbers shape your recovery prioritisation. When two things need restoring at once, you restore the app with the tighter RTO first.

Step 3: Map your recovery resources

When an incident happens, whoever is managing the recovery needs to know exactly where to go and what to use. Document this before you need it.

For each Tier 1 app, record:

• Backup tool and login URL. Where is the backup vault? What credentials are needed? (Don't store passwords in the DRP document itself, but note where they're held, e.g. "1Password vault, Ops team folder.")
• Who has restore access. Name specific people, not roles. "Head of IT" is useless if that person is the one who just left.
• Snapshot location. For ProBackup users: Home page, then "Go to..." for the relevant app. For Google Drive sync users: the backup folder structure in Drive, organised by app and project.
• Escalation contact. If the primary restore person can't be reached, who is second?
• Backup tool support contact. For ProBackup: support is available via the in-app chat and at support.probackup.io. For incidents where the volume or complexity is high, Pro and Premium plans have priority support.

This section of your DRP should be a single reference page someone can scan in under two minutes.

Step 4: Write your incident response runbook

This is the core of the DRP. A runbook is a documented, sequential procedure that anyone on the team can follow. It removes decision-making under pressure and ensures nothing important gets skipped.

The sequence for most SaaS data loss incidents follows six stages:

1. Detect

Establish that an incident has occurred. Common signals: a team member reports missing data, a ProBackup smart alert fires indicating unusual deletion activity, a weekly status email shows a spike in deletions. Document who receives alerts and who is responsible for triaging them.

2. Assess

Before acting, understand the scope. What data is affected? Which app, which workspace, which records? When did it happen (or when might it have started)? Is it still ongoing (e.g. a misfiring integration still running) or contained? Stopping an ongoing cause before restoring prevents restoring data into a still-broken state.

3. Contain

If the cause is still active, stop it. Revoke access for a compromised account. Disconnect the misbehaving integration. Pause imports that are still running. A restore is pointless if the same thing will happen again immediately.

4. Restore

Using your documented recovery resources, identify the correct snapshot date, select the affected items, and trigger the restore. For ProBackup: navigate to the vault, select the snapshot date preceding the incident, identify affected records, and use "Restore as new records" to create copies without overwriting current data. Track progress in the Restore Report. See the full step-by-step procedure in how to test your SaaS backups, which covers the same navigation path used in a real restore.

For silent corruption scenarios where the start date is unknown, work backwards through available snapshots from the most recent until you find a clean version of the affected data.

5. Verify

Don't close the incident until someone has confirmed the restored data is accurate. This should be the person who knows the data well enough to spot something wrong: the project owner, the account manager, whoever works in that workspace daily. Check field values, comments, attachments, and any related records.

6. Document

Record what happened: the timeline, cause, data affected, snapshot date used, who performed the restore, time to resolution, and whether any data was unrecoverable. This log serves three purposes: it improves your next response, it's evidence for compliance audits (SOC 2's Availability criterion and ISO 27001 Annex A.12.3 both require incident documentation), and it's the input for a post-incident review to prevent recurrence. Store it alongside your restore test log.

Step 5: Assign roles and contacts

A runbook without names is a procedure without owners. For each stage of the runbook, assign a primary and a backup person:

RolePrimaryBackupIncident detection / triage[Name][Name]Scope assessment[Name][Name]Containment (access revocation)[Name][Name]Restore execution[Name][Name]Data verification[Name][Name]Stakeholder communication[Name][Name]Incident documentation[Name][Name]

Also document your escalation path. If the primary restore person can't be reached within [30 minutes], who do they escalate to? Who has authority to make the call to involve external support or notify affected clients?

For out-of-hours incidents, include personal contact numbers or Slack handles that work when email is too slow. Data loss at 9pm doesn't wait until Monday.

Step 6: Test the plan

A disaster recovery plan you've never tested is an untested assumption. Run a tabletop exercise once a year: gather the relevant people, walk through a realistic scenario ("it's Monday morning, someone reports the HubSpot pipeline is empty"), and talk through each stage of the runbook. Who would do what? What would they need? Where would the friction be?

Tabletop exercises are low-cost and reveal gaps in the plan without the pressure of a real incident. Common things they surface: missing contact numbers, unclear ownership at the containment stage, backup access held only by someone who's since left the company.

Once a year, run a live drill: trigger an actual restore from a real snapshot, time the process end to end, and document how long each stage took. If your RTO for HubSpot is two hours and your live drill takes four, you've found the gap before it matters.

After any real incident, treat it as a drill debrief. Update the runbook based on what actually happened versus what the plan assumed.

Template: SaaS DRP one-pager

Below is a condensed template. A working DRP doesn't need to be long. It needs to be findable, current, and specific enough to act on.

[Organisation name] SaaS disaster recovery plan

Version: 1.0 | Owner: [Name, Role] | Last tested: [Date]

Covered apps: [List Tier 1 SaaS apps]

Recovery objectives:

AppRTORPO[App][e.g. 4 hours][e.g. 24 hours]

Recovery resources:

AppBackup toolRestore accessEscalation[App][e.g. ProBackup][Names][Name, contact]

Threat scenarios covered: Accidental deletion / Bad import or integration error / Compromised account / Malicious insider / Provider outage / Silent data corruption

Incident response sequence:

1. Detect: [who receives alerts, how incidents are reported]
2. Assess: [who assesses scope, what information is gathered]
3. Contain: [who revokes access or stops the cause]
4. Restore: [who performs the restore, backup tool used, procedure reference]
5. Verify: [who confirms data accuracy]
6. Document: [where the incident log is recorded]

Roles and contacts:

RolePrimaryBackupOut-of-hours contactTriage[Name][Name][Signal/mobile]Restore[Name][Name][Signal/mobile]Verification[Name][Name][Signal/mobile]Communications[Name][Name][Signal/mobile]

Related documents: [Link to backup policy] | [Link to SaaS data protection audit] | [Link to restore test log]

What to do next

Getting to this point means you've thought seriously about what recovery actually looks like: who acts, in what order, with what tools. That's the work most teams skip. The next step is making sure the backup infrastructure your runbook relies on is actually in place.

If you already have a backup policy in place, the DRP is the natural next document: same apps, same ownership, different purpose. Start with the roles and contact table and the RTO/RPO table from your audit, then build the runbook around them. If you're the one who owns both documents, see how ProBackup helps IT admins manage backup and recovery across the whole SaaS stack.

If you haven't yet set up independent automated backups, there's no point building a runbook that points to a backup vault that doesn't exist. Start a free trial of ProBackup, get your first snapshot running, then build the plan around that. Setup takes about three minutes per app. Plans start at $25/month (billed yearly) and cover 20+ platforms under a single licence.

See how other teams have used ProBackup when they've actually needed to recover on our success stories page.

‍

In short: The ten SaaS backup mistakes are: assuming the provider backs up your account data, treating the recycle bin as a backup, covering only some apps (private workspaces included), never testing restores, ignoring comments, attachments and metadata, having no retention policy, backing up to the same provider, no access controls on backup data, forgetting compliance requirements, and no monitoring between backups.

Most teams that experience a serious SaaS data loss had backups. Or thought they did. The problem usually isn't that nobody set anything up. It's that what they set up had a gap nobody noticed until something broke.

These are the ten mistakes we see most often, and the ones that are most likely to matter when you actually need to recover something.

Mistake 1: Assuming your SaaS provider backs up your data

This is where almost every other mistake starts. The assumption feels reasonable: your data is in the cloud, the provider runs the cloud, so surely they're looking after it.

They are, but not in the way you'd hope. The shared responsibility model means your SaaS provider protects the platform infrastructure. If their servers fail, they recover. What they don't protect is what happens inside your account: accidental deletions, bad imports, malicious actions by someone with access, integration errors that overwrite data silently.

Providers state this clearly in their terms of service. Most customers never read those terms until something goes wrong. Asana's terms explicitly state that users are responsible for maintaining copies of their own content. monday.com's data policy is similar. So is HubSpot's. The shared responsibility clause is in there; it's just in the kind of language nobody reads voluntarily.

The practical consequence: when data disappears from your workspace, your provider's infrastructure backup won't help you. That data was never part of what they were backing up. Support will confirm the deletion happened, sometimes tell you who did it, and wish you luck.

Mistake 2: Relying on the recycle bin as a backup

The recycle bin works just often enough to create a false sense of security. Someone deletes a task, finds it in the trash, restores it, and moves on. The next time something goes wrong, they expect the same thing to work.

Most platforms cap recycle bin retention at 30 days. Trello has no recycle bin for deleted cards at all. But the expiry window isn't even the main problem. Recycle bins don't cover bulk overwrites from bad imports, field configuration changes, automation errors, or anything modified rather than deleted. If a CSV import overwrites 300 custom field values with wrong data, nothing goes to the trash because nothing was deleted. The platform sees an update, not a deletion, and the recycle bin is blind to it.

Recycle bins are undo buttons. They handle "I just deleted this by accident." They are not data protection.

Mistake 3: Only backing up some of your apps

This one is less obvious, and more common than it sounds. A team connects their primary project management tool to a backup solution, considers it handled, and stops there. Meanwhile, three other apps containing business-critical data sit entirely unprotected.

It happens gradually. The backup gets set up when the company is small and only has a few critical tools. The SaaS stack grows. Nobody loops back. The SaaS audit that would catch this never happens.

The result: partial coverage that looks like full coverage. You have a backup, so you feel protected, but two of your five critical apps are completely exposed. The CRM that holds three years of client history. The HubSpot portal where your sales team logs every deal interaction. Neither of them in scope.

This is also where private workspaces create a specific gap. In tools like Asana, ClickUp, and Trello, backup scope is workspace-level. If the person who set up the backup doesn't have access to another team member's private workspace, that data isn't included. The backup runs, the status emails look clean, and nobody knows there's a gap until someone asks for data from a workspace that was never in scope. A team leader who kept all her client notes in a private Asana project leaves the company. Her successor asks where the project history is. The answer is: it was never backed up.

Mistake 4: Never testing your restores

Having backups you've never tested is roughly equivalent to having a fire extinguisher you've never checked is charged. It might work when you need it. It might not. You have no way to know.

The problem compounds under pressure. The worst time to figure out how a restore works is during an actual incident, when someone is standing behind you asking what's happening and the client is waiting for an update. The mechanics of navigating the vault, selecting a snapshot, choosing the right restore method, finding the restored items in your app: none of these should be learned for the first time in that moment.

Testing takes about 20 minutes and reveals things you wouldn't otherwise know: which data types can't be restored due to API limitations, how long a large restore actually takes, what the restored items look like in your app. Run one quarterly. Document the result. That log is also what SOC 2 and ISO 27001 auditors will ask for.

Mistake 5: Ignoring metadata, comments, and attachments

Teams often think of their data as the records: the tasks, items, contacts, deals. The fields that live in those records. But a lot of the operational value is in the context around them: comments where decisions were made, file attachments that document deliverables, activity logs that show who changed what and when.

Not all backup tools capture this, and not all platforms expose it through their API. This is worth checking specifically.

For example, Asana's API doesn't expose comments on subtasks, so those can't be backed up. Files attached to Asana tasks via Dropbox, Google Drive, or OneDrive links aren't captured either, only files uploaded directly. In monday.com, files uploaded directly to an item (rather than through a file column) aren't included. In Trello, Power-Ups and automation rules aren't accessible through the API at all.

There's also a character limit worth knowing: ProBackup captures the first 2,500 characters of any text field or comment. For most comments that's fine. For long project notes or detailed descriptions, content beyond that threshold isn't stored.

None of these are bugs. They're API limitations that every backup tool working with these platforms will hit. The mistake is assuming everything is captured when some of the most contextually rich data isn't.

Mistake 6: No retention policy

Daily backups with 30 days of retention sound reasonable until you face the most common real-world failure mode: the problem that nobody notices for six weeks.

A misconfigured integration silently overwrites a field across hundreds of records. A former employee deleted a project's history before leaving. Someone changed a custom field configuration and removed several options that tasks were assigned to. None of these are obvious immediately. Teams often don't notice until a client asks a question, a report looks wrong, or someone goes looking for something that should be there.

If your backup retention is shorter than your detection window, the clean snapshot you need is gone before you realise you need it.

Setting a meaningful RPO requires thinking about your worst-case detection time, not your average case. If your team might not notice a data problem for two months, you need at least two months of retention. For compliance-driven teams, the requirement is typically longer. SOC 2 and ISO 27001 both expect you to document your retention policy and justify it against your recovery objectives, not just set a default and leave it.

Retention settings also need to be protected. In most backup tools, reducing the retention period permanently deletes older snapshots. This should require explicit approval from the policy owner, not just anyone with admin access.

Mistake 7: Backing up to the same provider

This is the most technically interesting mistake, and the one most likely to cause complete, unrecoverable data loss.

The scenario: your SaaS app and your backup are both hosted by the same cloud provider, sometimes even under the same account. When the provider has an incident, both the source data and the backup go down together. When a malicious actor gains access to your account, they can reach both. Your backup isn't independent. It's just a copy stored in the same blast radius.

CodeSpaces, a code-hosting provider built on AWS, learned this in 2014. An attacker gained access to their AWS control panel and systematically deleted all EBS snapshots, S3 buckets, and machine images. CodeSpaces had backups. They were stored in the same AWS account. The company shut down permanently within 24 hours.

This pattern applies at a smaller scale every time someone uses their SaaS provider's built-in export feature as their "backup." The export lives in Google Drive, which is authenticated with the same Google account as the workspace. The workspace gets compromised; the export goes with it.

A genuine independent backup means different infrastructure, different authentication, different provider. ProBackup stores all backup data in AWS with AES-256 encryption, in one of nine AWS regions — the region is selected by the customer at signup and applies to every backup in the ProBackup account — using access tokens that are completely isolated from your SaaS accounts. Compromising your Asana or monday.com account gives an attacker no pathway to your ProBackup data.

Mistake 8: No team access controls on backup data

Who can access your backup vault? Who can trigger a restore? Who can see what data was deleted and when?

Most teams set this up for their primary admin and never think about it again. The result is that either too many people have restore access (including former employees), or too few people do (so if the primary admin is unavailable during an incident, nobody else can do anything).

Access controls on backup data deserve the same attention as access controls on the source platform. In ProBackup, the admin user has full access. Invited users can be granted per-platform permissions at three levels: view only, export, or full restore. These should be set deliberately, not left at defaults.

Offboarded employees are a specific risk. If someone with restore access leaves the company and their backup account isn't deactivated, they have access to a historical record of your organisation's data, including things deleted months before they left. That's a data exposure problem, not just a security hygiene issue. GDPR's principle of data minimisation applies here: access to personal data should be limited to those who currently need it.

Two-factor authentication on backup tool accounts is non-negotiable. It's the same lesson the Snowflake breach taught at scale: stolen credentials are common, MFA stops them from being useful.

Mistake 9: Forgetting about compliance requirements

Backup is often treated as an operational concern rather than a compliance one. That's a mistake for any organisation subject to GDPR, SOC 2, ISO 27001, or sector-specific regulations.

SOC 2's Availability trust service criterion requires demonstrable evidence that you can restore data within documented recovery objectives. An auditor will ask for your backup policy, status reports showing backups are running, and records of restore testing. "We have backups" isn't evidence. Documented procedures and test logs are.

ISO 27001 Annex A.12.3 requires documented backup procedures including scope, frequency, retention, and regular testing. The standard also requires that backup storage be "adequately protected," which means physical security, encryption, and access controls.

GDPR adds a specific wrinkle: when a data subject requests deletion under Article 17, you must delete their data from live systems. But that data may persist in backup snapshots until the retention period expires. Your backup policy should document this as a known behaviour and, if your compliance obligations require it, define a process for removing personal data from backups on request.

Teams that treat backup as pure ops and never connect it to compliance often discover the gap during an audit rather than before one.

Mistake 10: No monitoring between backups

Daily backups are a 24-hour safety net. But between backups, things happen. A disgruntled employee mass-deletes 400 tasks on a Tuesday afternoon. An integration misfires and clears a column across an entire board. Someone with admin access empties the recycle bin.

Without monitoring, none of this surfaces until the next backup cycle, by which time the window for catching it in real time has closed. If you notice on Wednesday that your Tuesday afternoon was catastrophic, you can restore from Tuesday morning's snapshot and lose a few hours of work. That's recoverable. If you notice on Friday because someone finally went looking for a task that should have been there, you're in a different situation: multiple days of legitimate work happened on top of the corrupted state, and disentangling what to restore is significantly harder.

Proactive alerts close this gap. ProBackup's smart alert system notifies you when unusual deletion activity is detected, for example a spike where far more items than normal are removed in a short window. On Pro and Premium plans, weekly status emails summarise backup health, storage usage, and recent deletion activity across all connected platforms.

Monitoring doesn't replace backups. It shortens the detection window that determines whether a restore is a quick fix or a complex, multi-day reconstruction.

Quick reference: the 10 mistakes at a glance

What to do now

If any of these mistakes apply to your current setup, the fix is usually simpler than it looks.

Run a SaaS data protection audit to find your coverage gaps. Write or update your backup policy to document scope, retention, ownership, and access controls. Run a test restore if you haven't done one recently.

If you don't yet have independent, automated backups for your SaaS stack, start a free trial of ProBackup. Setup takes about three minutes per app and covers 20+ platforms under a single licence, including Asana, monday.com, ClickUp, Trello, Notion, HubSpot, Jira, Airtable, and Slack. Plans start at $25/month (billed yearly).

See how other teams have used ProBackup to recover from real data loss on our success stories page.

In short: test a SaaS backup with a non-destructive restore drill: pick a recent snapshot, restore one item as a new record, check that fields, comments and attachments arrive intact, then delete the test copy. It takes about 20 minutes — and until you have done it, your backup is an assumption rather than a safeguard.

The worst moment to discover your backup doesn't work is when you're already in an incident. Your Asana workspace is corrupted, the client is waiting for an update, someone is standing behind you asking what's happening, and you're clicking around in a backup tool you haven't opened in six months trying to figure out what "restore as new records" means.

This happens more than it should. Not because teams don't have backups, but because they never test them. Setting up automated backups feels like the finish line. It isn't. A backup you've never tested is an assumption, not a safeguard.

Testing takes about 20 minutes. It's non-destructive. It answers the questions you don't want to be answering for the first time during a real incident: where do I find the snapshot? What do I restore? How long does it take? Where do the restored items appear? What if the data looks wrong?

This post walks you through the full process.

Why backup testing gets skipped (and why that's a problem)

The common reasons are predictable. "We have backups running, so we're covered." "We'll figure it out if it ever happens." "It would take too long."

None of these hold up. A backup that runs successfully every night doesn't guarantee the data inside it is usable. APIs have limitations. Some data types can't be restored due to platform constraints. Certain field values don't survive the restore process. You won't know any of this until you actually try restoring something.

There's also the time pressure problem. During a real incident, people are stressed, decisions need to be made quickly, and the person doing the restore is probably not the person who set up the backup tool. If nobody has ever done a restore before, the learning curve hits at exactly the wrong moment.

A quarterly test costs 20 minutes. An untested restore during a live incident can cost hours, and sometimes data you can't recover at all.

What you're actually testing

Before running a test, be clear on what you're trying to verify. A good backup test answers four questions:

Is the data there?

Can you find a clean snapshot from a recent date? Is the data you'd want to restore actually in the backup vault?

Is the data complete?

When you look at a backed-up record, are the field values, comments, files, and related items all present? It helps to know how the backup engine stores each revision before you judge a gap. Or are there gaps you'd expect to be filled?

Does the restore work end to end?

Can you trigger a restore, have it complete successfully, find the restored items in your SaaS app, and verify they match the original?

How long does it take?

‍For a single record, for a project, for a larger set of items. This is your RTO data point. If restoring 200 tasks takes 40 minutes, that's your RTO for that scenario, and you should know it now.

What to test

Don't try to test everything in one session. Pick a representative sample across the data types your team relies on most.

A useful test set for a first run:

• One task or record with comments, attachments, and custom field values (tests field-level restore fidelity)
• One project or board from a few weeks ago (tests point-in-time snapshot integrity and project-level restore)
• One recently deleted item still within the retention window (tests deleted-item recovery)
• One item deleted long enough ago that it's gone from the platform's own recycle bin; this tests the core value proposition of an independent backup (see why SaaS recycle bins aren't enough)

That last one is the most important. If your backup can recover something the platform's native recycle bin can no longer see, you know the independent backup is doing what it's supposed to.

How to run a test restore in ProBackup

The process is the same for any platform you have connected.

Step 1: Open the vault and navigate to your data.

On the Home page, click "Go to..." for the app you want to test. In the left sidepane, navigate to the workspace, folder, project, or board that contains the data you want to restore. Switch between data type tabs (tasks, comments, files, and so on) to browse what's captured.

Step 2: Select a snapshot date.

Use the date filter to select a past snapshot, the further back the better for a meaningful test. If your retention is six months, try a snapshot from two months ago. This confirms both that the snapshot exists and that the data looks as expected.

Step 3: Select the records and click "Restore..."

Select one or more records and click "Restore..." at the bottom of the screen or via the preview panel. A restore pane opens on the right. Before confirming, check two things:

Restore location: confirms where the restored items will appear. This is set automatically based on the original location.

Restore method: choose between "Restore as new records" (creates copies alongside existing data, the safest option and the right choice for testing) and "Overwrite existing records" (updates existing records with backed-up field values, useful for rolling back changes to a record that still exists). For testing, always use "Restore as new records." Nothing gets overwritten, and you can delete the test copies once you've verified them.

Also review "Restore constraints" at the bottom of the pane. This lists any data types that can't be restored due to API limitations for that platform. For example, Asana tasks can't have formula fields or read-only custom fields restored. This is important to note in your test log as a known limitation.

Step 4: Track progress and find restored items.

After confirming, go to Reports > Restore Report to follow progress. Large restores can take a few minutes. Once complete, open your SaaS app:

• Restored projects and boards appear with "restore" and the date appended to the name, for example "Q3 Campaign (restore 2026-04-15)." Find them in the relevant workspace.
• Restored tasks and records appear as new items in the original project or board. Sort by creation date to find them quickly.
• Restored comments appear as new entries in the related record.

Step 5: Verify the data.

Compare the restored items against what you'd expect. Check field values, comments, files, and any custom fields that are central to how your team uses the app. Note anything that's missing or looks wrong. Some gaps are expected (known API limitations), and some might be surprises worth investigating.

Step 6: Delete the test copies.

Once you've verified the restored data, delete the test copies to keep your workspace clean. The original data is untouched throughout this process.

What to do when a test reveals missing data

Not every restore test comes back clean. Sometimes you'll find data types that are missing or field values that didn't survive the restore. Before treating this as a backup failure, check whether it's an expected API limitation.

ProBackup's restore pane shows "Restore constraints" before you confirm a restore. These are the known limitations for that platform and data type. For Monday.com, for example, subitems, relationship fields, and mirror fields can't be restored. Button columns, lookup columns, and board-relation columns are also excluded due to API constraints. For Asana, formula fields and read-only custom fields can't be restored.

If missing data falls within these documented constraints, it's a known limitation, not a bug. Document it in your test log so it's captured as an explicit gap in your coverage, and evaluate whether a manual workaround (like a scheduled export of those specific field types) can compensate.

If missing data falls outside the documented constraints, something unexpected is happening. Check the Restore Report for any errors. If the report shows failures or partial restores that don't match the known limitations, contact ProBackup support with the restore report details.

Either way, the point of testing is to discover these things now, not during a real incident.

Keeping a test log

Every test should be documented. Not because it's bureaucratic box-ticking, but because the test log is your evidence during an audit, your reference when something goes wrong, and your record of known limitations.

For each test, record:

• Date of test
• Platform tested
• Snapshot date used
• Data types tested (tasks, comments, files, custom fields)
• Restore method used
• Time from trigger to completion
• Pass / Fail
• Notes: what matched, what was missing, whether missing data was a known API limitation or an unexpected gap

If you're using the backup policy template from our SaaS data backup policy post, Appendix A already has a restore test log table you can fill in. Use it. Auditors asking for SOC 2 or ISO 27001 evidence will want to see exactly this, and under GDPR Article 32, the ability to restore data "in a timely manner" is meaningless unless you can demonstrate you've actually tested it.

How often to test

Quarterly is the right cadence for most teams. That's frequent enough to catch configuration drift and infrequent enough that it doesn't become a burden.

Rather than testing the same app every quarter, rotate through your stack so all critical platforms get covered over the course of a year. If you've done the SaaS data protection audit and categorised your apps by tier, a simple four-quarter rotation works well:

• Q1: Your primary project management tool (Asana, Monday.com, ClickUp, or Jira). This is typically the highest-criticality app and the one most likely to surface API limitation surprises.
• Q2: Your CRM (HubSpot, Pipedrive, or similar). Focus on records with comments, associated files, and activity history, since these are the data types most likely to have restore constraints.
• Q3: Your knowledge base or collaboration tool (Notion, Confluence, Slack). Test from a snapshot that's at least two months old to verify retention depth.
• Q4: Any remaining Tier 1 apps, plus a spot-check on a Tier 2 app you haven't tested before.

By the end of the year, every critical platform has had a dedicated test, and you've built enough familiarity with the restore process that doing it under real pressure won't feel like the first time.

Test more frequently if you've recently changed something: added a new platform, changed retention settings, updated workspace permissions, or onboarded a significant number of new users. Any of these can affect backup scope in ways that aren't immediately obvious.

Also test after any real incident. If you restored data to fix an actual problem, document the experience while it's fresh: how long it took, where the friction was, what you'd do differently. That's more useful than any scheduled test because it's based on a real failure mode in your specific environment.

Beyond testing: proactive monitoring

Testing is periodic. Monitoring is continuous.

ProBackup's smart alerts notify you when unusual deletion activity is detected, for example a spike where 50 tasks disappear in an hour, or a board is deleted by someone who doesn't normally delete things. On Pro and Premium plans, you also receive weekly status emails summarising backup health, recent changes, and storage usage across all connected platforms.

These two things together (proactive alerts and weekly status reviews) help close the detection gap that makes slow-burn data loss so dangerous. If you know about a problem within hours rather than weeks, the right snapshot is much easier to find. The test confirms the backup works. The monitoring helps you catch problems early enough that the backup matters.

Proactive alerts and weekly reports are available on Pro and Premium plans.

What to do next

If you haven't run a restore test since setting up your backups, do one this week. Pick one platform, pick a snapshot from a few weeks ago, restore a small set of records, verify them, and document the result. It takes 20 minutes and tells you more about your actual data protection posture than any configuration page.

If the test surfaces gaps (known API limitations you weren't aware of, retention windows that don't cover the period you need, workspaces that fell out of scope), address them as part of your backup policy review.

If you don't yet have automated backups in place and you're still relying on the platform's native recycle bin, start a free trial of ProBackup. Setup takes three minutes per app. Your first snapshot runs within 24 hours. See how other teams use ProBackup when things actually go wrong on our success stories page.

Plans start at $25/month (billed yearly).

In short: A SaaS backup policy is a one- or two-page document stating which apps are backed up, how often (daily gives a 24-hour RPO), how long snapshots are kept (ProBackup: 6 months on Plus, 2 years on Pro, unlimited on Premium), who owns it, who can restore, and how restores are tested. A SOC 2 and ISO 27001-aligned template is included.

Your head of marketing left last month. Her private Asana workspace, three years of campaign briefs, launch timelines, and vendor contacts, wasn't included in the backup scope. Nobody knew until the new hire asked where the Q3 launch plan was. The IT admin checked the backup tool: it was only connected to the shared Engineering and Product workspaces. Marketing's data was never covered.

This is a policy problem, not a technology problem. The backup tool worked fine. It just wasn't configured to cover everything that mattered, and nobody had documented what "everything" meant.

The shared responsibility model means your SaaS provider protects the platform, not your account data. But even teams that understand this and have a backup tool in place often lack a written policy. Without one, backup decisions get made ad hoc: the ops lead sets up a manual CSV export "just in case," the IT admin connects a backup tool to two apps but forgets the third, the new hire doesn't know backups exist at all.

A SaaS backup policy fixes that. It documents what gets backed up, how often, who's responsible, and what recovery looks like. It's not a hundred-page governance document. It's a page or two that makes sure the right things happen consistently, especially when the person who originally set them up is on holiday or has moved on.

Why every organisation needs a SaaS backup policy

The obvious reason is data protection. But the practical reason is accountability.

Without a written policy, there's no clear answer to basic questions. Which SaaS apps are backed up? All of them, or just the ones someone remembered to connect? How long are backups retained? Does anyone test restores? What happens when a new app gets added to the stack?

These questions don't matter until something goes wrong. Then they matter a lot. The team that deleted a project board six weeks ago needs to know if a clean backup exists. The CFO preparing for a SOC 2 audit needs to show documented backup procedures. The departing employee's manager needs to know whether private project data was included in the backup scope.

A policy also protects against the bus factor. If your backup setup lives entirely in one person's head, it's not a system. It's a single point of failure. A written policy means anyone on the team can understand, verify, and maintain the backup process.

What a backup policy should cover

At its simplest, a backup policy answers: what gets backed up, how often, how long backups are kept, who's responsible, who can access restore functions, and how you verify it all works. That's it. The sections below walk through each of those decisions with the specific choices you need to make and document.

Defining scope: which apps, which data

Start by listing every SaaS app your organisation uses that contains business-critical data. Not just project management tools. Think about your CRM, knowledge base, helpdesk, design tools, communication platforms, and any app where losing data would cause real pain.

For each app, document what data types you're backing up. This matters because no backup tool covers everything. API limitations mean certain data types are inaccessible. Automations, dashboard configurations, and some file types typically can't be backed up in apps like Trello, ClickUp, or monday.com. Your policy should be honest about these gaps so nobody is surprised later. And don't assume the app's native recycle bin fills the gaps: most recycle bins expire after 30 days and don't cover field-level changes at all.

Your scope definition should also cover workspace selection. In tools like Asana, ClickUp, and Trello, backup scope is controlled at the workspace level. If your organisation has workspaces owned by different departments, you need to ensure each one is included. This sometimes requires inviting additional team members to authorise the backup tool so their private workspaces are covered.

Setting backup frequency and retention

These two settings define your Recovery Point Objective (RPO): the maximum amount of data you can afford to lose.

Frequency: For most SaaS apps, daily backups are the right balance between risk reduction and practicality. Real-time backup sounds better in theory, but SaaS APIs have rate limits that make continuous backup impractical at scale, and the marginal improvement in RPO rarely justifies the cost. Daily snapshots give you a 24-hour RPO, which covers the vast majority of SaaS data loss scenarios.

Retention: This is how long each snapshot is kept. Retention determines how far back you can recover. If someone corrupts data via a bad import and nobody notices for two months, you need a snapshot from before that import. Short retention (30 days) won't help. Longer retention (6 months, 2 years, or more) gives you the safety margin to handle slow-discovery problems.

Your policy should specify both the minimum backup frequency and the minimum retention period. It should also specify who can change these settings, because reducing retention in ProBackup (or any backup tool) is a destructive action that permanently deletes older snapshots. If your organisation follows the 3-2-1 backup rule (three copies, two destinations, one offsite), document that here too; one easy second destination is to keep a second copy in Google Drive.

In ProBackup, retention depends on your plan: 6 months on Plus, 2 years on Pro, and unlimited on Premium. Pro and Premium users can also configure shorter retention periods if their compliance policies require it. The right setting depends on your compliance requirements and how quickly your team typically notices data issues. You can also control storage and retention per backup rather than account-wide.

Assigning ownership and access controls

A backup policy without an owner is a document nobody reads. Name a specific person (not a team, a person) who is responsible for:

• Making sure all critical SaaS apps are connected and backing up successfully. This includes verifying that new workspaces created by other teams get added to the backup scope.
• Reviewing backup status reports weekly. ProBackup sends weekly status emails on Pro and Premium plans, but the owner needs to actually read them and act on failures.
• Responding to smart alerts when unusual deletion activity is detected. A spike in deletions could mean a disgruntled employee, a misbehaving integration, or just a big clean-up. The owner should investigate within one business day.
• Adding new SaaS apps to the backup scope when the organisation adopts them. This is the one that slips most often. Someone signs up for Notion or Airtable, the team migrates data into it, and nobody thinks to connect it to the backup tool until something goes wrong.
• Updating the policy itself when scope, frequency, or retention changes. The policy is only useful if it reflects reality.

Access controls matter too. Not everyone on the team needs the ability to restore data. In ProBackup, the admin user has full access to all backup data and billing. Invited users can be scoped per-platform with granular permissions: view only, export, or restore. Your policy should define who gets which level of access and under what circumstances.

This is also where you document the authentication setup. ProBackup supports two-factor authentication and Google SSO on all plans, with enterprise SSO (SAML) on Premium. Your policy should require 2FA for anyone with restore access, at minimum. The irony of a compromised backup account is not lost on anyone who's been through it.

Testing and audit requirements

Backups you've never tested are assumptions, not safeguards. Your policy should mandate regular restore tests and document the procedure.

A straightforward testing process: once per quarter, pick a recent backup snapshot, select a small set of records (a project, a handful of tasks, a few CRM records), restore them, and verify the result against the originals. In ProBackup, restored items are created as new copies in the original location, so this is completely non-destructive. You restore, compare, confirm the data matches, and delete the test copies.

What to do when a test fails. Sometimes the restored data won't match what you expected. A custom field might be empty. An attachment might be missing. Comments might not be included for a particular app. This doesn't necessarily mean the backup is broken. It usually means there's an API limitation you weren't aware of, a data type that can't be backed up due to platform restrictions. When this happens, document the gap in your policy's scope table (the "data types excluded" column) so it's captured as a known limitation, not a surprise during a real incident. If the missing data type is critical, evaluate whether a manual export or alternative process can cover the gap.

Document every test result. Record the date, which app and data types were tested, who performed the test, the time from trigger to completion, and whether the restored data matched expectations. This log is useful for your own confidence, but it's also exactly what an auditor will ask for during a SOC 2 or ISO 27001 assessment.

Your policy should also define how often the policy itself gets reviewed. Once a year is the minimum. Review the app inventory (has the team added new tools?), the scope (are all workspaces covered?), retention settings (do they still match your compliance needs?), and user permissions (has anyone left the company who still has backup access?).

Template: sample SaaS backup policy

Below is a starter template you can adapt. It's deliberately concise. A policy nobody reads because it's 30 pages long is worse than a one-page policy everyone follows.

[Organisation name] SaaS data backup policy

Effective date: [date]
Policy owner: [name and role]
Last reviewed: [date]

1. Purpose
This policy defines how [Organisation name] protects data stored in third-party SaaS applications from accidental loss, malicious deletion, data corruption, and compliance failures.

2. Scope
The following SaaS applications are covered under this policy:

ApplicationWorkspaces includedData types excludedBackup tool[e.g. Asana][e.g. All active workspaces][e.g. Automations, dashboard configs][e.g. ProBackup][e.g. HubSpot][Full account][e.g. Call logs, dashboards][e.g. ProBackup][e.g. Trello][e.g. Product, Engineering boards][e.g. Power-Ups, deleted cards prior to backup][e.g. ProBackup]

3. Backup frequency and retention
All applications in scope are backed up daily (every 24 hours). Backup retention is set to [e.g. 2 years]. Changes to frequency or retention settings require approval from the policy owner.

4. Access controls
Backup admin access is held by [name/role]. Restore access is granted to [names/roles]. All users with restore access must have two-factor authentication enabled. Permissions are reviewed quarterly.

5. Monitoring
The policy owner reviews weekly backup status reports and responds to automated alerts (e.g. unusual deletion activity) within [e.g. 1 business day].

6. Restore testing
A test restore is performed quarterly. The test includes selecting a previous snapshot, restoring a sample of records, verifying data accuracy, and documenting the results. Test records are summarised in the [restore test log / internal wiki / shared drive].

7. Policy review
This policy is reviewed annually, or sooner if the organisation's SaaS stack, team structure, or compliance requirements change. The review covers app inventory, backup scope, retention settings, user permissions, and testing logs.

Want a ready-to-use version? Download the complete SaaS backup policy template with pre-filled examples for common platforms, a quarterly restore test log, and a review checklist

Download the template →

Aligning your policy with SOC 2 and ISO 27001

If your organisation is pursuing or maintaining SOC 2 or ISO 27001 certification, your backup policy isn't just good practice. It's a control that auditors will specifically look for.

SOC 2 (specifically the Availability trust service criterion) requires organisations to demonstrate that they can restore data and systems to a defined state within documented recovery objectives. An auditor will want to see your backup policy, evidence that backups are running (status reports, logs), and records of restore testing. They'll also check that access controls on backup data are appropriate and that retention periods match your stated data handling commitments. ProBackup's Premium plan includes audit reports specifically designed to provide this evidence, and our Vanta integration automates continuous compliance monitoring.

ISO 27001 (Annex A.12.3) requires documented backup procedures, including what data is backed up, the backup schedule, retention periods, and regular testing. The standard also requires that backup media (in this case, the cloud infrastructure where backups are stored) be adequately protected. ProBackup stores all data in AWS with AES-256 encryption, in one of nine AWS regions — the region is selected by the customer at signup and applies to every backup in the ProBackup account. The AWS data centres themselves are ISO 27001, SOC 1 and SOC 2, and PCI DSS Level 1 certified. Full details on our infrastructure and security controls are on our data security page.

GDPR doesn't prescribe a specific backup framework, but Article 32 requires "the ability to restore the availability and access to personal data in a timely manner." If your SaaS apps contain EU personal data (they almost certainly do), your backup policy is part of your Article 32 compliance story. Your policy should also address how GDPR deletion requests interact with backups, since personal data in a backup snapshot may persist beyond a deletion in the live app.

For a deeper look at how backup infrastructure supports these frameworks, see why backups matter for SOC 2 and ISO 27001.

What to do next

You don't need to get this perfect on the first draft. Start with the template, fill in the blanks for your current SaaS stack, and share it with whoever manages IT and security at your organisation. If that person is you, see how ProBackup helps IT admins keep every app in the stack covered. A rough policy is better than no policy, and you can refine it as you learn what your actual RPO needs and compliance requirements look like.

If you don't yet have a backup tool in place, start a free trial of ProBackup. Setup takes about three minutes per app, and your first snapshot runs within 24 hours. Plans start at $25/month (billed yearly) and cover unlimited apps under a single licence. See how other teams protect their SaaS data on our success stories page. The same policy pays off when migrating between SaaS platforms.

‍

In short: Since May 2026 ProBackup's Settings > Data retention offers four storage controls: a shorter retention window (Pro and Premium), skipping attachments over 10 MB, 100 MB or 1 GB or excluding them entirely, excluding chosen file extensions, and deleting attachments older than 3 months to 2 years. A Storage Usage Report shows which projects or lists use the most space.

Today we are rolling out one of the most-requested updates to ProBackup: far more granular control over what gets backed up and how long we keep it.

Until now, retention in ProBackup meant choosing how long to keep your versions and deleted items. That works well, but storage usage is rarely just about time. It is also about what you are storing - and most accounts have a handful of files, file types, or projects that quietly consume the majority of the space.

So we built four new ways to take charge of that.

What's new

Inside Settings > Data retention, you will now find a full toolkit for tuning your storage:

1. Adjust your data retention period (improved) Your plan sets the maximum retention window: 6 months on Plus, 2 years on Pro, and unlimited on Premium. Pro and Premium users can set a shorter window that fits their compliance and recovery needs - and shortening it is still the fastest way to cut storage in one click. See the retention included in each plan.

2. Exclude files by size or skip attachments entirely Not every file needs the same protection. You can now back up all attachments, skip anything larger than 10 MB, 100 MB, or 1 GB, or exclude attachments altogether. Big media files like .mov, .mp4, .tiff, .raw, .avi, and .zip are the usual storage hogs — now you can decide whether they belong in your backup at all.

3. Exclude files by extension Filter out specific file types you do not need protected. Choose extensions like .pdf, .png, or anything else from the dropdown, and ProBackup will leave them out of future backups.

4. Exclude files by upload date Sometimes the files eating your storage are the old ones nobody touches anymore. The new Delete old attachments option shows you exactly how much space you would reclaim by clearing out active files uploaded more than 3 months, 6 months, 1 year, or 2 years ago. (For safety, this change is confirmed by emailed verification code rather than a single click.)

5. Request a Storage Usage Report and exclude your biggest projects or lists This one is a game-changer for larger accounts. Generate a report for your connected app and see exactly which projects and lists are driving your storage usage. Spot the outliers, then exclude them from your backup scope in a couple of clicks.

Why this matters

Backup storage tends to grow quietly. A few oversized attachments here, a legacy project there, file types you never actually need to restore... over months and years, that adds up. Every one of our daily snapshots adds to the pile. The result is teams paying for storage they do not strictly need, and admins with no easy way to see where it all went.

With this update, the picture becomes clear and the levers become obvious:

• See it: generate a report and find out where your storage is actually going.
• Trim it: exclude by size, type, age, or scope.
• Keep what matters: without overpaying for what does not.

For teams under tighter compliance regimes, this also means cleaner retention policies that better reflect what your business actually needs to keep. If you have not already, write a retention policy that records those choices.

Try it now

Head to Settings > Data retention in your ProBackup account to explore the new controls. If you are not sure where to start, the Storage Usage Report is a great first step — most accounts find an easy win within minutes.

Full step-by-step guide: How to control your data storage

As always, let us know what you think. Many of these options exist because customers asked for them. Keep the feedback coming!

In short: RTO (Recovery Time Objective) is how long your team can afford to be without usable data after an incident; RPO (Recovery Point Objective) is how much recent work you can afford to lose. With daily SaaS backups your RPO is at most 24 hours; your RTO depends on how fast you can find and restore the affected records.

Last Tuesday, your ops lead ran a CSV import into monday.com. It was supposed to update project statuses. Instead, it overwrote 300 custom field values across six boards. Nobody noticed until Friday. By then, three days of real work had been layered on top of the corrupted data, and monday.com's recycle bin had nothing to offer because nothing was deleted. The data was just wrong.

Two questions determine how badly this hurts: how long until the data is usable again, and how much work did you lose? In disaster recovery, those questions have names. The first is your Recovery Time Objective (RTO). The second is your Recovery Point Objective (RPO). Together, they define what "acceptable" looks like when things go wrong, and they should be shaping your backup strategy right now, before you need them.

What is RTO?

Recovery Time Objective is the maximum amount of time your team can tolerate being without access to usable data after an incident. Not how fast your backup tool runs. How long your business can function without the data.

An RTO of zero means you need instant failover, no downtime at all. That's what banks and hospitals aim for. An RTO of 24 hours means you can survive a full working day without the affected system. An RTO of one week means the data is important but not operationally critical on a daily basis.

For most SaaS-dependent teams, the honest answer is somewhere between a few hours and one business day. If your project management tool's data is corrupted or your CRM records are gone, you can probably limp through the morning. But by afternoon, people are blocked: they can't see task assignments, client history, deal stages, or project timelines.

What people get wrong about RTO is assuming it only applies to total outages. It doesn't. The monday.com import scenario above isn't an outage. The platform works fine. But your team is locked out of accurate data until someone fixes it, and that's an RTO scenario just the same.

Your RTO isn't just an abstract number. It determines what kind of restore process you need. If your RTO is four hours, you need a backup solution where you can identify affected records, select a clean snapshot, and restore them within that window. If your RTO is "whenever we get around to it," you don't have an RTO. You have a hope.

What is RPO?

Recovery Point Objective is the maximum amount of data loss your organisation can tolerate, measured in time. It answers the question: if we had to restore from a backup right now, how far back is acceptable?

An RPO of zero means you can't lose any data at all. Every transaction, every field update, every comment needs to be captured in real time. An RPO of 24 hours means you can accept losing up to one day's worth of changes. An RPO of one week means losing a week of work is tolerable if it comes to that.

RPO is the metric that most directly determines your backup frequency. If your RPO is 24 hours, you need daily backups at minimum. If it's one hour, you need near-real-time replication. If it's a week, weekly backups might work, though you'd want a strong reason for accepting that level of risk.

Back to the monday.com scenario. If you had a daily backup and noticed the problem on the same day, your RPO of 24 hours means you restore from last night's snapshot and lose, at most, a few hours of work done before the import. Annoying, but manageable. But the problem wasn't noticed until Friday. Now your RPO is fine (you have yesterday's snapshot), but the right snapshot to restore from is Tuesday's, before the import ran. Whether that snapshot still exists depends on your retention period. RPO tells you the maximum gap between backups. Retention tells you how far back those backups go. You need both.

Why RTO and RPO matter for SaaS apps

In traditional IT, RTO and RPO planning is standard practice. You have servers, backup schedules, and someone on the infrastructure team has documented recovery procedures and tested them.

With SaaS apps, most of that planning disappears. The provider handles infrastructure, and teams assume that means recovery is handled too. It isn't. The shared responsibility model means your provider recovers from their infrastructure failures. Account-level data loss, deletions, overwrites, corruption from integrations, is yours to deal with.

Without defined RTO and RPO objectives, teams default to whatever their SaaS app's native recovery offers. And those native features have hard limits. Recycle bins expire after 30 days on most platforms. Trello has no recycle bin for deleted cards. None of them protect against field-level overwrites or bulk import errors, which are among the most common data loss scenarios.

The practical consequence: when data loss happens without a backup, your actual RTO becomes "however long it takes someone to manually reconstruct the data." We've seen teams spend an entire week rebuilding a project board from screenshots and Slack messages. Your actual RPO, meanwhile, becomes "whenever someone last happened to export a spreadsheet." That's not a strategy. That's luck.

How to calculate your RTO and RPO

You don't need a consultant for this. You need honest answers to a few questions, applied to each SaaS app your team depends on.

For RTO, ask: If this app's data became unusable right now, how long before it affects revenue, client commitments, or team output? Be specific. "We'd lose some productivity" is not an RTO. "The sales team couldn't update pipeline for a full day, which means the Monday forecast review is based on stale data and we might miss a renewal" is an RTO of roughly one business day.

Then ask: can our recovery process actually meet that window? If your RTO is four hours but your only recovery option is manually rebuilding from memory, you've already exceeded it. If you have a backup tool, time the process: how long to find the right snapshot, select the affected records, trigger the restore, and verify the result? That's your real RTO.

For RPO, ask: If we had to restore from a backup, how much lost work could we absorb? Think about what changes daily. A CRM where reps log 50 calls and update 30 deal stages per day has very different RPO needs than a knowledge base that gets edited twice a week.

Walk through your critical apps one by one. Your CRM probably has a tighter RPO than your design tool. Your project management platform sits somewhere in the middle. Not everything needs the same recovery objectives, and acknowledging that is part of the exercise.

What happens when you exceed your RPO

Your RPO is exceeded when the data loss stretches further back than your most recent usable backup can cover.

The most common way this happens isn't dramatic. Someone modifies a batch of records via import, or a third-party integration quietly overwrites field values over several days. Nobody notices for three weeks. The recycle bin expired two weeks ago, and if your backup retention is shorter than the detection window, the clean version is gone from your backups too.

The result is manual reconstruction. Someone pieces together what the data should look like from memory, client emails, exported spreadsheets, screenshots in Slack threads. It's slow, error-prone, and deeply demoralising for the team doing it.

This is also where compliance risk lives. If your RPO was 24 hours on paper but the actual loss was three weeks of data, that's a control failure. The major frameworks all have something to say about this:

• SOC 2 (Availability trust principle) requires organisations to demonstrate they can restore data within documented recovery objectives.
• ISO 27001 (Annex A.12.3) requires documented backup procedures with regular testing.
• GDPR (Article 32) requires "the ability to restore the availability and access to personal data in a timely manner." It doesn't mandate a specific RPO, but failing to meet your own documented objectives is a problem.

An auditor seeing a three-week gap against a 24-hour RPO will flag that as a control failure. For more on how backups support these frameworks, see our post on why backups matter for SOC 2 and ISO 27001.

Two things determine whether you'll exceed your RPO: backup frequency (how often snapshots are taken) and retention period (how long those snapshots are kept). Frequent backups with short retention won't help if the problem isn't discovered for months. Infrequent backups with long retention leave too large a gap between the incident and the last clean snapshot.

Daily backups vs real-time: what makes sense

If shorter RPO is better, why not back up everything in real time?

For databases and financial systems, real-time replication makes sense. The data changes constantly, every transaction matters, and losing even a few minutes is costly.

For SaaS productivity and CRM tools, the calculus is different. Real-time backup sounds ideal, but it runs into practical limits:

• API rate limits. SaaS platforms restrict how many requests you can make per minute. A single Asana workspace with 10,000 tasks requires thousands of API calls to fully capture. Running that every few minutes would exhaust your rate limit and could affect your team's normal use of the platform.
• Cost. Real-time or near-real-time SaaS backup solutions exist, but they're significantly more expensive and designed for enterprise environments with specific regulatory needs. For most teams, the additional cost doesn't match the marginal RPO improvement.
• Diminishing returns. Most SaaS data doesn't change by the second. It changes by the day. A project board updated 20 times across a workday looks functionally the same whether you snapshot it hourly or nightly.

The more useful question is: does a 24-hour RPO actually cover your risk?

For the vast majority of SaaS use cases, it does. Most data loss is either immediate and obvious (someone deletes a board, the team notices within hours) or slow and silent (a bad integration corrupts data over days or weeks). For the first category, a 24-hour-old snapshot means you lose at most one day of work. For the second category, what matters is retention depth, not backup frequency. Backing up every hour won't help if nobody notices the corruption for a month. What helps is having a clean snapshot from before it started.

That's a retention question, not a frequency question.

How ProBackup's daily snapshots fit your RPO

ProBackup runs a complete snapshot of your connected SaaS apps every 24 hours, giving you an effective RPO of 24 hours.

Every evening (based on your local time), our backup engine captures the current state of your workspace: tasks, records, cards, comments, files, custom field values, and field configurations. Each snapshot is stored as a separate version, encrypted with AES-256, in one of nine AWS regions, selected by you at signup. The region is set per ProBackup account and applies to every backup in it; afterwards, support can move them all to a different region on request. The backups are incremental (we only process what changed since the last cycle) but the result is a complete, point-in-time picture of your data for every day within your retention window.

Retention depends on your plan: 6 months on Plus, 2 years on Pro, and unlimited on Premium. Pro and Premium users can also configure shorter retention periods if their compliance policies require it. That depth matters because it determines how far back you can reach when a problem isn't caught quickly.

When something goes wrong, the restore process is designed to keep your RTO short. You pick a date in the ProBackup vault, browse or search for the affected items, select what you need, and click restore. ProBackup creates a new copy in the original location, so nothing in your current workspace gets overwritten. Restoring a single task, including its comments and attachments, takes a few clicks. Restoring an entire board creates a new copy with "restore" and the date appended to the name. You can track progress in the Restore Report page, and large restores typically complete within a few minutes.

For the monday.com scenario from the intro: you'd open ProBackup, navigate to the affected boards, select Tuesday's snapshot (before the bad import), identify the 300 records with corrupted custom field values, and restore them. The original corrupted records stay in place, and the clean copies appear alongside them for you to verify and reconcile. Total time from "we have a problem" to "we have clean data back": probably under 30 minutes, depending on the volume.

On the Pro and Premium plans, proactive alerts notify you when unusual deletion activity is detected, which helps close the detection gap that makes slow-burn data loss so dangerous. If 50 tasks disappear in an hour, you'll know before the recycle bin even becomes relevant.

We support 20+ platforms under a single licence, including Asana, monday.com, ClickUp, Trello, Notion, HubSpot, Jira, Airtable, and Slack. Plans start at $25/month (billed yearly). See how teams have used ProBackup to recover from real data loss on our success stories page.

If you want to map your RTO and RPO across your full SaaS stack, the ultimate backup and recovery guide walks through the full strategy. Or just start a free trial and have your first snapshot within 24 hours.

In short: Under the shared responsibility model your SaaS provider secures the platform (uptime, infrastructure, encryption) while you are responsible for your account data: access, MFA, and recovery from deletions, bad imports and integration errors. Native recycle bins cap at 30 days on Asana and monday.com and miss overwritten fields. CodeSpaces (2014) and the Snowflake breaches (2024) show what ignoring this costs.

Most teams assume their SaaS provider has their back when something goes wrong. Deleted board? Corrupted import? Surely there's a way to get it all back.

There isn't. Or at least, not in the way you'd expect.

SaaS providers operate under what's called the shared responsibility model. The short version: they keep the platform running, and you keep your data safe. If your Asana workspace gets wiped because someone ran a bad CSV import at 4pm on a Friday, that's on you. The provider will shrug, point to their terms of service, and wish you luck.

This misunderstanding is remarkably common. Teams discover it after a data loss incident and say some version of "I thought Asana/monday.com/Trello handled that." They didn't. And the terms of service said so all along.

This post explains where the model came from, how it works in practice, and what you can do about it.

What is the shared responsibility model?

The concept started in cloud infrastructure. When AWS popularised it in the early 2010s, the split was relatively intuitive: AWS secures the physical servers, the network, and the hypervisor. You secure everything you put on top, including your operating system, your application code, and your data.

It made sense because IaaS customers were already used to managing servers. They understood that renting compute power didn't mean outsourcing security.

The model has since been adopted by virtually every cloud and SaaS provider. Sometimes it's spelled out explicitly. Sometimes it's buried in legal fine print you'd need a lawyer to find. Microsoft, Google, Salesforce, Atlassian: they all describe some version of it in their documentation. The language varies, but the principle is the same. The provider is responsible for the platform. You are responsible for what you do with it.

How it applies to SaaS apps

Here's where things get tricky. With IaaS, the division of labour is fairly obvious. You're managing virtual machines and storage buckets. You know you're in charge.

With SaaS, the abstraction is much higher. You don't see the infrastructure. You log in, create boards, assign tasks, upload files, and everything just works. It feels like the provider is handling everything, including protecting your data.

They're not.

What SaaS providers typically handle is platform-level resilience: replication across data centres, disaster recovery for their own infrastructure, uptime SLAs. If their servers go down, they'll recover. If you delete a project, or a rogue integration overwrites 500 records, or a former employee nukes your workspace on their way out? That's your problem. The same line runs through the project management apps teams rely on every day.

Most SaaS apps offer some recovery features. Trash folders, undo buttons, version history. But these have limits. Asana's recycle bin keeps deleted items for 30 days. Trello's undo is even more limited. monday.com's Recycle Bin also caps at 30 days. And none of these features protect against the scenarios where you really need them: bulk data corruption from a bad integration, malicious deletion by a compromised account, or silent data loss you don't notice until weeks later when the recycle bin has already emptied itself.

What SaaS providers are (and aren't) responsible for

Let's be specific. Most B2B SaaS apps invest heavily in platform security: encryption at rest and in transit, SOC 2 compliance, regular penetration testing. That's real, and it matters.

But there's a gap between "platform security" and "your data is protected" that catches a lot of teams off guard, which is exactly why vendor backups are not your backup.

What the provider typically covers: infrastructure uptime and disaster recovery, physical security of data centres, encryption of data at rest and in transit, platform-level vulnerability patching, and providing authentication systems (though whether you actually configure MFA is on you).

What you're responsible for: who has access to your account and what permissions they have, whether MFA is enabled for all users, recovering from accidental or malicious deletions within your workspace, protecting against data corruption from integrations and imports, maintaining independent backups of your account data, and meeting your own compliance obligations around GDPR data retention, audit trails, and similar regulatory requirements.

The most common causes of SaaS data loss, human error, malicious insiders, and faulty integrations, all fall squarely on the customer side of the line. That's an uncomfortable thing to sit with if you've been assuming your provider had it covered.

When the model fails: real-world incidents

The shared responsibility model works fine when both sides hold up their end. The problem is that many organisations don't realise they have a side until something breaks. Even a provider-side outage lands on your side of the line: here is how one customer kept working through the AWS outage.

CodeSpaces (2014)

CodeSpaces was a code-hosting provider built on AWS. In June 2014, an attacker gained access to their AWS EC2 control panel during a DDoS attack. When extortion negotiations broke down, the attacker systematically deleted all EBS snapshots, S3 buckets, and machine images over a 12-hour window.

The company had backups. But they were stored in the same AWS account the attacker had compromised. Every redundancy layer they'd built was inside the blast radius.

CodeSpaces shut down permanently within 24 hours. Their website had previously advertised "full redundancy" and a "proven" recovery plan. It didn't help that AWS had offered MFA and IAM best practices that CodeSpaces apparently hadn't implemented. A textbook shared responsibility failure: the provider offered the tools, the customer didn't use them, and when things went wrong, there was nothing to fall back on.

Snowflake customer breaches (2024)

This one deserves a closer look, because it's the clearest recent example of what happens when the shared responsibility model meets reality at scale.

In mid-2024, attackers used stolen credentials, harvested from infostealer malware on employee machines, to access Snowflake customer environments. The credentials worked because the affected accounts hadn't enabled multi-factor authentication. Snowflake's platform itself wasn't breached. The attackers just logged in with valid usernames and passwords.

The scale was staggering. Over 160 organisations were targeted. Confirmed victims included AT&T (call metadata for nearly all US customers compromised), Ticketmaster, Santander Bank, Lending Tree, and Neiman Marcus. The personal data of over 500 million individuals was exposed. AT&T reportedly paid $370,000 in ransom.

Snowflake's response was firm and consistent: this wasn't a platform vulnerability. Customers were responsible for enabling MFA and managing their own access controls. And technically, Snowflake was right. Their shared responsibility documentation made it clear that customers manage their own credentials.

But "technically right" doesn't undo a breach affecting hundreds of millions of people.

Here's what we keep coming back to about the Snowflake incident. Snowflake didn't require MFA. They offered it as an option and left enforcement to each customer. Many customers assumed their cloud data warehouse provider was handling that sort of thing. The result was a grey zone between what the provider offered and what the customer configured. Attackers walked straight through it.

Snowflake has since made MFA mandatory for new accounts. But the damage was already done, financially and reputationally. There's now consolidated litigation in US federal court involving Snowflake, AT&T, Ticketmaster, and several other defendants.

The lesson isn't necessarily that Snowflake did something wrong (though you could argue they should have enforced MFA sooner). The lesson is that the model creates gaps. And those gaps are easy to miss when the provider's platform feels secure enough that you stop thinking about your own obligations.

How to protect your side

Knowing the model exists is step one. Acting on it is harder, mostly because it requires admitting that your SaaS provider, however good, is not your backup plan.

1. Audit what your SaaS apps actually retain, and for how long

Log into each platform your team relies on and check the data retention policy. Look for recycle bin time limits, version history depth, and what happens when you downgrade or cancel your plan. You'll probably find the recovery window is shorter than you assumed. This is especially true for project management tools where native archiving and undo features have significant gaps.

If you're subject to GDPR, SOC 2, or similar regulations, also check whether your provider's native retention meets your compliance obligations. Often it doesn't, and that gap becomes your problem.

2. Enforce MFA everywhere

The Snowflake breach happened because accounts lacked MFA. That's it. Stolen passwords are common. MFA stops them from being useful. If your SaaS app offers it, turn it on. If it doesn't, that should factor into your vendor evaluation.

3. Review permissions quarterly

Who has admin access? Who left the company three months ago but still has an active account? Who has write access but only needs read? Malicious or careless insiders are one of the most common causes of data loss, and access reviews are the simplest way to reduce that risk.

This isn't glamorous work. But it closes one of the most exploitable gaps in the shared responsibility model.

4. Set up independent, automated backups

This is the one we obviously care about most, but also the one that matters most practically.

If your SaaS provider's recovery features are your only safety net, you don't really have a safety net. You need backups stored independently from the source platform, with their own authentication and retention policies. That way, a compromised SaaS account can't take your backup data with it. This is exactly what CodeSpaces lacked: their backups lived in the same environment as the data they were supposed to protect.

This is exactly what ProBackup does. We run daily automated snapshots of your SaaS data across 20+ apps, including Asana, Trello, monday.com, ClickUp, HubSpot, Jira, and Notion. Everything is stored in our own encrypted AWS infrastructure, in one of nine AWS regions — you select the region at signup and it applies to every backup in your ProBackup account — using AES-256 encryption with separate credentials that are completely isolated from your SaaS accounts. If something goes wrong in any of your connected apps, you can restore individual records, comments, files, or entire projects from any previous snapshot.

Plans start at $25/month (billed yearly) and include unlimited apps. See how other teams use ProBackup to recover from data loss on our success stories page.

5. Test your restores

Having backups you've never tested is barely better than having no backups at all. Pick a date from last month. Try restoring a project or a set of records from that snapshot. If it works, you're covered. If it doesn't, better to find out now than during an actual incident.

What to do next

The shared responsibility model isn't going away. It's a reasonable division of labour, and honestly, it makes sense. Providers can't anticipate every way their customers might misconfigure access or accidentally destroy data. The model just requires both sides to understand what they own.

Most data loss doesn't come from dramatic infrastructure failures. It comes from someone on your team making a mistake, an integration misfiring, or a compromised credential that nobody noticed. Those are your problems to solve.

Audit your retention policies. Enforce MFA. Clean up permissions. Back up your data independently. Test your restores.

If you want to see what automated SaaS backups look like in practice, start a free trial. Setup takes about three minutes, and you'll have your first snapshot within 24 hours.

In short: Airtable has two trash levels: deleted records, fields, tables and views stay in base trash for 7 days; deleted bases and workspaces stay in workspace trash for 30 days (up to 180 on Enterprise). Snapshots restore a whole base as a new copy, never individual records, with history from 2 weeks (Free) to 3 years (Enterprise Scale).

Why this guide matters for Airtable users

Airtable is mission-critical for teams managing operations, projects, client work, and business data. But here's the reality: a surprising number of teams experience data loss from accidental deletion, human error, or system issues.

This comprehensive guide shows you:

✓ How to safely delete and restore data in Airtable

✓ What Airtable's native recovery can and CAN'T do

✓ How to prevent permanent data loss

✓ A complete backup strategy for business continuity

Who this guide is for:

• IT Administrators managing Airtable for their company
• Operations Managers protecting business-critical data
• Project Managers responsible for team workflows
• Compliance Officers ensuring data retention requirements

‍👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

Understanding Airtable's data structure

The hierarchy of Airtable data

Before you delete anything, understand how Airtable organizes data. Deletion flows downward: removing a high-level container removes everything inside it.

Airtable Data Hierarchy:

Workspace
└── Base
   ├── Table
   │   ├── Records (rows)
   │   ├── Fields (columns)
   │   ├── Record comments
   │   └── Attachments
   ├── Views
   ├── Interfaces
   ├── Automations
   └── Extensions

Important: Deleting a Workspace or Base removes:

❌ All bases, tables, and records inside it

❌ All comments and communication history

❌ All file attachments

❌ All views, interfaces, automations, and extensions

❌ All custom field data and record history

How to delete data in Airtable

Best practice: Archive vs. Delete

🟢 Archive / Hide: Recommended 99% of the time

• Removes item from active view without deleting data
• Preserves all data and history
• Can be restored at any time
• No permanent consequences

🔴 Delete: Use with extreme caution

• Moves to Trash with a limited retention window
• Permanently erased after retention period expires
• Cannot be undone once trash is emptied

How to delete records

1. Select the record(s) you want to delete in any table view
2. Right-click and select Delete record, or press the Delete/Backspace key after selecting
3. Confirm the deletion in the popup
4. The record moves to the base trash: recoverable for 7 days

How to delete a field (column)

1. Click the dropdown arrow on the field header
2. Select Delete field
3. Confirm the action
4. Field goes to base trash, recoverable for 7 days

How to delete a table

1. Right-click the table tab at the top of the base
2. Select Delete table
3. Confirm the deletion
4. Table goes to base trash, recoverable for 7 days

How to delete a base

1. From the Airtable home screen, right-click the base card
2. Select Delete base
3. Confirm the action
4. Base moves to workspace trash: recoverable for 30 days (up to 180 days on Enterprise)

How to delete a workspace

1. From the Airtable home screen, click the workspace name
2. Open workspace settings
3. Scroll to the danger zone and select Delete workspace
4. Confirm the deletion
5. Workspace moves to trash: recoverable for 30 days

How to restore data in Airtable

Airtable has two levels of trash: base-level trash (tables, fields, records, 7-day window) and workspace-level trash (bases and workspaces, 30-day window).

How to restore deleted records, fields, or tables (base trash)

1. Open the base where data was deleted
2. Click the base history icon (next to "Share" in the top-right corner)
3. Click Trash
4. Find the item you want to recover
5. Click Restore next to it

How to restore a deleted base or workspace (workspace trash)

1. Go to your Airtable home screen
2. Click your profile icon in the top-right corner
3. Select Trash
4. Find the deleted base or workspace
5. Click Restore

Trash retention limits by data type

Airtable snapshots: your safety net for base-level recovery

Airtable automatically takes snapshots of your bases based on activity and also lets you take manual snapshots. A snapshot captures everything in a base: tables, records, views, interfaces, automations, and extensions.

Snapshot retention by plan

How to take a manual snapshot

1. Open the base you want to snapshot
2. Click the base history icon in the upper-right corner
3. Click Snapshots, then Take a snapshot

How to restore from a snapshot

1. Open the base you want to restore
2. Click the base history icon in the upper-right corner
3. Select your preferred snapshot
4. Name the restored base and click Create

⚠️ Important: Restoring a snapshot creates a new base. It does not overwrite your existing one. Your original base is unaffected. The new base will have a new base ID, though record, view, table, and interface IDs are preserved. Restored bases will not have revision history but will include record comments.

What snapshots can and can't do

What can't be restored natively in Airtable

Airtable's trash and snapshot features are helpful for immediate mistakes, but they have critical limitations that can lead to permanent data loss.

A. Short trash windows at the record/field level

Base trash only retains deleted records, fields, and tables for 7 days. For workspace-level items (bases), the window is 30 days, or as few as 14 days if the base was sitting in a Free plan workspace at the time. Once the window closes, the data is gone.

B. No version history for individual cell edits

Airtable does not offer rollback for bulk data changes. You can review what changed in a record's revision history, but you cannot one-click revert a field to how it looked yesterday across thousands of records.

Common causes of silent data corruption:

• ✗ A broken automation overwrites field values across all records
• ✗ A third-party integration syncs incorrectly and bulk-updates statuses
• ✗ An API script runs against the wrong base
• ✗ A bulk import pastes incorrect data over existing content

C. Snapshots can't restore granular items

Restoring a snapshot brings back the whole base as a new copy, there's no way to extract a single record or table from a snapshot without manually copying it over.

D. What Airtable support can and cannot do

Common data loss scenarios & solutions

Scenario 1: "I accidentally deleted a base with months of client work"

What happened: A team member deleted an active client base instead of archiving it. They noticed 3 weeks later.

Native solution:

‍✓ Go to workspace trash (profile icon → Trash)

✓ Find the base and click Restore

✓ All tables, records, and history come back

Time to fix: 5 minutes: if within 30 days

If it happened 31+ days ago:

‍✗ Data is permanently gone

✗ Must reconstruct from emails, exports, or memory

Scenario 2: "Someone deleted a table inside an active base"

What happened: A collaborator deleted a table thinking it was a duplicate. The team noticed 10 days later.

Native solution:

‍✗ Base trash only retains deleted tables for 7 days

‍✗ After 7 days, table and all its records are permanently gone

✗ Airtable support cannot recover it

Scenario 3: "Our automation overwrote all our records"

What happened: An Airtable automation had a logic error and set the "Status" field on 500 records to the wrong value. The records exist, the data inside them is just wrong.

Native solution:

‍✗ Records weren't deleted, so trash doesn't help

✗ No version rollback for bulk field changes

✗ Must manually correct each record or re-import from a CSV

Time to fix: Hours

Scenario 4: "We need to prove what a client approved 6 months ago"

What happened: A client disputes the original project scope. You need to show what the Airtable base looked like when sign-off happened.

Native solution:

‍✗ Snapshots exist, but only for up to 3 years on Enterprise (2 weeks on Free)

✗ No way to view "what the base looked like on a specific date" in the UI without restoring a full copy

✗ Restored snapshot creates a new base - not directly shareable as a point-in-time audit trail

Scenario 5: "A departing employee deleted all their bases before leaving"

What happened: An admin-level employee deleted 5 bases and emptied the workspace trash before their last day.

Native solution:

‍✗ If trash was manually emptied, data is immediately gone. The 30-day window doesn't apply

✗ Airtable support cannot recover from an emptied trash

✗ No audit trail to confirm what existed before

Quick reference: "I lost data: what should I do?"

Why Airtable's native tools aren't enough for professional teams

Native Airtable recovery is a safety net for immediate mistakes, not a disaster recovery plan. Here's how it stacks up:

Compliance & data retention

Data retention requirements by industry

GDPR compliance: the "right to be forgotten"

When an EU citizen requests deletion of their personal data, you must delete it from both production systems and backups, and document it within 30 days.

How this works with Airtable + ProBackup:

Step 1: Delete user data from Airtable: remove the person from your workspace, delete their records, and purge personal data from custom fields.

Step 2: Request deletion from ProBackup: open a support ticket specifying the user and date range. ProBackup purges that data from backup storage.

Step 3: Export a deletion certificate from ProBackup for your GDPR compliance documentation.

👉 Read our full GDPR guide: Handling GDPR Deletion Requests in Your Backup System

SOC 2 & ISO 27001: what auditors look for

Protect your Airtable tables today

Don't wait for a data loss disaster to implement backup. The most common causes (accidental deletion, automation errors, and integration mishaps) can strike any team at any time.

ProBackup for Airtable gives you:

✓ Automated daily backups of all your Airtable data

✓ Unlimited retention on the Premium plan (no expiring windows)

✓ Point-in-time recovery (restore from any date)

✓ Granular restore (one record, one table, or everything)

✓ Google Drive sync on Pro and Premium plans (you own your data)

✓ SOC 2 Type II certified (enterprise-ready)

✓ 3-minute setup (no technical knowledge needed)

Evaluating backup tools? See how ProBackup compares to On2Air for Airtable.

‍👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

In short: Since March 2026 ProBackup offers two restore methods: 'Restore as new records' (the default; creates a fresh copy without touching live data) and 'Overwrite existing records', which updates a live record with values from any backup date, limited to the fields you tick. Per-data-type constraints, such as Asana formula and read-only custom fields, are shown in the restore pane.

We've just shipped a significant upgrade to ProBackup's restore experience. and if you've ever needed to roll back changes to a record that's still live in your app, this one's for you.

What's new

Until now, ProBackup always restored data as new records. That's still the safest and most common approach, but it isn't always what you need. Sometimes a record wasn't deleted; it was changed. Someone updated the wrong fields, an automation went sideways, or an AI agent touched things it shouldn't have. The record still exists, but the data inside it is wrong.

Starting today, you can restore directly into existing records, overwriting only the specific fields you choose.

How it works

When you select a record and click "Restore...", a restore pane opens on the right. You'll now see a Restore method option with two choices:

• Restore as new records (recommended): The existing behaviour. Creates a fresh copy of the record in its original location without touching anything currently in your app.
• Overwrite existing records: Updates the live record with values from a previous backup. When you select this option, a field picker appears so you can choose exactly which fields to overwrite. Everything else stays untouched.

You can also adjust the snapshot date directly in the pane using the date picker, so you're not limited to the most recent backup, you can restore the record as it looked on any date ProBackup has captured.

At the bottom of the pane, ProBackup surfaces any restore constraints for the data type you're working with. For example, formula fields and read-only custom fields can't be restored for Asana tasks. These are shown upfront so there are no surprises.

Both methods run on the same granular restore engine, down to a single record or field.

When to use each method

The same two choices apply on every platform we support, including when you back up HubSpot.

Why this matters

As teams adopt more automation and AI-driven workflows, the risk of bulk, unintended changes to live records has grown significantly. An agent that updates the wrong fields across a hundred tasks, or an automation that fires at the wrong time — these are exactly the scenarios where surgical field-level recovery makes the difference between a five-minute fix and a painful manual cleanup.

Overwrite restore gives you that precision, and makes it practical to undo unwanted AI-agent edits.

ProBackup: built for the complexity of SaaS data

Backup is only as valuable as the restore capabilities behind it. Field-level overwrite restore is part of our broader commitment to building the most capable, granular recovery tooling available for SaaS platforms - going well beyond the basic export-and-reimport approaches that most solutions still rely on.

Whether you need to recover a deleted record, roll back a handful of fields, or undo the aftermath of a runaway automation, ProBackup gives you the control to respond precisely and confidently. That's what best-in-class cloud backup for SaaS looks like in practice.

Getting started

The new restore experience is available now for all ProBackup users. For a full walkthrough of the restore flow, see How to recover deleted data in our Help Center.

Before you need it in anger, it is worth taking the time to run a test restore first.

As always, if you run into anything or have feedback, we'd love to hear from you.

In short: A backup is a second copy of your data, so it falls under the same transfer rules as the original. ProBackup stores every snapshot on AWS S3 in one of nine AWS regions. You pick the region when you create your account, it applies to every app you back up, and support can move the account later.

Why the location of a backup copy matters

When your team evaluates a backup tool for Asana, HubSpot, monday.com, ClickUp or any other cloud app, the first question from legal is usually not "how fast can we restore?" but "where does the copy live?". There are three reasons the question is legitimate.

1. GDPR treats a backup as a transfer like any other

Chapter V of the GDPR governs transfers of personal data outside the EU/EEA. Article 44 sets the general principle: any transfer of personal data to a third country "shall take place only if ... the conditions laid down in this Chapter are complied with by the controller and processor" (Art. 44 GDPR, checked 2026-09-16). Nothing in the text exempts copies made for backup purposes. If your CRM contacts are personal data in HubSpot, they are still personal data in the snapshot.

A transfer is lawful when the destination country has an adequacy decision (Art. 45, checked 2026-09-16) or when appropriate safeguards are in place, such as binding corporate rules or standard data protection clauses adopted by the Commission (Art. 46, checked 2026-09-16). The European Data Protection Board's guide for small businesses walks through the same three routes: adequacy decision, appropriate safeguards, and, as a last resort, derogations (EDPB, International data transfers, checked 2026-09-16).

Every one of those mechanisms is paperwork you have to produce and defend. Keeping the backup in the same jurisdiction as the source data removes the transfer question for that copy entirely. That is why a compliance team asks about location before it asks about features.

2. NIS2 makes backup management a named security measure

For organisations in scope of the NIS2 Directive, Article 21 lists the minimum cybersecurity risk-management measures. Point 2(c) names "business continuity, such as backup management and disaster recovery, and crisis management" (Directive (EU) 2022/2555, Art. 21, checked 2026-09-16). The directive is in force at EU level; how and when it is transposed into national law varies by member state, so check your country's status before quoting a deadline.

A backup you cannot place, describe or audit is a weak answer to "show us your backup management". A backup with a known region, a known encryption standard and an audited provider is a strong one. See our post on NIS2 backup requirements for the full picture.

3. Customers and regulators ask, and "we don't know" is not an answer

Beyond the EU, sector regulators, public-sector procurement teams and enterprise customers routinely require data, including backups, to remain within a given jurisdiction. The specifics differ by country and industry, and this post is not legal advice. The practical point is the same everywhere: you need to be able to state where the copy is, in one sentence, with a source.

How ProBackup's data region works

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account. Each snapshot is stored as JSON plus attachments on AWS S3, encrypted with AES-256 at rest and TLS in transit.

The region rules are deliberately simple:

• Nine AWS regions. When you create your ProBackup account you choose one of nine AWS data regions. ProBackup pre-selects the closest one; you can pick any other from the list.
• One region per account. The region applies to every backup in the account. If you back up Asana, HubSpot and monday.com under the same ProBackup account, all three live in the same region. One app cannot sit in a different region from another.
• Changing region goes through support. Once backups are running, the region cannot be changed from the interface. Contact support and we move all of the account's backups to the new region. It is not locked forever; it is just not a self-service toggle, because moving live snapshot history is an operation we want to supervise.
• Same price on every plan. Region choice is available on Plus, Pro and Premium at no extra cost. Plans start at $25 per month, billed yearly (see pricing).

ProBackup acts as a data processor for your account data; you remain the controller, and AWS is a sub-processor. The full processor terms are on our GDPR page.

How to choose a region

Most teams can settle this in a five-minute conversation. Three questions:

1. Where is your team? If everyone who will browse and restore backups sits in one country or economic area, the region covering that area is the default choice.
2. Where are the people in the data? For a HubSpot or Pipedrive backup, the contacts are the data subjects. If they are overwhelmingly in one jurisdiction, keeping the copy there avoids a transfer.
3. Who will ask? If a regulator, an enterprise customer or a public-sector contract already tells you where data must stay, that answer wins over the first two.

If the three answers disagree, choose the region that satisfies the strictest requirement, and note the decision in your data-processing register so the next audit takes ten minutes instead of a week.

One thing the region does not do: it does not, on its own, make you GDPR or NIS2 compliant. Residency removes one transfer question. Access control, retention, encryption and a tested restore process are separate items on the same checklist. See data security at ProBackup and our earlier post on GDPR and cloud backups.

Frequently asked questions

Where is my Asana, HubSpot or monday.com backup stored?

On AWS S3 in the AWS region you selected when you created your ProBackup account. All apps in the account share that region.

Can I keep my HubSpot backup in one region and my ClickUp backup in another?

Not within one ProBackup account. The region is set per account and applies to every backup in it. Teams that genuinely need two regions run two accounts.

How do I change my data region after backups have started?

Contact support. The change is not available in the interface because it involves moving the account's full snapshot history; support carries out the move for all backups in the account.

Does choosing an EU region make my SaaS backup GDPR compliant?

It removes the international-transfer question for the backup copy. GDPR compliance also depends on your legal basis, retention, access control and processor agreement. ProBackup provides the processor terms on the GDPR page and the audit evidence on the trust centre.

Choose your region and start backing up

Create an account at app.probackup.io/onboarding, pick a region, and connect your first app. The 7-day trial needs no credit card. The interface itself runs in five languages, including French and German.

The regulatory summaries above are a general overview to help you start the conversation internally, not legal advice. Check requirements specific to your organisation and industry with your own legal or compliance team.

In short: Since January 2026 ProBackup runs inside HubSpot: a custom object called 'ProBackup Deleted Records' lists every deleted contact, deal or CRM record, searchable, filterable and usable in workflows, each linked to one-click restore in the ProBackup vault. HubSpot's own trash purges records after 90 days; ProBackup keeps them for your configured retention period, which can extend to years.

Managing deleted CRM data just got significantly easier. ProBackup now lives directly inside your HubSpot account, giving you instant access to deleted records, backup status, and key settings from the interface you already use every day.

Why this matters for HubSpot users

HubSpot's native trash permanently deletes records after 90 days. If someone accidentally removes a contact six months ago, it's gone. ProBackup has always protected against this, but until now you needed to switch to a separate app to recover anything.

With this update, your safety net is built right into HubSpot.

For a side-by-side look at the alternatives, see ProBackup vs SysCloud for HubSpot.

A dedicated object for deleted records

ProBackup now creates a custom object called "ProBackup Deleted Records" in your HubSpot account. Every contact, deal, or CRM record that gets deleted automatically appears here.

This isn't just a log. You can search by type, date, or ID. You can filter, select multiple records, and even add them to workflows. Each record links directly to your ProBackup vault for full history and one-click restoration.

The key difference from HubSpot's trash: ProBackup retains deleted records according to your retention settings, which can extend to years rather than 90 days.

Your backup status at a glance

The new ProBackup homepage inside HubSpot shows everything you need in one view:

• When your last backup completed
• Your current storage usage
• Quick access to deleted records
• A direct link to your full ProBackup vault

No more wondering whether your backups are running. The status is visible whenever you need it.

How far back that history reaches depends on your plan; our pricing page lists retention by plan.

Configure settings without switching apps

You can now adjust ProBackup settings directly from HubSpot's Connected Apps section. Choose your status email frequency, set retention periods for record versions, and configure how long deleted items are kept.

Everything stays in sync with your main ProBackup account. Change a setting in HubSpot, and it applies everywhere.

Getting started

If you already use ProBackup for HubSpot, the deleted records object and homepage are available now. Simply click the Marketplace icon in HubSpot's left menu and select ProBackup.

For recovery beyond the deleted-records object, read our complete HubSpot restore guide.

Not using ProBackup yet? Start your free trial today to protect your HubSpot data:https://app.probackup.io/onboarding

In short: Trello has no trash bin. Archived cards, archived lists and closed boards are kept indefinitely and can be restored from Archived items or the workspace home, but a permanently deleted card, list or board leaves Trello's servers immediately and Atlassian support cannot retrieve it. Always archive or close; delete only test data or items that must be erased for compliance.

Why this guide matters for Trello users

Trello's card-based interface makes it one of the most approachable project management tools on the market. It is also one of the most unforgiving when it comes to data recovery. Unlike most platforms, Trello has no trash bin. When a card, list, or board is permanently deleted, it leaves Trello's servers immediately and permanently, with no recovery window, no escalation path, and no way to ask Atlassian support to retrieve it.

This comprehensive guide shows you:

✓ How to safely archive and delete data in Trello

✓ What Trello's native recovery can and cannot do

✓ How to prevent permanent data loss

✓ A complete backup strategy for business continuity

Who this guide is for:

• IT Administrators managing Trello for their company
• Project Managers responsible for team workflows
• Operations Managers protecting business-critical data
• Compliance Officers ensuring data retention requirements

‍👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

Understanding Trello's data structure

The hierarchy of Trello data

Trello is structured simply, but deletion cascades downward through that hierarchy. Removing a container removes everything inside it, permanently, with no recovery path if you chose Delete rather than Archive.

Trello Data Hierarchy:

Workspace
└── Board
   └── List (column)
       └── Card
           ├── Description
           ├── Checklists & checklist items
           ├── Comments
           ├── Attachments
           ├── Labels
           ├── Members
           └── Due dates & custom fields

Important: Deleting a Board removes:

❌ All Lists inside it

❌ All Cards inside every List

❌ All checklists, checklist items, and descriptions on every Card

❌ All comments and activity history on every Card

❌ All file attachments

❌ All labels, members, and due date data

⚠️ The critical difference from other platforms: Every other tool covered in this series (monday.com, ClickUp, Asana, HubSpot, Airtable) holds deleted items in a trash bin for at least 30 days. Trello does not. A permanently deleted item is gone from Trello's servers the moment you confirm the deletion. There is no timer, no recovery window, and no support escalation that can retrieve it.

How to archive and delete data in Trello

Archive vs. Delete: the most important distinction in Trello

In Trello, this distinction matters more than on any other platform. The reason is simple: archive is reversible indefinitely; delete is immediately and permanently irreversible.

🟢 Archive: The correct choice in almost every situation

• Removes the card, list, or board from your active view
• Preserves all data, comments, attachments, and history indefinitely
• Can be restored at any time from the Archived items menu, no time limit
• Archived cards also improve board performance on large boards
• No countdown clock, no risk of permanent loss

🔴 Delete: Only for data that must be destroyed

• Trello requires you to archive an item before the Delete option appears. This two-step process is your last warning
• Once you click Delete and confirm, the data is gone from Trello's servers immediately and permanently
• Trello support confirms: deleted items cannot be recovered under any circumstances
• The only legitimate reasons to delete are items created by mistake, obvious test data, or GDPR/compliance-driven removal

How to archive a card

Method 1, From the card back:

1. Click the card to open it
2. In the Actions menu on the right sidebar, click Archive
3. The card disappears from the board but is fully preserved

Method 2, From board view:

1. Hover over the card
2. Click the pencil/edit icon that appears
3. Select Archive

Keyboard shortcut: Hover over any card and press C to archive it instantly.

To permanently delete after archiving: reopen the archived card → click the red Delete button that now appears in the Actions menu → confirm. This action is irreversible.

How to archive a list

1. Click the three dots (...) next to the list title
2. Select Archive this list
3. All cards inside the list are archived with it, fully preserved

To permanently delete a list after archiving: open the board menu → More → Archived items → switch to Lists → find the list → click Delete → confirm. This permanently deletes the list and all of its cards, including any cards that were previously archived within it.

⚠️ Warning: Deleting an archived list does not just delete the list structure. It permanently deletes every card the list ever contained, including ones you archived months ago. Verify the full contents before confirming a list deletion.

How to close (archive) a board

1. Click the three dots (...) menu in the top-right corner of the board
2. Select ...More
3. Click Close board
4. Confirm: the board is hidden from your active workspace but fully preserved

To permanently delete a closed board: go to your workspace home → find the closed board → open it → click ...More → Permanently delete board → confirm. Workspace admins on paid plans can also delete closed boards they don't own if they have the board URL.

⚠️ Warning: Board deletion is permanent and cannot be recovered. If you want to get rid of a board without losing its content, close it and leave it closed.

How to restore archived data in Trello

If you followed the archive-first approach, restoration is straightforward and has no time limit.

Restoring archived cards

1. Open the board where the card lived
2. Click the three dots (...) menu in the top-right corner
3. Select ...More → Archived items
4. Use the search bar to find your card by name or keyword
5. Click Send to board to restore it to its original list position

Restoring archived lists

1. Open the board where the list lived
2. Click the three dots (...) menu → ...More → Archived items
3. Toggle to the Lists view
4. Find the list and click Send to board
5. The list and all its cards return to the board

Restoring a closed board

1. Go to your Trello workspace home page
2. Find the closed board (it appears with a closed indicator in your board list)
3. Open it
4. Click Reopen board

Archive and restore summary

What can't be restored natively in Trello

Trello's archive is an excellent tool for keeping workspaces tidy without losing data. It is not a backup. Here is where native recovery ends.

1. Permanently deleted items have zero recovery path

This deserves to be stated plainly. Unlike every other platform in this series, Trello has no trash bin that holds deleted items for any period of time. The moment you confirm a permanent deletion, the data is gone from Trello's servers. There is no 30-day window, no 7-day window, no support ticket that can retrieve it, and no escalation path. Atlassian's own documentation confirms this.

2. Checklist items and comments are gone immediately

Deleting a checklist item or a comment bypasses the archive step entirely. There is no two-step process, no archive-then-delete flow, no toast notification with an undo button. A single click confirms the deletion and the data is gone immediately and permanently.

For teams that use card comments to record decisions, client approvals, or project context, or use checklists to track process steps, this is a significant and often-overlooked exposure.

3. No version history or rollback

Trello's activity log on each card shows a history of changes: when a card moved between lists, when a due date was set, when a member was added. What it cannot do is restore a previous state of the card's data.

If a Power-Up or integration updates card descriptions or custom fields in bulk, or if Butler automation fires on the wrong condition and modifies hundreds of cards, the activity log tells you it happened. It does not give you a way to reverse it.

Common causes of silent data corruption:

• A Butler automation rule fires on a broader set of cards than intended, moving them between lists or updating labels at scale
• A third-party Power-Up integration writes incorrect data to card descriptions or custom fields
• A team member bulk-archives or bulk-deletes cards using the board menu without reviewing each one
• Atlassian Intelligence or a connected AI tool takes action on cards based on an ambiguous instruction

4. What Trello support can and cannot do

✅ Can do:

• Advise on using the Archived items menu and board restoration
• Investigate if data loss was caused by a platform bug
• Sometimes restore data if a verified system error caused the loss (rare)

❌ Cannot do:

• Recover permanently deleted cards, lists, or boards
• Recover deleted comments or checklist items
• Roll back bulk changes made by Butler automations, AI agents editing boards over MCP, or Power-Up integrations
• Provide any recovery path for items deleted through the standard Delete flow

Common data loss scenarios & solutions

Scenario 1: "A board with months of client work was permanently deleted"

What happened: A workspace admin was cleaning up old boards and permanently deleted an active client board, thinking it was a completed test project. There is no confirmation showing what is inside before the final delete step.

Native solution:

‍✗ Board deletion in Trello is immediate and permanent

✗ There is no trash bin, no recovery window, and no timer

✗ Trello support cannot retrieve permanently deleted boards

✗ Must reconstruct from emails, screenshots, or memory

Scenario 2: "An archived board was deleted... and took all its cards with it"

What happened: A team member deleted an archived board to clean up the Archived items menu, not realising that deleting an archived board permanently deletes every card it ever contained - including cards that had been archived months earlier.

Native solution:

‍✗ Deleting an archived list permanently destroys all its cards - both open and previously archived

✗ There is no recovery path for any of those cards

✗ The activity log shows the list was deleted but cannot restore it

Scenario 3: "Comments recording a client approval were deleted"

What happened: A team member tidied up a card by deleting old comment threads. The comments included written client approval of a project scope. The client is now disputing what was agreed.

Native solution:✗ Deleted comments have no archive step and no recovery path in Trello✗ Gone immediately and permanently on click✗ The card's activity log shows comments were added and deleted but does not show the comment content✗ Trello support cannot retrieve deleted comment text

Scenario 4: "A Butler automation moved 300 cards to the wrong list"

What happened: A Butler rule was misconfigured and triggered on a broader set of cards than intended, moving 300 cards from their correct lists into a "Done" list. The cards still exist, but all workflow context (which stage each card was in) is lost.

Native solution:

‍✗ Cards were moved, not deleted = the archive offers no help

✗ Activity log shows each card's movement but moving 300 cards back manually is hours of work

✗ No bulk undo or rollback mechanism in Trello

Scenario 5: "A departing employee permanently deleted all their boards"

What happened: A team member with admin access deleted 6 boards before their last day. All work history, checklists, and client communication stored in those boards is gone.

Native solution:

‍✗ Permanently deleted boards cannot be recovered, not by admins, not by Atlassian support

✗ There is no audit log showing what data existed in the boards before deletion

✗ No time window to recover, deletion is immediate

Scenario 6: "Checklists were deleted from cards across a process board"

What happened: A team member deleted checklist items from 40 cards while "cleaning up" a process board, removing the step-by-step process documentation attached to each task.

Native solution:

‍✗ Checklist items deleted directly have no archive step and no recovery path

✗ Gone immediately on click with no undo mechanism

✗ No way to restore them through any native Trello feature

Quick reference: "I lost data: what should I do?"

Summary: Why Trello's archive isn't enough for professional teams

Trello's archive is one of the most straightforward data preservation tools in the category, indefinite retention with simple restoration. But it was built to keep workspaces tidy, not to serve as a disaster recovery system. And crucially, it offers zero protection against permanent deletion, which in Trello is immediate, irreversible, and happens with a single confirmation click.

Compliance & data retention

Data retention requirements by industry

GDPR compliance: the "right to be forgotten"

When an EU citizen requests deletion of their personal data, you must delete it from production systems and backups, and document it within 30 days.

How this works with Trello + ProBackup:

Step 1: Delete user data from Trello: remove the person from the workspace, permanently delete cards containing their personal data, and remove personal data from card descriptions and comments.

Step 2: Request deletion from ProBackup: open a support ticket specifying the user and date range. ProBackup purges that data from backup storage.

Step 3: Export a deletion certificate from ProBackup for your GDPR compliance documentation.

👉 Read our full GDPR guide: Handling GDPR Deletion Requests in Your Backup System

SOC 2 & ISO 27001: what auditors look for

Protect your Trello data today

Trello's simplicity is one of its greatest strengths. But that same simplicity extends to its deletion model: there is no confirmation screen that shows you what you are about to destroy, no trash bin to fish things out of afterwards, and no support escalation that can retrieve what's gone. For Trello specifically, the question is not whether you need a backup. It is how recent your last snapshot needs to be.

ProBackup gives you:

✓ Automated daily backups of all your Trello data

The step-by-step walkthrough is in how to back up your Trello boards.

✓ Unlimited retention on the Premium plan (no expiration, ever)

✓ Point-in-time recovery (restore from any date)

✓ Granular restore (one card, one board, or everything)

✓ Google Drive sync on Pro and Premium plans (you own your data)

✓ SOC 2 Type II certified (enterprise-ready)

✓ 3-minute setup (no technical knowledge needed)

Evaluating backup tools? See how ProBackup compares to Rewind for Trello.

‍👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

In short: To back up HubSpot with ProBackup: start the 7-day free trial at probackup.io/backup/hubspot, choose HubSpot, enter your name and email and verify it, then click 'Sign in with HubSpot', pick the account and click Start Backup. The first backup fetches contacts, companies, deals, quotes, notes, tasks and emails and can take a few hours; daily backups then run automatically.

HubSpot is a leading customer platform for business of all sizes, covering all aspects to manage your CRM, marketing, sales, services, content management & operations. While you rightfully trust cloud apps like HubSpot to be secure and reliable, managing your business's critical data on any single platform opens the door to potential risks. 

Using HubSpot to manage your CRM can expose your team to issues such as accidental data deletion from human error, malicious actions by disgruntled employees, or data loss due to technical glitches and downtime. Losing an important contacts, notes or deals can set your team back hours.

To gain peace of mind and protect your CRM, implementing an automated backup solution is essential. This guide will walk you through setting up a daily, automated backup for your HubSpot account using ProBackup.

Part 1: Create a ProBackup Account

Getting started is easy and comes with a 7-day free trial.

1. Visit the ProBackup for HubSpot page by navigating to https://www.probackup.io/backup/hubspot
2. Click on the Start free 7 day trial button.
3. Select HubSpot as the app you would like to back up and click Continue
4. Fill in your email, first name, and last name, then click Continue.

5. Verify your email address by following the instructions sent to your inbox.

Part 2: Connect HubSpot and Start Your First Backup

Once your ProBackup account is created and verified, you can connect your HubSpot account. 

We recommend that you sign in to the right HubSpot account first, before connecting your account. 

1. In ProBackup, click on Sign in with HubSpot. This will redirect you to HubSpot to authorize the connection. If you are not signed in to HubSpot, then you will have to sign in first. 

‍

2. On the HubSpot authorization page, select the account you would like to back up
3. Click on Choose Account

3. On the next step of the onboarding wizard, click on Start Backup to start your first backup.

What Happens Next?

After you confirm, the initial backup of your selected HubSpot will begin automatically. Our backup app will fetch all relevant data types such as contacts, organizations, deals, quotes and related information such as notes, tasks and emails. Depending on the size of your HubSpot account, the initial backup can take up to a few hours. You will be notified by email as soon as the first backup is complete.

Click on Go to HubSpot to view the data that is already backed up. Once the first backup lands, you can also browse deleted records without leaving HubSpot. 

That’s it! Your HubSpot account is now protected with daily automated backups, ensuring your data is safe and easily restorable when you need it most.

Still evaluating backup tools? See how ProBackup compares to Skyvia for HubSpot.

It is also worth reading our ProBackup vs SysCloud breakdown for HubSpot.

In short: ClickUp's Trash holds deleted Spaces, Folders, Lists, tasks and Docs for 30 days; owners and admins restore from Settings > Trash, members only their own deletions. Archive instead of deleting wherever possible. Deleted comments, individually deleted attachments, time entries and custom-field values never reach the Trash and are gone immediately, so only an independent backup brings them back.

Why this guide matters for ClickUp users

ClickUp is mission-critical for project management, operations, and client delivery. Teams use it to track every task, conversation, and decision. But here's the reality: 3 out of 4 teams will experience data loss from accidental deletion, human error, or system issues at some point.

This comprehensive guide shows you:

• How to safely delete and restore data in ClickUp
• What ClickUp's native recovery can and cannot do
• How to prevent permanent data loss before it happens
• A complete backup strategy for business continuity and compliance

Who this guide is for:

• IT Administrators managing ClickUp for their organization
• Project Managers responsible for team workflows and deliverables
• Operations Managers protecting business-critical data
• Compliance Officers ensuring data retention requirements are met

👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

Understanding ClickUp's data structure

Before you delete anything, understand how ClickUp organizes data. Deletion flows downward: removing a high-level container removes everything inside it.

ClickUp Data Hierarchy:

Workspace
└── Space
   ├── Folder (optional)
   │   └── List
   │       ├── Task
   │       │   ├── Subtask
   │       │   ├── Comments
   │       │   ├── Attachments
   │       │   └── Time entries
   │       └── Checklist
   └── List (standalone, no Folder)

Important: Deleting a Space removes:

❌ All Folders and Lists inside it

❌ All Tasks and Subtasks

❌ All comments and communication history

❌ All file attachments

❌ All time entries (permanently, even if restored from Trash, time entries are gone)

❌ All custom field data and task history

How to archive and delete data in ClickUp

Best practice: Archive vs. Delete

🟢 Archive: Recommended 99% of the time

• Removes item from active view without deleting data
• Preserves all data and history indefinitely
• Can be restored at any time
• Archived Spaces don't count toward Free plan limits
• Automations in archived Spaces continue to run; items remain searchable

🔴 Delete: Use with extreme caution

• Moves to Trash with a 30-day retention window
• Permanently erased after 30 days
• Comments, files, and time entries may not be recoverable even within 30 days
• Cannot be undone after the Trash is emptied or the window expires

How to archive a Space

1. In your Sidebar, hover over the Space name and click the ellipsis (...) menu
2. Select Archive
3. The Space is hidden from your active Sidebar but fully preserved
4. To view archived Spaces, use All Spaces and toggle archived items visible
5. To restore: hover over the archived Space → ellipsis (...) → Restore

How to delete a Space

1. First archive the Space (you can only delete an archived Space in ClickUp)
2. Show archived items in the Sidebar
3. Hover over the archived Space → ellipsis (...) → Delete
4. Confirm deletion
5. Space moves to Trash: recoverable within 30 days by Workspace owners, admins, or the member who created and deleted it

How to archive a Folder or List

1. In your Sidebar, hover over the Folder or List and click the ellipsis (...) menu
2. Select Archive
3. The Folder or List is hidden from active view but data is preserved
4. To restore: find the archived item → ellipsis (...) → Restore

How to delete a Folder or List

1. Hover over the Folder or List in the Sidebar and click the ellipsis (...) menu
2. Select Delete
3. Confirm the action
4. Item moves to Trash: recoverable within 30 days by Workspace owners, admins, or the member who created and deleted it

How to delete a Task

1. Open the task and click the ellipsis (...) in the upper right, then click Delete, or:
2. Hover over a task, click the task selector checkbox, then click the trash icon in the Bulk Action Toolbar, or:
3. Right-click a task and select Delete from the Task Action Menu
4. Task moves to Trash: recoverable within 30 days

⚠️ Warning: If a task has time entries, a warning is displayed before deletion. Time entries are permanently deleted even if the task is later restored from Trash.

How to archive or delete multiple Tasks

• Switch to List or Table view.
• Select the tasks you want by checking the boxes.
• Click the Archive or Delete icon in the action bar that appears.

How to restore data in ClickUp

ClickUp has a unified Trash that holds all deleted items, Spaces, Folders, Lists, Tasks, Docs, and more, for 30 days before permanent deletion.

How to access the Trash

As a Workspace owner or admin:

1. Click your Workspace avatar in the upper-right corner
2. Select Settings
3. In the left sidebar, click Trash

As a member (for items you deleted yourself):

1. Click your profile avatar in the bottom-left corner
2. Select Trash from the dropdown menu

How to restore deleted Tasks

1. Open Trash (steps above)
2. Search for the task by name, or filter by item type, Space, or date deleted
3. Hover over the task and click the ellipsis (...)
4. Select Restore
5. The task returns to its original List

How to restore deleted Folders and Lists

1. Open Workspace Trash (owner/admin access required)
2. Filter by item type: Folder or List
3. Click the ellipsis (...) next to the item
4. Select Restore
5. The Folder or List, along with all its contents, is restored to its original location

How to restore deleted Spaces

1. Open Workspace Trash (owner/admin access required, or member who both created and deleted the Space)
2. Filter by item type: Space
3. Click Restore next to the Space
4. All Folders, Lists, and Tasks inside the Space are restored

Restoring from a backup behaves differently from the Trash: an overwrite restore writes the backed-up values back onto tasks that still exist, instead of creating duplicates.

Trash retention and permissions summary

What can't be restored natively in ClickUp

ClickUp's Trash is a useful safety net for immediate mistakes, but it has critical limitations that can lead to permanent data loss.

A. Granular data is gone immediately

When you delete the following items, they disappear permanently and do not appear in the Trash:

• Individual comments on tasks
• Single file attachments (in most cases)
• Time entries (lost even when a task is later restored)
• Custom field values when the field itself is deleted
• Activity log entries

Docs are their own case: once the Trash window has passed, the only way to restore ClickUp Docs is from an independent backup.

B. No version history or rollback

ClickUp has no field-level version history and no rollback. Trash covers deletions only: deleted Spaces, Folders, Lists, tasks and Docs stay in Trash for 30 days (ClickUp Help, checked 16 September 2026). If a task still exists but its status, custom fields, assignees or description were overwritten, ClickUp holds no earlier version to return to, and the change is invisible to Trash. A daily snapshot is the only record of what the task looked like yesterday. See how ClickUp's windows compare with Asana, monday.com, HubSpot and others in Version history and trash retention per app and plan.

Common causes:

• ✗ A third-party integration syncs incorrectly and bulk-updates task statuses or custom fields
• ✗ An automation rule fires unexpectedly and changes values across hundreds of tasks
• ✗ An API script runs against the wrong List or Workspace
• ✗ A bulk import pastes incorrect data over existing content

C. What ClickUp support can and cannot do

✅ Can do:

• Advise on using Trash and archive features
• Investigate if deletion was caused by a platform bug
• Sometimes restore data if a verified system error caused the loss (rare)

❌ Cannot do:

• Recover data deleted more than 30 days ago
• Recover deleted comments, time entries, or individual attachments
• Roll back bulk changes made by automations or integrations
• Restore data from an emptied or expired Trash

Common data loss scenarios & solutions

Scenario 1: "I accidentally deleted a Space with 6 months of client work"

What happened: A PM was cleaning up the Workspace and deleted an active client Space instead of archiving it. Noticed the mistake 2 weeks later.

Native solution:

‍✓ Open Workspace Trash (Settings → Trash)

✓ Filter by Space, find the item, click Restore

✓ All Folders, Lists, and Tasks come back

✓ Must be done within 30 days

If it happened 31+ days ago:

‍✗ Data is permanently gone

✗ No native recovery option

✗ Must rebuild from emails, exports, or memory

Scenario 2: "Someone deleted all comments on our tasks"

What happened: A team member "cleaned up" a project by deleting comment threads across 60 tasks. All decision history and client communication is now gone.

Native solution:

‍✗ Comments do not go to Trash

✗ Once deleted, they are immediately and permanently gone

✗ ClickUp support cannot recover them

✗ No workaround exists

Impact:

• Lost context on why decisions were made
• Can't prove what was approved by the client
• Team has to reconstruct decisions from memory or email

Scenario 3: "Our integration overwrote all our task statuses"

What happened: A third-party integration had a sync error and updated 400 task statuses to the wrong values. The tasks still exist, but all status data is corrupted.

Native solution:

‍✗ Tasks weren't deleted, so Trash doesn't help

✗ No version history to roll back to

✗ No "undo" for bulk field value changes

✗ Must manually correct each task

Time to fix: 10+ hours

Scenario 4: "We need to recover a project from 6 months ago for a dispute"

What happened: A client claims the agreed deliverables were different from what was delivered. You need the original List structure and task descriptions from 6 months ago to prove what was scoped.

Native solution:

‍✗ If archived: you can restore, but only the current state - no point-in-time view

✗If deleted more than 30 days ago: data is permanently gone

✗ No version history means no view of "what it looked like on a specific date"

Scenario 5: "A departing employee deleted everything on their way out"

What happened: An admin-level team member deleted 6 Spaces and emptied the Trash before their last day. The deletion was intentional.

Native solution:

‍✗ If Trash was emptied manually, items are immediately and permanently gone

✗ The 30-day window doesn't apply once Trash is manually purged

✗ ClickUp support cannot recover from an emptied Trash

✗ No audit trail showing what existed before

Quick reference: "I lost data... what should I do?"

Summary: Why native Trash isn't enough for professional teams

ClickUp's Trash is a safety net for immediate mistakes, not a disaster recovery plan. If your team relies on ClickUp for revenue-generating work or compliance requirements, native Trash alone is insufficient.

Compliance & data retention

Data retention requirements by industry

Whether you can meet those windows depends on how long your snapshots are kept, so check the retention per plan before committing to a policy.

GDPR compliance: the "right to be forgotten"

When an EU citizen requests deletion of their personal data, you must delete it from production systems and backups, and document it within 30 days.

How this works with ClickUp + ProBackup:

Step 1: Delete user data from ClickUp: remove the person from your Workspace, delete tasks assigned to them, and purge personal data from custom fields.

Step 2: Request deletion from ProBackup: open a support ticket specifying the user and date range. ProBackup purges that user's data from backup storage.

Step 3: Export a deletion certificate from ProBackup for your GDPR compliance documentation.

👉 Read our full GDPR guide: Handling GDPR Deletion Requests in Your Backup System

SOC 2 & ISO 27001: what auditors look for

Protect your ClickUp data today

Don't wait for a data loss disaster to implement backup. Accidental deletion, automation errors, and integration mishaps can strike any team at any time, and ClickUp's 30-day Trash gives you no buffer against granular data loss or bulk changes.

ProBackup gives you:

✓ Automated daily backups of all your ClickUp data

✓ Unlimited retention on the Premium plan (no 30-day expiration)

✓ Point-in-time recovery (restore from any date)

✓ Granular restore (one task, one List, or everything)

✓ Google Drive sync on Pro and Premium plans (you own your data)

✓ SOC 2 Type II certified (enterprise-ready)

✓ 3-minute setup (no technical knowledge needed)

👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

In short: ProBackup added Webflow in July 2025, its first website-builder integration, with daily automated backups of Webflow projects. Paid ProBackup customers can back up Webflow alongside their other apps at no extra cost: log in, click '+ New App', select Webflow and authorise the connection. It is aimed at SMEs, designers and marketers who build and manage their sites in Webflow.

We are excited to announce that ProBackup now supports Webflow, our first-ever website builder integration! This marks an important milestone in our mission to become the one-stop backup solution for SMEs relying on SaaS applications.

What is Webflow?

Webflow is a powerful website-building platform that allows users to design, build, and launch websites visually, without the need for traditional coding. It combines the flexibility of custom development with the ease of a drag-and-drop editor.

Why Webflow?

Many SMEs, designers, and marketers rely on Webflow for its intuitive interface, robust customization options, and ability to create pixel-perfect, responsive websites. Since a large portion of our customers already use Webflow, adding backup support was a logical step in expanding our services. It’s a favorite among SMEs, designers, and marketers who need an intuitive yet powerful tool to build and manage their online presence. Since many of our customers already use Webflow, this integration was a natural next step. 

What This Means for You

• Automated Backups for Webflow: Keep your Webflow projects safe with daily backups.
• Free for Existing Customers: If you're a paid user, you can now back up Webflow alongside your other SaaS apps at no additional cost.
• More Website Builder Support? Let us know if we should add more website apps!

How to Add Webflow to ProBackup

1. Log in to your ProBackup account.
2. Click the "+ New App" button.
3. Select the Webflow app to start connecting and authorize ProBackup.
4. Start automatic backups 

More Integrations Coming Soon

Webflow is the first of a series of new updates. We are actively working on integrations for Figma and Canva, and we're also working on a complete revamp of the user interface. Stay tuned for more product updates.

Try our new Webflow integration today and keep your websites secure with ProBackup!

In short: monday.com keeps deleted items, groups, columns, boards, docs and dashboards in Trash for 30 days, restorable by admins or the person who deleted them; archived items are kept indefinitely, so archive first. Two traps: deleting a column wipes that data on every item instantly, and restoring a deleted workspace returns an empty shell, so each board must be restored separately.

Why this guide matters for monday.com users

monday.com is mission-critical for teams running sales pipelines, project workflows, engineering sprints, onboarding processes, and client operations. But here's the reality: 55% of teams experience data loss from accidental deletion, human error, or system issues.

This comprehensive guide shows you:

✓ How to safely delete and restore data in monday.com

✓ What monday.com's native recovery can and CAN'T do

✓ How to prevent permanent data loss

✓ A complete backup strategy for business continuity

Who this guide is for:

• IT Administrators managing monday.com for their company
• Project Managers responsible for team workflows
• Operations Managers protecting business-critical data
• Compliance Officers ensuring data retention requirements

👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

Understanding monday.com's data structure

The hierarchy of monday.com data

Before you delete anything, understand how monday.com organizes data. Deletion flows downward, removing a high-level container removes everything inside it.

monday.com Data Hierarchy:

Account
└── Workspace
   ├── Folder / Sub-folder (optional)
   │   └── Board
   │       ├── Group
   │       │   ├── Item (row)
   │       │   │   ├── Subitem
   │       │   │   ├── Updates (comments)
   │       │   │   └── File attachments
   │       │   └── Columns (Status, Date, Text, People…)
   │       └── Views
   ├── Dashboard
   └── Workdoc

Important: Deleting a Workspace or Board removes:

❌ All boards, groups, and items inside it

❌ All subitems and their data

❌ All updates (comments) and communication history

❌ All file attachments

❌ All column data across every item

❌ All views, dashboards connected to that board

How to archive and delete data in monday.com

Best practice: Archive vs. Delete

🟢 Archive: Recommended 99% of the time

• Removes item from active view without deleting any data
• Preserves all data and history indefinitely
• Can be restored at any time, even years later
• Archived items can be automated: set up rules to archive completed items automatically
• No permanent consequences

🔴 Delete: Use with extreme caution

• Moves to Trash with a 30-day retention window
• Permanently erased after 30 days: monday.com support cannot recover it
• Comments and certain file types may not be recoverable even within 30 days
• Cannot be undone after the Trash window expires

How to archive an item

1. Select the item in the board view
2. Click the three dots (...) in the item popup at the bottom of the screen
3. Choose Archive
4. Confirm the action: the item disappears from the active board but is preserved

To restore: open the board → three-dot menu (...) → View archive/trash → Archive tab → find the item → Restore

How to archive a group

1. Click the three-dot menu (...) to the left of the group name on your board
2. Select Archive group
3. Confirm: the group and all its items are preserved

To restore: open the board → three-dot menu (...) → View archive/trash → Archive tab → filter by Group → Restore

How to archive a board

1. Click the three-dot menu (...) next to the board name in the left sidebar
2. Select Archive board
3. The board moves to the Board Archive, hidden from the active workspace

To restore: click the three-dot menu (...) in the workspace navigation bar → View archive/trash → Archive → find the board → Restore. You can also use Search Everything (magnifying glass icon) → Archived Boards → open the board → board menu → Unarchive board

How to delete an item

1. Select the item in the board
2. Click the three-dot menu (...) in the item popup
3. Select Delete
4. Confirm: item moves to Trash, recoverable for 30 days

How to delete a group

1. Click the three-dot menu (...) to the left of the group name
2. Select Delete
3. Confirm: the group and all items inside move to Trash, recoverable for 30 days

How to delete a column

1. Click the three-dot menu (...) at the top of the column header
2. Select Delete column
3. Confirm the action

⚠️ Warning: Deleting a column removes that data point from every single item on the board, across all groups, instantly. There is no selective undo in monday.com. The column moves to Trash, but the data values inside each item may not be fully restored even if the column is recovered. If a column is accidentally deleted, your only reliable path back is a backup that pre-dates the deletion.

How to delete a board

1. Click the three-dot menu (...) next to the board name in the left sidebar
2. Select Delete board
3. Confirm: the board and all its contents move to Trash, recoverable for 30 days

How to delete a workspace

1. Open the left side panel and hover over the workspace name
2. Click the three-dot menu (...) next to its name
3. Select Delete workspace
4. Confirm: the workspace moves to Trash for 30 days

⚠️ Warning: Restoring a deleted workspace from Trash gives you back only the workspace container. You must restore each board inside it separately from Trash. Do not delete a workspace unless you have already archived or backed up the boards within it.

How to restore data in monday.com

monday.com offers two parallel recovery paths: Archive (indefinite, for items you deliberately put away) and Trash (30-day window, for accidentally deleted data).

How to access the Archive

For items, subitems, groups (board-level):

1. Open the board containing the archived data
2. Click the three-dot menu (...) in the upper-right corner of the board
3. Click View archive/trash, then select the Archive tab
4. Browse or filter by type (Item, Subitem, Group), date archived, or board name
5. Select the item(s) and click Restore

For archived boards:

1. Click the three-dot menu (...) above the workspace navigation bar in the left panel
2. Select View archive/trash → Archive
3. Find the board and click Restore

How to access the Trash

1. Click your avatar/profile picture in the upper-right corner
2. Select Trash
3. Browse deleted items: filter by type (Item, Subitem, Column, Group, Board, Doc, Dashboard), date deleted, or board name
4. Click the three-dot menu (...) to the right of the item
5. Select Restore

💡 Permissions note: Only admins and the person who deleted an item can see and restore it from Trash. If a board was set to "Only owners can change" permissions, non-owners will not see deleted items from that board in Trash.

A backup restore works along different lines: an overwrite restore puts the backed-up column values back onto items that still exist, rather than adding duplicates.

Restoration options and retention summary

What can't be restored natively in monday.com

monday.com's Archive and Trash are useful for catching recent mistakes, but they have critical limitations that can lead to permanent, unrecoverable data loss.

1. Comments and updates are gone immediately

When a team member deletes an update (comment) on an item, it does not go to Trash. It disappears instantly and permanently. There is no recovery path, native or otherwise, without a third-party backup.

2. No version history or data rollback

This is the limitation that causes the most damage in practice. If a board still exists but the data inside it has changed (wrong values, overwritten fields, a corrupted import) monday.com has no way to show you what it looked like before.

The activity log tells you that a change happened and who made it. It does not let you revert those changes at scale.

Common causes of silent data corruption:

• ✗ A bulk import maps columns incorrectly and overwrites existing data across hundreds of items
• ✗ An automation rule fires on unintended items and changes Status, Date, or custom field values
• ✗ monday.com's AI Sidekick misinterprets a prompt and updates records at scale
• ✗ A third-party integration syncs incorrectly and bulk-pushes wrong values
• ✗ An API script runs against the wrong board or workspace

None of these are deletions, so they don't appear in Trash. The activity log shows what happened, but reversing it manually at scale is not realistic.

3. The 30-day hard cutoff

monday.com confirms in their own documentation that anything deleted more than 30 days ago is permanently gone. There is no extended retention window, no archive tier for deleted items, and no way to request recovery from their support team after that point.

4. Files uploaded directly to items

Files attached to an item via the Files tab are not available through monday.com's API and are not reliably recoverable after deletion. Files shared through file columns or comments can be backed up, but direct item uploads are a known gap.

5. What monday.com support can and cannot do

Common data loss scenarios & solutions

Scenario 1: "I accidentally deleted a board with 6 months of client work"

What happened: A PM was tidying up the workspace and clicked Delete instead of Archive on an active client board. Noticed the mistake 3 weeks later.

Native solution:

‍✓ Go to your avatar menu → Trash

‍✓ Filter by Board, find the item, click Restore

‍✓ All groups, items, and history are recovered

✓ Must be done within 30 days

If it happened 31+ days ago:

‍✗ Data is permanently gone

✗ No native recovery option

✗ Must rebuild from emails, exports, or memory

Scenario 2: "Someone deleted all the updates on our items"

What happened: A team member "cleaned up" tasks by deleting comment threads across 80 items. All decision history, client approvals, and context are now gone.

Native solution:

‍✗ Deleted updates (comments) do not go to Trash

✗ Once deleted, they are immediately and permanently gone

✗ monday.com support cannot recover them

✗ No workaround exists natively

Impact:

• Lost proof of client approvals
• No context on why decisions were made
• Team must reconstruct discussions from memory or email

Scenario 3: "A column was accidentally deleted, and took data with it"

What happened: An editor deleted a custom Priority column, thinking it was a duplicate. The column affected 300 items across 12 groups. The column appeared in Trash, but restoring it did not recover all the original cell values.

Native solution:⚠️ Column goes to Trash and can be restored within 30 days, but the individual cell values stored in that column are not guaranteed to return✗ For a column deleted more than 30 days ago: permanently gone✗ If cell values are lost even after column restoration, there is no further native recovery path

Scenario 4: "Our automation overwrote all our item statuses"

What happened: An automation rule was misconfigured and updated the Status column on 500 items across three boards to the wrong value. The items still exist: The data inside them is just wrong.

Native solution:

‍✗ Items weren't deleted, so Trash doesn't help

✗ Activity log shows what changed but cannot revert it at scale

✗ No version history to roll back to✗ Manual correction across 500 items: 10+ hours of work

Scenario 5: "monday.com AI Sidekick updated the wrong boards"

What happened: A team member used monday.com's AI Sidekick to bulk-update item fields. The prompt was ambiguous and the agent applied changes to the wrong workspace boards, overwriting statuses and dates across hundreds of items.

Native solution:

‍✗ These are data changes, not deletions, so Trash is irrelevant

✗ Activity log confirms the changes occurred but cannot undo them in bulk

✗ No rollback mechanism exists in monday.com for AI-driven updates

✗ Manual correction required

Scenario 6: "A departing employee deleted everything on their way out"

What happened: An admin-level employee deleted 9 boards and their workspace before their last day. The deletions were intentional.

Native solution:

‍✗ If within 30 days: boards can be restored from Trash by another admin

✗ If the workspace was also deleted: boards must be restored separately from Trash after restoring the workspace shell

✗ After 30 days: everything is permanently gone

✗ No audit trail showing what data existed before deletion

Quick reference: "I lost data: what should I do?"

Summary: Why Archive and Trash aren't enough for professional teams

monday.com's native recovery tools are designed to catch immediate mistakes, not to serve as a disaster recovery plan. Here is how they stack up:

Compliance & data retention

Data retention requirements by industry

Meeting those windows depends on how far your snapshots go back, so check the retention per plan before you commit to a retention policy.

GDPR compliance: the "right to be forgotten"

When an EU citizen requests deletion of their personal data, you must delete it from production systems and backups, and document it within 30 days.

How this works with monday.com + ProBackup:

Step 1: Delete user data from monday.com: remove the person from your account, delete items assigned to them, and purge personal data from column values.

Step 2: Request deletion from ProBackup: open a support ticket specifying the user and date range. ProBackup purges that user's data from backup storage.

Step 3: Export a deletion certificate from ProBackup for your GDPR compliance documentation.

👉 Read our full GDPR guide: Handling GDPR Deletion Requests in Your Backup System

SOC 2 & ISO 27001: what auditors look for

Protect your monday.com data today

Don't wait for a data loss disaster to implement backup. As monday.com expands into AI-powered workflows with Sidekick and agentic automations, the risk of bulk, unintended data changes grows alongside the risk of accidental deletion. A single misconfigured agent or automation can touch every item on a board before anyone notices, and the activity log will show you it happened, but won't undo it.

ProBackup gives you:

✓ Automated daily backups of all your monday.com data

✓ Unlimited retention on the Premium plan (no 30-day expiration)

✓ Point-in-time recovery (restore from any date)

✓ Granular restore (one item, one board, or everything)

✓ Google Drive sync on Pro and Premium plans (you own your data)

✓ SOC 2 Type II certified (enterprise-ready)

✓ 3-minute setup (no technical knowledge needed)

New to this? Our walkthrough shows how to set up a monday.com backup from scratch.

ProBackup is also a monday.com marketplace partner, so you can install it straight from the marketplace.

Evaluating backup tools? See how ProBackup compares to Rewind for monday.com.

👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

In short: Slack's free plan now keeps only the last 90 days of messages and files; anything older becomes inaccessible unless the workspace upgrades to a paid plan. ProBackup backs up Slack users, channels, threads, messages, attachments and the direct messages you can access, retaining versions for 6 months on Plus, 2 years on Pro and unlimited on Premium.

Slack recently rolled out significant updates that impact users on free workspaces, limiting data retention and message history. If you manage projects or collaborate with teams on Slack’s free plan, it's crucial to understand these changes and how they affect your ability to access past conversations and files. Here’s everything you need to know about the update and why a solid backup strategy is more important than ever.

What’s Changing in Slack’s Free Workspaces?

Slack has shifted from storing messages and files indefinitely to a rolling 90-day limit on free workspaces. This means:

• Message Retention: Only messages from the past 90 days will be available. Anything older will be inaccessible unless your workspace is upgraded to a paid plan.
• File Storage: Similarly, files shared more than 90 days ago will no longer be accessible.

This change can be a major disruption for teams that rely on Slack for daily communication. Old conversations, decisions, and shared files are critical, especially in long-term projects.

Why Should You Be Concerned?

While Slack's free plan remains a valuable tool for small teams, the updates pose a risk of data loss. Without proper backups, you could lose access to important files, project discussions, or decision-making threads, which may affect future work. Key risks include:

• Loss of Historical Data: Teams often refer back to past discussions in long-term projects. Under the new Slack policy, this historical data could vanish unless you pay for a higher plan.
• Unreliable File Availability: Shared files older than 90 days will no longer be stored, which could lead to gaps in your documentation.

How ProBackup Can Help

ProBackup is designed to protect your valuable data on platforms like Slack. Our solution offers automated, scheduled backups that ensure your conversations, files, and attachments are securely stored and easily retrievable - no matter what happens on Slack’s servers.

With ProBackup, you can back up various types of data, including:

• Users: Maintain records of all team members.
• Channels: Keep a complete history of discussions across different channels.
• Threads: Save important threaded conversations for context.
• Messages: Archive all messages for future reference.
• Attachments: Securely store files shared in channels and direct messages.
• Direct Messages: Back up direct messages that you have access to, ensuring no vital communication is lost.

With ProBackup, the retention of your data depends on your subscription plan:

• Plus Plan: Retains revisions for up to 6 months.
• Pro Plan: Retains revisions for up to 2 years.
• Premium Plan: Retains revisions forever (unlimited retention).

This flexibility allows you to choose a plan that best fits your team's needs.

What You Can Do Now

To avoid any disruption or potential data loss, here’s what you should do:

1. Evaluate Your Needs: If you rely heavily on Slack’s free version for project management, consider the potential impact of the 90-day limit.
2. Upgrade or Back Up: You can either upgrade to Slack’s paid plan for longer retention or use ProBackup to ensure your data is backed up and retrievable.
3. Set Up ProBackup: Automate the process of securing your Slack data, giving you continuous access to your messages and files based on your chosen retention plan.

Conclusion

Slack's changes to free workspaces introduce limits that could put your team’s data at risk. ProBackup offers a seamless solution to these challenges by ensuring your conversations and files are always backed up, accessible, and secure - so you can focus on what matters most: getting work done.

‍

In short: to back up ClickUp, connect a backup service such as ProBackup to your workspace via OAuth — about three minutes of setup. Your lists, tasks, comments, files, custom fields and ClickUp Docs are then copied automatically every 24 hours to independent storage, with one-click restore of a single task or an entire list to any backed-up date.

ClickUp is a fantastic all-in-one productivity platform that helps teams manage everything from simple tasks to complex, multi-stage projects. While you rightfully trust cloud apps like ClickUp to be secure and reliable, managing your business's critical data on any single platform opens the door to potential risks. 

Using ClickUp to manage your business can expose your team to issues such as accidental data deletion from human error, malicious actions by disgruntled employees, or data loss due to technical glitches and downtime. Losing an important ClickUp task or list can set your business back hours, or even days.

To gain peace of mind and protect your workflow, implementing an automated backup solution is essential. This guide will walk you through setting up a daily, automated backup for your ClickUp account using ProBackup.

Part 1: Create a ProBackup account

Getting started is easy and comes with a 7-day free trial.

1. Visit the ProBackup for ClickUp page by navigating to https://www.probackup.io/backup/clickup
2. Click on the Start free 7 day trial button.
3. Select ClickUp as the app you would like to back up and click Continue
4. Fill in your email, first name, and last name, then click Continue.

5. Verify your email address by following the instructions sent to your inbox.

Part 2: Connect ClickUp and start your first backup

Once your ProBackup account is created and verified, you can connect your ClickUp account. 

We recommend that you sign in to the right ClickUp account first, before connecting your account. 

1. In ProBackup, click on Sign in with ClickUp. This will redirect you to ClickUp to authorize the connection. If you are not signed in to ClickUp, then you will have to sign in first. 

2. On the ClickUp authorization page, select the workspaces you would like to back up and click on Connect Workspaces. 

3. Click Start Backup to grant ProBackup access and begin your first backup.

Alongside your lists and tasks, ClickUp Docs are covered too.

What happens next?

After you confirm, the initial backup of your selected ClickUp workspaces will begin automatically. Our backup app will fetch all relevant data types such as lists, tasks, comments, files and ClickUp docs. Depending on the size of your ClickUp account, the initial backup can take up to a few hours. You will be notified by email as soon as the first backup is complete.

Click on Go to ClickUp to view the lists that are already backed up. 

That’s it! Your ClickUp account is now protected with daily automated backups, ensuring your data is safe and easily restorable when you need it most.

Every change is kept as a revision, and how long revisions are kept depends on the plan you choose.

Inviting other ClickUp users

During the onboarding flow of ClickUp, you choose which workspaces you want to back up. Once the initial backup is started, we can back up all data that your ClickUp account has access to. This means that any private spaces, folders or lists that you don’t have access to, will not be included in the scope of the backup. You can solve this by inviting other team members to your account. 

1. In ProBackup, go to Settings > Users.
2. Click on Invite Team Member and confirm the popup.

Each invited team member needs to create their own ProBackup account and authorize ProBackup to their ClickUp account. Once they’ve done this, then their personal spaces, folders and lists will be added to the backup scope. 

In short: to back up Asana, connect a backup tool such as ProBackup to your account via OAuth — setup takes about three minutes. Your projects, tasks, comments, custom fields and attachments are then copied automatically every 24 hours to independent storage, and any item can be restored to a previous date in one click.

Asana is a leading work management platform for human and AI coordination. Whether it's managing strategic initiatives, cross-functional programs, or company-wide goals, Asana helps business bring clarity to complexity. While you rightfully trust cloud apps like Asana to be secure and reliable, managing your business's critical data on any single platform opens the door to potential risks. 

Using Asana to manage your business can expose your team to issues such as accidental data deletion from human error, malicious actions by disgruntled employees, or data loss due to technical glitches and downtime. Losing an important Asana task or project can set your business back hours, or even days.

To gain peace of mind and protect your workflow, implementing an automated backup solution is essential. This guide will walk you through setting up a daily, automated backup for your Asana account using ProBackup.

Part 1: Create a ProBackup Account

Getting started is easy and comes with a 7-day free trial.

1. Visit the ProBackup for Asana page by navigating to https://www.probackup.io/backup/asana
2. Click on the Start free 7 day trial button.
3. Select Asana as the app you would like to back up and click Continue
4. Fill in your email, first name, and last name, then click Continue.‍
5. Verify your email address by following the instructions sent to your inbox.

Part 2: Connect Asana and Start Your First Backup

Once your ProBackup account is created and verified, you can connect your Asana account. 

We recommend that you sign in to the right Asana account first, before connecting your account. 

1. In ProBackup, click on Sign in with Asana. This will redirect you to Asana to authorize the connection. If you are not signed in to Asana, then you will have to sign in first. 

2. On the Asana authorization page, click on Allow. 

3. On the next step of the onboarding wizard, select the workspaces you would like to back up.
4. Click on Start backup to start your first backup.

What Happens Next?

After you confirm, the initial backup of your selected Asana workspaces will begin automatically. Our backup app will fetch all relevant data types such as projects, tasks, comments, files and custom fields. Depending on the size of your Asana account, the initial backup can take up to a few hours. You will be notified by email as soon as the first backup is complete.

Click on Go to Asana to view the projects that are already backed up. 

That’s it! Your Asana account is now protected with daily automated backups, ensuring your data is safe and easily restorable when you need it most.

Still evaluating backup tools? See how ProBackup compares to Skyvia for Asana.

For a feature-by-feature view against a Microsoft 365-oriented alternative, read ProBackup versus FluentPro for Asana.

Inviting other Asana users

During the onboarding flow of Asana, you choose which workspaces you want to back up. Once the initial backup is started, we can back up all data that your Asana account has access to. This means that any workspaces or private projects that you don’t have access to, will not be included in the scope of the backup. You can solve this by inviting other team members to your account. 

1. In ProBackup, go to Settings > Users.
2. Click on Invite Team Member and confirm the popup.

Each invited team member needs to create their own ProBackup account and authorize ProBackup to their Asana account. Once they’ve done this, then their added workspace and private projects will be added to the backup scope. 

In short: to back up monday.com, connect a backup app such as ProBackup via OAuth or the monday.com marketplace. Your boards, items, updates, columns, files and WorkDocs are then copied automatically every 24 hours to storage outside monday.com, and any item or board can be restored to a previous date in one click.

monday.com is a best-in-class productivity platform that allows teams to create customizable workflows to manage projects, tasks, and processes. While you rightfully trust cloud apps like monday.com to be secure and reliable, managing your business's critical data on any single platform opens the door to potential risks. 

Using monday.com to manage your business can expose your team to issues such as accidental data deletion from human error, malicious actions by disgruntled employees, or data loss due to technical glitches and downtime. Losing an important monday.com board or WorkDow can set your business back hours, or even days.

To gain peace of mind and protect your work, implementing an automated backup solution is essential. This guide will walk you through setting up a daily, automated backup for your monday.com account using ProBackup.

Part 1: Create a ProBackup Account

Getting started is easy and comes with a 7-day free trial.

1. Visit the ProBackup for monday.com page by navigating to https://www.probackup.io/backup/monday-com
2. Click on the Start free 7 day trial button.
3. Select monday.com as the app you would like to back up and click Continue
4. Fill in your email, first name, and last name, then click Continue.

5. Verify your email address by following the instructions sent to your inbox.

Part 2: Connect monday.com and Start Your First Backup

Once your ProBackup account is created and verified, you can connect your monday.com account. 

We recommend that you sign in to the right monday.com account first, before connecting your account. 

1. In ProBackup, click on Sign in with monday.com. This will redirect you to monday.com to authorize the connection. If you are not signed in to monday.com, then you will have to sign in first. 

2. On the monday.com authorization page, scroll down and click on Authorize

‍

3. On the next step of the onboarding wizard, select the workspaces you would like to back up.

4. Click on Start Backup to start your first backup.

What Happens Next?

After you confirm, the initial backup of your selected monday.com workspaces will begin automatically. Our backup app will fetch all relevant data types such as items, files, comments, fields and WorkDocs. Depending on the size of your monday.com account, the initial backup can take up to a few hours. You will be notified by email as soon as the first backup is complete.

Click on Go to monday.com to view the boards that are already backed up. 

That’s it! Your monday.com account is now protected with daily automated backups, ensuring your data is safe and easily restorable when you need it most — which matters once you know what monday.com cannot restore natively.

Still evaluating backup tools? See how ProBackup compares to Rewind for monday.com.

Version history runs from six months to unlimited, so check the revision retention on each plan before you choose one.

Inviting other monday.com users

During the onboarding flow of monday.com, you choose which workspaces you want to back up. Once the initial backup is started, we can back up all data that your monday.com account has access to. This means that any workspaces or private boards that you don’t have access to, will not be included in the scope of the backup. You can solve this by inviting other team members to your account. 

1. In ProBackup, go to Settings > Users.
2. Click on Invite Team Member and confirm the popup.

Each invited team member needs to create their own ProBackup account and authorize ProBackup to their monday.com account. Once they’ve done this, then the additional workspaces and their private boards will be added to the backup scope. 

In short: Slack's free plan only shows the last 90 days of messages and files and permanently deletes anything older than a year. A workspace export is a one-off JSON dump, not a backup. To back up Slack, connect ProBackup via OAuth: it snapshots channels, messages, threads, files and the connected user's DMs every 24 hours and restores them back into Slack.

Slack is where decisions get made and context lives. It is also where that context quietly disappears: a channel is deleted, an admin removes a departing user's messages, or a free workspace ages out a year of history. This guide covers what Slack keeps, what an export gives you, what the Slack API lets a backup tool capture, and how to set up automated daily backups.

What Slack keeps on the free plan (checked 16 September 2026)

Slack's help article Usage limits for free workspaces sets two rules for free workspaces:

• Members can access messages and files from the last 90 days. Once a workspace reaches that window, Slack starts hiding messages and files older than 90 days.
• Messages and files more than one year old are permanently deleted.

Hidden content comes back if the workspace upgrades to a paid plan, but only until the one-year mark. After that no plan change or support request brings it back. These free-plan history limits are the clearest illustration of why a SaaS recycle bin will not save you.

Paid plans remove the history limit, not the other loss scenarios. Deleting a message is immediate and deleting a channel removes every message and file in it. Slack's own retention policies (Business+ and Enterprise) exist to delete data on a schedule, which is the opposite of a backup.

Export vs backup: they are not the same thing

Slack lets workspace owners and admins export data from Settings & administration > Workspace settings > Import/export data. The help article Export your workspace data (checked 16 September 2026) sets the scope:

An export is useful for a legal hold or a migration. It is not a backup, for four reasons:

1. It is manual. Someone has to remember to run it, and that lapses.
2. It is one point in time. An export taken in March says nothing about a message deleted in June.
3. It is partial on most plans. Private channels and DMs are excluded on Free and Pro, and file links are not files; once a file is deleted in Slack, the link is dead.
4. It is not restorable. A folder of JSON is readable by a developer, not by the operations lead who needs a thread back in Slack this afternoon.

A backup is an automated, versioned, independent copy you can search and restore from. Slack does not offer one, so the job falls to you.

What the Slack API exposes to ProBackup

ProBackup backs up through Slack's public API, so its scope is exactly the API's scope. According to the support article What data is backed up for Slack? (checked 16 September 2026), each daily snapshot captures:

• Users: the member directory of the workspace.
• Channels: public channels, and private channels the connected user belongs to.
• Messages: every message in those channels, including edits captured as new revisions.
• Threads: thread replies, up to 1,000 messages per thread.
• Attachments: files and images shared in channels and threads, stored as the files themselves rather than links. There is no attachment size limit.
• Direct messages: DMs the connected user is part of.

Not backed up, because the API does not expose it: direct messages between other users, private channels the connected user cannot see, group membership and permissions, and Slack Workflows. ProBackup's rule is simple: it can only back up what the connected user can access. Connect an admin account with broad channel membership, or add more than one team member's account to the backup, to widen coverage.

One general limit applies across all ProBackup platforms: text fields are captured up to the first 2,000 characters.

How to back up Slack with ProBackup

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account. Setting it up for Slack takes a few minutes:

1. Start a trial. Go to app.probackup.io/onboarding, choose Slack and create your account. The 7-day trial needs no credit card.
2. Connect Slack via OAuth. Click Connect Slack and authorise the ProBackup app with a Slack user that can see the channels you want protected. ProBackup never stores your Slack password; it holds an OAuth token you can revoke from Slack at any time.
3. Choose the scope. Confirm the workspace. Everything the connected user can access in that workspace is in scope; add further users if you need their private channels and DMs covered.
4. Wait for the first snapshot. The first snapshot completes within 24 hours (large workspaces take longer to pull) and you receive an email when it is done. From then on ProBackup takes a new snapshot every 24 hours, with no scheduling required.
5. Optional: turn on Smart Alerts (Pro and Premium plans) to be notified of unusual changes between snapshots, so a mass deletion is noticed in hours rather than months.

Each snapshot is stored as JSON and files on AWS S3, encrypted with AES-256 at rest and TLS in transit, in one of nine AWS regions you select at signup. ProBackup is SOC 2 Type II certified (May 2025) and GDPR compliant; two-factor authentication is available on every plan and SSO on Premium. You can also sync backups to your own Google Drive (Pro and Premium plans) for a second copy.

Restoring Slack data

Restore is where a backup earns its keep. From the ProBackup vault you browse channels by snapshot date, use Global Search (unlimited on Pro and Premium; 3 free uses per month on Plus) to find a message by keyword, and restore at the level you need with granular restore:

• A single message. Restored as a new message in the original channel; its thread replies and attached files come back with it.
• A thread or a set of messages. Select multiple items and restore them in one action.
• A whole channel. Restore a deleted channel's message history from any snapshot in your retention window.
• Files. Download an attachment directly, or restore it alongside its message.

Restores to Slack create copies rather than overwriting, so nothing in the live workspace is touched. You can also export any channel or snapshot as XLSX, or bulk-download attachments (Premium). Version history is 6 months on Plus, 2 years on Pro and unlimited on Premium; plans start at $25 per month, billed yearly, and one licence covers the whole workspace.

Best practices for Slack backups

• Decide who the connected user is. Coverage follows that account's channel membership; an admin who sits in the channels that matter is the right choice.
• Match retention to obligations. If a regulator or contract expects communication records for years, pick a plan whose history covers that period.
• Treat DMs deliberately. Only the connected user's DMs are captured. Move decisions into channels, or add those users to the backup.
• Test a restore each quarter. A backup you have never restored from is an assumption, not a control.
• Mind privacy. Chat is personal data. Limit who can open the vault (invited users can be scoped to view, export or restore) and record ProBackup as a processor.

FAQ

Does Slack back up my messages? Slack keeps its own infrastructure backups to recover from its failures, not to restore your deleted messages. On the free plan, messages and files older than 90 days are hidden and anything older than a year is permanently deleted (checked 16 September 2026).

Can I back up private channels and direct messages? Yes, for any private channel or DM the connected user is part of. Slack's API does not expose other users' DMs or channels the connected user cannot see, so add more users to the backup to widen coverage.

Is a Slack export a backup? No. It is a manual, point-in-time JSON dump that includes only public channels on Free and Pro plans and file links rather than files. A backup runs automatically, keeps versions and lets you restore into Slack.

How often does ProBackup back up Slack? Every 24 hours, automatically, with no scheduling required. Each snapshot is stored encrypted in the AWS region you chose at signup, and you can restore from any snapshot within your plan's version history.

Start backing up Slack with a free 7-day trial.

In short: to back up Trello, connect a backup app such as ProBackup to your workspace via OAuth. Your boards, lists, cards, checklists, comments and attachments are then copied automatically every 24 hours to storage outside Trello, and a deleted card — or an entire board — can be restored from any snapshot in one click.

Trello is a powerful, visual collaboration tool that uses boards, cards and lists to help teams and businesses organize and prioritize their projects and collaborate effictively.

As Trello can be used for a wide range of projects, from simple to-do lists to complex workflows, it's a popular choice for many businesses across all verticals. While you rightfully trust cloud apps like Trello to be secure and reliable, managing your team's work in one cloud app opens the door to potential risks. It can expose your team to issues such as accidental data deletion from human error, malicious actions by disgruntled employees, or data loss due to technical glitches and downtime. Losing an important Trello card or board can set your business back hours, or even days.

To gain peace of mind and protect your work, implementing an automated backup solution is essential. This guide will walk you through setting up a daily, automated backup for your Trello boards using ProBackup.

Part 1: Create a ProBackup Account

Getting started is easy and comes with a 7-day free trial.

1. Visit the ProBackup for Trello page by navigating to https://www.probackup.io/backup/trello
2. Click on the Start free 7 day trial button.
3. Select Trello as the app you would like to back up and click Continue
4. Fill in your email, first name, and last name, then click Continue.‍
5. Verify your email address by following the instructions sent to your inbox.

Part 2: Connect Trello and Start Your First Backup

Once your ProBackup account is created and verified, you can connect your Trello account. 

We recommend that you sign in to the right Trello account first, before connecting your account. 

1. In ProBackup, click on Sign in with Trello. This will redirect you to Trello to authorize the connection. If you are not signed in to Trello, then you will have to sign in first. 

2. On the Trello authorization page, scroll down and click on Allow.

3. On the next step of the onboarding wizard, select the workspaces you would like to back up.
4. Click on Start Backup to start your first backup.

What Happens Next?

After you confirm, the initial backup of your selected Trello workspaces will begin automatically. Our backup app will fetch all relevant data types such as cards, files, comments and check lists. Depending on the size of your Trello account, the initial backup can take up to a few hours. You will be notified by email as soon as the first backup is complete.

In the meantime, you can click on Go to Trello to view the cards that are already backed up. 

That’s it! Your Trello account is now protected with daily automated backups, ensuring your data is safe and easily restorable when you need it most — which counts for a lot, given why Trello has no trash to fall back on.

Still evaluating backup tools? See how ProBackup compares to BackupLABS for Trello.

It is also worth reading our side-by-side look at ProBackup versus Rewind for Trello.

Inviting other Trello users

During the onboarding flow of Trello, you choose which workspaces you want to back up. Once the initial backup is started, we can back up all data that your Trello account has access to. This means that any workspaces or private boards that you don’t have access to, will not be included in the scope of the backup. You can solve this by inviting other team members to your account. 

1. In ProBackup, go to Settings > Users.
2. Click on Invite Team Member and confirm the popup.

Each invited team member needs to create their own ProBackup account and authorize ProBackup to their Trello account. Once they’ve done this, then their workspaces and personal boards will be added to the backup scope.