Hello, is there a way to download everything in coda for a backup? The only option I’m really finding is to print and save as a PDF. Thanks!
1 Like
This is a complicated topic, but you might start here for some insights.
Many thanks, the export data function is what I was looking for.
We would like to ensure an easy process for daily backups. Is there an official or friendly way to automate backups?
@BenLee are there plans to add an explicit backup endpoint to the API? Or release some client tool that supports a backup command?
Coda is a cloud service and not a file that you can run locally. For this reason, there isn’t really a backup per doc that’s downloadable and usable in an easy way for typical backup purposes. We do have an account data download in your Account Settings that abides by all GDPR rules in that you have a right to your data, but I don’t think this is what you’re looking for here.
If it’s a matter of needing timestamped info on a daily basis, I’ve used emails with the Gmail pack to record data.
I should add that we have a robust backup system. Should you need to refer to a previous version, you can check the version history of a doc and create a doc copy from there. These are snapshots taken at that moment in time.
Thanks @BenLee. I mean simply to maintain a dump of all data in a way that is not tied to Coda, in case we need to migrate it or re-import it into Coda, for worst-case scenarios:
- Coda goes out of business, or shutdown for whatever reason.
- Coda loses all its backups or has some data corruption issue that causes our documents not to load, go missing, or otherwise not function properly.
- We choose to use a different tool.
I’ve experienced issues like this with platforms like DropBox, Synology Cloud, GDrive so they are not theoretical. It really doesn’t have much to do on whether it is cloud based or not, even if Coda was a local server with local files, we would need to ensure we can backup the data in a readable way for recovery and migration options (e.g. if the data is binary packed or encrypted by the local process).
Multiple, decoupled backups are a must for business data, and a way to fairly easily create them on an automatic basis is super important.
The account data download is a start, however a) it can’t be automated AFAIK and b) yes the format leaves something to be desired, and I don’t know what it is missing.
For my company in particular we would want to at least make sure all source table data (not views) is backed up in some reasonable format (csv at a minimum, possibly json if it solves issues with type data complexity which I believe it would…). It would be good to have section text and everything else of course. I mean really I think coda should aim for full export + import support eventually, but I realize this requires proper versioning and backwards/migration support on the imports.
What do you suggest or what is Coda’s plan for this? I haven’t tried the gmail pack section sending, but sounds pretty cludgy.
@Bill_French you have mentioned some local process you use and it’s great you have that in place, but it does sound quite complicated (stack: gmail + gdrive + some email accumulator thing + some custom client tool to use API for json table data? it seems).
@BenLee this seems like this is something Coda should implement either in the API or as a provided client tool.
Edit - something to consider I guess for the API goals - that it should allow the user to obtain a full state of their workspace, either with a specific export endpoint, or by using the various GET requests to fetch all needed data for a full state.
2 Likes
You are quite right to plan for whatever may come up. My previous work was in various outdoor industries taking people hiking or on other adventures and the best thing to have in your backpack is a first aid kit you never use. Good to have even if you most likely don’t need it.
We don’t have an export feature, and that is something noted and discussed, but the API should offer ways to export data to a pretty reasonable degree that can be a rolling backup instead of a full backup taken everyday.
Again, for myself, It’s emailing a table when I need to mostly because it has a verified timestamp. My needs were along the lines of proving what hours were submitted for work, so an uneditable email was better than a CSV file in this case.
1 Like
Thanks @BenLee - yea definitely talking just-in-case scenarios here - I sure hope we stay with the tool indefinitely and that you never experience any issues there at Coda =)
Regarding the rolling backup - is this because we would perhaps hit call rate limits when attempting to do a full export on a larger project using the API?
I’m not an API expert by any means, but my hunch is that it’ll be much easier to write something that updates a G-Sheet verses something that creates a new sheet, uploads data, and saves everyday.
Again, I’m no expert here, just stating what I’d look to start with and where I think you might find more examples to work from.
Definitely don’t hesitate to check out our Developers Central category and ask for tips there as well!
Sorry for the long rant on a Friday.
This is a very key point.
Any person or company that chooses a SaaS product is fundamentally placing their data into a fiduciary trust with the SaaS tool provider because the application logic is never actually conveyed to the licensee. Licensees have only a limited right to circulate their data - i.e., blending it with Coda - to exact specific benefits in exchange for a monthly fee. That’s it; that’s all you’ve purchased.
Given this very simple business model, each party have a few basic rights and responsibilities. This is not intended to be a legal position per-se because I don’t know crap about the law. But these points are reasonable and customary in all SaaS platforms.
In my view…
-
The SaaS provider has an obligation to sustain the app along with the data you’ve blended into it. Coda does this through managing a collection of services that provide reasonable backup and restoration options in the context of the application. If they fail at this requirement, your remedy is to not choose it as a place to put your data.
-
SaaS providers generally must make it possible to access and preserve your data independent of the product itself. It has no obligation to preserve or provide your data in a format that enables you to enjoy the benefits of the application itself, or the benefits of any other application.
-
Consumers of SaaS products have an obligation to create and manage each their own backup and restoration strategies. Today, it is possible to stitch together a relatively effective preservation of data. It’s not ideal and it comes with some technical challenges, but it is certainly possible.
It is also in Coda’s best interest to do these things well and by all measures they are meeting these obligations for the most part. It is also in every consumer’s best interest to perform their own obligations well.
This is a rational business requirement, but it is generally not in the realm of a SaaS provider’s cone of responsibility which ends at the point where you can access and extract 100% of the data.
Migration is not Coda’s responsibility (nor should it ever be). Re-importing data is also not in Coda’s cone of obligations. But these are features that might compel users to buy in more easily; I’m not debating the benefits of doing more than the minimum low bar of data preservation. This is a free-market issue best decided by – wait for it – the free market. ;-).
Desired by whom or what exactly?
You want more human-friendly formatting of exported data but you also want full re-import capabilities. Machines want data they can read and understand. Humans want something entirely different.
I don’t think this is their obligation. Asking for a snapshot of a workspace suggests exportation of application-level knowledge, app schema and settings, and overall workspace organization. This is not something I would encourage any SaaS provider to do and this appears to be an overreach.
Um, that’s what they currently offer. But, you are oversimplifying the nature of this beast by wrapping it all up in a GET request to fetch all needed data for a full state.
The API is adequate-enough to get all table data. You can build a reliable and timely system that always captures the latest snapshots. You are also free to create an incremental backup process which optimizes the process to a degree. When events and webhooks are ultimately added, you’ll be able to create a real-time reflection of your data without performing a single GET request.
What About Your Business Logic?
Show of hands, who has built a Coda solution without a single formula? Anyone? I didn’t think so.
It seems that y’all are concerned with data preservation but not a single bead of sweat concerning arguably the most important asset - the IP in your Coda solution.
Coda gets an F for this aspect of preservation. But not because they don’t do it; rather - because they don’t provide an API into the underlying elements of a Coda solution which is actually what makes it a usable “app”. If anything – and the irony doesn’t escape me – we should all be using a Coda doc to capture every formula, critical formatting configurations, and the entire data model, relationships, and schema. As soon as the API is complete, this will become an aftermarket tool. But again - this is not Coda’s responsibility.
Hi @Bill_French , thanks for the insights as always.
I agree on most points but want to clarify I wasn’t asking for both human readable and computer-friendly and I realize there is no natural format here, simply different formats and structures for different backup use cases. I was mostly asking what Coda’s plans were here - is backup a priority for them, or as it seems now, mostly a consequence of having a GDPR export option and an API that allows access to some level of data (I haven’t tried or reviewed its surface).
Interestingly Asana appears to also lack a backup solution other than use of API (although I haven’t searched much). IMO backup support is more important for Coda users, where people are tempted to put much more of their overall company data into, e.g. financial, knowledge base, etc.
I think your point about the actual IP we are creating in the product is absolutely massive. Now a few weeks in with Coda, I realize how much customization, design and formula work has been done to create a workflow that works well for a particular use case - but I don’t know of a way to extract, store, or otherwise personally own the data for this work. Your suggestion to store this in a coda doc made me smile. There is a lot of value in this data - I wonder if Coda would make exposing this a priority.
Okay - that’s a fine request, but you should provide an example of these different formats you’d like to see because the term “format” can mean just about anything. In the context of backups, the norm [historically] has been CSV. JSON is becoming pervasive. What format did you have in mind and what backup use cases? I’m curious only in the sense that formats conditioned on specific use cases could be very broad in scope.
Yep - and this is common practice for all SaaS providers; even those with greater platform maturity. This is why I’m suggesting that data extraction via APIs is the only likely remedy.
Well, this is where Codans have an opportunity to leapfrog competitors. If they exposed access to every aspect of a Coda “solution” - all its data, formulas, filters, business process and logic - such that it could be shared with any other user and restored into any Coda account or printed, this would provide a pathway to a powerful approach to comprehensive IP protection.
Less-informed Codans would simply say - “We have that, it’s called Make a Copy”. 
Anyone who says this - Codan or otherwise - does not understand the envelope of risk.
Until we have the ability to deeply scrape a solution, the only way to defend loss of this [fleeting] IP is to meticulously document every formula, cell formatting, filter, view, etc. And to be clear, I’m not suggesting Coda build such a deep scraping feature; rather - simply expose it all through the API and let the free-after-market build tools to meet backup/restore/documentation use cases (as you have intimated).
1 Like
I agree with the first of these points. As for the second (about the format of the download file), I’m more satisfied than Ed is.
.
Re Ed’s point a (automating the backup download)
The excellent service that I use to host solutions for my FileMaker clients (a place called FileMaker Hosting Pros) makes daily backups and retains them for a while, in case I want to download one. But it also allows me to setup automatic downloads of backup files to my Dropbox account. This is an excellent option. They build this into their pricing structure, but I understand that this would increase traffic on Coda’s servers and if Coda needed to charge a little extra for this option, I’d be willing to pay for it. I should add: I’ve not played with Coda’s integration with Dropbox yet. For all I know, this may be something I can do myself. (That would be awesome.)
.
Re Ed’s point b (limitations in the format of the data dump)
I just tried the Coda “download my data” feature. Works much like Google’s Takeout feature. For those who haven’t tried it, the download file is named coda-data-export.zip and it contains mostly text files with meaningless names, and a couple of JSON files.
My only complaint is with the name of the output file. It really needs to be timestamped: not coda-data-export.zip but 20200131-coda-export.zip.
Otherwise, all things considered, I think they’ve done a pretty good job.
.
For those who have not tried the Coda export yet…
The text files have meaningless names representing (I assume) doc IDs. But one of the JSON files (“doc-manifest.json”) is an index that identifies which of your Coda docs each text file comes from. For example, line 8 of the manifest for my download reads
8 "MgU2ByUPSV": "FileMaker alternatives"
where “FileMaker alternatives” is my name for one of my Coda docs. So you can translate the meaningless names into something meaningful pretty easily. Well done there.
When I open file MgU2ByUPSV.txt up in a text editor like Sublime Text, what I see was surprising but, if I’m honest, kind of impressive. It’s an entirely readable plain-text rendition of my entire document. Entirely readable! That is, I can read not only any normal text that I’d entered on the canvas but can also see the data in any tables and/or views. The parts of this output file that represent data in a table are tab-delimited. I was able to copy a table, paste into Sublime Text, save as “alternatives.tab”, then open in another database app without a problem.
The other JSON file in the download zip file is a JSON list of my users. Perfect.
Every technological decision “leaves something to be desired”, at least that’s my experience. But all things considered, Coda’s formatting of the data dump strikes me as a pretty intelligent compromise. It does remind me that I should make sure in future to have one section of each doc that contains NOTHING or almost nothing but an unfiltered data table (which was clear to me even before I tried this export process).
It might be nice if Coda offered alternative forms of download: CSV or JSON output of base tables (not views). But if they have to limit us to one option, I think what they’ve done is a pretty good compromise.
My two cents.
William
3 Likes
And from this dump, anyone is free to build their own localized process or programmatic interpretation of the content to effectuate pretty much any imaginable reutilization of the data and text. But, as you point out, it is already in a format that is inherently parseable and reusable should a crisis hit or you decide you need to escape from Coda.
There are some missing pieces I would like to see added to the dump (i.e., formulas, etc) but that is probably not a stretch for Coda - all in due time hopefully.
I’ve just requested the “Export my data”. Will take a closer look but that sounds like its good for disaster recovery.
From what I understand right now, the export cannot be re-imported to Coda?
Adding my 2cents on backups. Miro have a nice “board backup” feature. doc link here.
This works well, it generates a compressed archive of a board and allows for easy restore/cloning of boards from a offline backup.
I opened the miro .rtb archive with 7-zip and have attached a screenshot of the contents. It contains the assets and configuration. So full backup of the board, and as mentioned it can be restored to the miro platform.
I can post this in the suggestion box if requested.
1 Like