I am a very heavy Coda User since 2018. A lot of my work has been transformed by Coda for good.
In order to achieve piece of mind, I would like to save entire, quite long and complex documents. I accept that I’m gonna lose Coda powerful functionalities, but at least I would like to save raw data as it is.
Settings > advanced > export data is not feasible for me since I have a mountain of Coda data.
Some recent packs for exporting tables into csv or google spreadsheets are quite nice, but not what I am looking for
Other low-code solutions such as Notion offer very powerful and flexible exporting options of entire documents.
Although I am more than satisfied with Coda, nowadays I cannot use it at certain projects because of lack of suitable exporting options. Besides, some customers have said to me that, no matter how powerful Coda is, lack of exporting options is a total deal breaker for them. They cannot accept golden cages no matter how much gold has been used for raise them
I am pretty sure that Coda can do it better and offer options to such customers who cannot rennounce to backups
2 Likes
Just to add to what @Juan_Luis_Chulilla said, we also use Coda in our company for many different things, and some good reliable automated (that you can schedule) backup option would be good, both as export which is very important but also even as Coda format which can be imported back to Coda (in case that something goes wrong both on Coda or even on our side) so that information can be restored. For example our ERP software is backed up on our local storage every day (+ full online cloud backup that works all the time), but it gives us additional peace of mind for important and sensitive information, because cloud is good and all but it can still go wrong from time to time 
2 Likes
Indeed, and there are no simple ways to export the content in a Coda document. Tables are first-class citizens and accessible by the API, but texts are second class objects unreadable by formulas or the API.
One alternative - set up an email automation to send the documents to an inbox that serves only to process backups.
1 Like
Could you elaborate on how you would send the actual doc please ?
That’s an interesting workaround. Thing is, non-tabular parts of the page are second-class Coda citizens and thus they couldn’t be send as such, or am I wrong?
Correct - you are wrong. 
But more accurately, I’m not clear. LOL
While the API has no access to the non-tabular elements, the Email Pack apparently has some internal magic that allows non-tabular content to be transmitted via email messages. This forum thread touches on a lot of these issues. If they would expose this magic to Pack developers, a far better backup capability might be possible. Until then, a hybrid approach could be contrived in something like Google Apps Script that watches a dedicated inbox for content and then uses the Coda API to gather all tabular content, thus blending it all into some sort of unified backup schema stored in Drive, Firestore, sheets, whatever…
Reversing this process - i.e., mitigating disaster recovery - is an entirely different story.
This hackathon sheds some light on the approach. There may be some better (more recent) discussions about exporting document content via emails.
I also have used this approach to support comprehensive CRM processes. So, for example, we are able to send newsletters designed in Coda documents complete with embedded images via email. The Send button dispatches the content via email without breaking a sweat; ergo - moving document content via email is simple stuff. Parsing it at the receiving inbox is also straightforward; storing it with tabular data is also straightforward.
2 Likes
My company compliance people are also is pushing back on expanding usage of CODA because there is no suitable backup. I know it’s unexciting to think about, but serious companies have backups.
Problems
- It’s hard to do, and not schedulable.
- The CVS files that contain tables are misformatted, clearly written without intending that anyone would ever actually read them. (you should escape quotes inside a quoted field)
- There is no apparent way to reconstruct the original pages, it’s just scattered fragments of pages.
You sometimes see this sort of half-hearted attempts at export when the intent is legal “discovery”, and you are not really on the same side as the receiver of the information.
But in the case of company backup, you really do want the data to be readable, usable and ideally restorable. CODA could show it’s maturity by making a real effort at serious backup.
2 Likes
As a person who has all his eggs in one basket, this is also an interesting topic to me, and I have thought some about this.
But first, what is meant by Backup of entire docs or folders?
- There are two aspects to a Coda doc - one is the functionality, the second is the data.
- The data ranges from free form text on the one hand, to structured databases with tables of information. Bear in mind that these tables in turn can contain canvas columns, which in turn can have a mixture of structured and unstructured information.
- Functionality in turn covers a range of possibilities. Starting with formulas on the canvas, formulas in tables, which includes table relationship formulas. Buttons with formulas, both on the canvas and in columns. Automations that are triggered either by time or by events. And then packs. Packs is a biggy. Packs can be anything from simple new formulas added to the Coda Formula language, to extensive integrations with other apps like Miro, Jira, Slack, Teams, GMail and hundreds of others.
- Then there are special examples like the compose column, which mixes data and formulas in a very tightly integrated way.
- When we backup - what do we backup?
- Freeform page text is one easy topic.
- Stand alone tables is another easy topic, assuming there are no “strange” columns like compose, canvas, calculate, file, URL or emoticons.
- Formulas and buttons? Wherever they are? I am not certain how one would go about that, especially as the doc starts approaching being an app.
- Packs? Not remotely possible.
- Assuming we managed to make a back up, what do we do with that back-up? Backups without the ability to restore them are worthless.
- If the need for a backup is to protect against mistakes made in a doc, then there is there various ways to use the Coda version recovery functionality. Over and above that you can also make regular copies of docs for peace of mind to protect against yourself and rogue users.
- But if you are making “backups” to protect yourself against
a. a catastrophic failure of Coda, or
b. The need to move to a new no-code supplier
I think that you are out of luck. There is no other tool that is available to read and restore a “backup” of a Coda doc. It is not going to understand the formulas, it is DEFINITELY not going to be able to make use of the packs in your doc.
- What next? Are we up the paddle without a creek?
No, there are several paddles we can use.
- The first is to not use Coda, and by implication, not use any other no code tool either.
- Make copies of certain types of information - for example policy and procedure documents, bearing in mind that any hyperlinking and cross-referencing you have done will be lost. But you can always import them into Word or Google Docs. Tables can be exported using various export functions already available in Coda
- We can hope for, or commission a pack-like function in say Notion, so that a Coda doc can be moved to Notion. And there is precedent for that, there is a Coda pack that will allow you to import a Notion document into Coda.
But underlying all of the above is loosing the Coda functionality, the whole reason why we implemented Coda in the first place
- Lets approach this from a different perspective. Is Coda the only SaaS that cannot be “backed” up?
- What about Google Photos, Gmail, OneDrive and Google Drive. Slack, Monday.com? Haddop, and other data lakes.
- What about your bank account?
I think that this is not a uniquely Coda proposition, but a growing societal problem. Maybe the world never suffers a calamity. Or maybe a sunflare will wipe out electronics and electricity, half the world starve and the survivors move back to caves.
And as always, reality will be somewhere between the extremes. We trust hospitals to have redundancy in service, FEMA to have disaster recovery plans, and so on.
We should consider the impact of loosing a Coda doc, or loosing Coda as a whole. But I do not think that a “back up” in the sense of making a copy of an Office doc, or an SQL database is an option in our brave new world.
BUT, it’s just a ramble,
Rambling Pete
3 Likes
That’s a pretty good ramble! 
I feel there are still concrete steps Coda could take
to improve:
-
Making the backup operation schedulable would be nice.
You could use the wee hours when servers are typically
unloaded.
-
Assure that the file formats you use are effectively
implemented: CSV files correctly formatted, character
elements like quote marks and line endings are escaped
properly, and JSON files are valid, etc.
-
Offer some guidance about how the fragments relate to
one another, so that the poor schlep who has to reconstruct
the wiki on some other service has some hope of partial
success.
The resulting backup won’t be perfect, programmable
elements won’t work, packs are out, but if the text,
pictures, links and table data are recoverable, that’s
pretty darn good.
Maybe export to markdown syntax? That would serve to
tie together a serviceable version of the wiki. It would
be a nontrivial effort for sure, but it would add
real value for many companies.
Markdown export might be similar in complexity to PDF
export. Easier because formatting is light, harder
because you want page links to work.
It’s true that poor data safety is becoming more common.
Services often
- provide poor or no backup
- do not successfully secure the data they hold from hackers
- outright sell the data they hold for profit
- sell the whole company to a holder who just burns it down
- simply go out of business taking the data with them
No service likes to think that they themselves could ever
fall prey to these things. But wise customers know one or
more of their services will fall at some point. They know that
restoring from backup is a WHEN not an IF.
These sad facts are reasons to offer good backup, not reasons
to skip it.
Because the market is generally unsafe, Companies
will tend to entrust their operations to Services that are safer.
