Design for recovery?

I read post " Airtable Backup & Recovery Strategies: Simply, a Nightmare" Sobering.
I come from a background in Oracle and MS Access. I loved the tools to visualize relationships and miss them in Airtable.
However, We have fairly simple contact database that is rapidly getting more complex and need to establish a better backup strategy (not just occasional downloads to Excel).
Would appreciate comments on following proposed process.

  1. setup a separate “backup” account or workspace
  2. setup zapier automation to backup to something (Excel, Sheets, “UNLY”, whatever)
  3. Setup restore process to recover from that backup set
  4. Create a “test suite” of fundamental operations (such as extracts to mailchimp)
  5. Run backup
  6. Test recover process to the “backup” workspace
  7. Run “test suite” and examine results
  8. If bad, “fix” some combination of (a) design of main worksheet (usually simplify it) or (b) backup & recovery process or © test suite
  9. Repeat steps 5-8 until tests are clean
    In principle, I think this (tedious) process would help ensure that the database design did not outrun our backup and recovery capability. At least within the scope of the test suite.
1 Like

Thanks [equally] for the sobering remarks. To be clear, that was penned a while ago but largely still accurate today. And it’s also important to realize that this issue is prevalent in many competitive platforms. It’s a thing and that thing needs to have a remedy.

I worry more about the topic of recovery than the topic of export and I appreciate your points as they focus on one aspect to attempt to discover a smart pathway for the not-so-inevitable-but-very-costly incident that is probably going to happen at some point.

This topic was solved and automatically closed 15 days after the last reply. New replies are no longer allowed.