As we know Asana can store attachments from:
- Google Drive
I would be interested in who is using what. I just tried my free Dropbox as an attachment, and editing in Word and re-saving worked fine to update the attachment to Asana. I know a feature request is to be able to Save From Computer, edit in program and re-save seamlessly. One of the employees I consult with asked a pretty good questions. “If I load everything in Asana instead of saving it on the network and something happens to Asana do I loose all my documents”. I need a good answer to this. I also think that Microsoft OneDrive would be a good addition.
@JCarl In the context of data storage, I’d say our Dropbox, Box, and Google Drive integrations are a great option.
Now, specifically regarding the “if something happens to Asana” question. Due to the volume of businesses we support, we know it is imperative that we treat your data respectfully and that means we take stability and security very seriously. Our database is replicated synchronously so that we can quickly recover from a database failure. As an extra precaution, we take regular snapshots of the database and securely move them to a separate data center so that we can restore them elsewhere as needed, even in the event of a regional Amazon failure. You can read more about our security here: Asana Trust Center | SafeBase
Also, within premium organizations, we allow admins to export all data in their Organization in case companies want to retain a full copy of their Asana instance.
I hope that helps!
Does that include attachments also that are uploaded?
@JCarl I was going to answer this based on my knowledge, but I wouldn’t want to lead you wrong, so I took a look at our codebase. When you attach a file, we wrap that attachment in a URL - this is for the purpose of doing some workflow activities, like generating thumbnails for images in comments or mantaining access control rules. Behind the request for the file, though, we delegate storage responsibility to the original location of the attachment (i.e. Dropbox for dropbox-attached files, Google Drive for documents and drive attachments, and so on) - so your files should in this case be accessible from Asana as long as we can access it, and carry the persistence guarantees that the original locations give, so even if Asana were to (knock on wood) have some catastrophic data loss, the original files are unaffected for this case. That’s one reason that this is a good approach: you can access the file independently of Asana in the worst case scenario.
As far as uploaded attachments, we currently store these on Amazon S3, for which: “Amazon S3 Standard and Standard - IA are designed to provide 99.999999999% durability of objects over a given year.” So that seems pretty solid
The reason that we don’t actually advertise that we are a file storage company is because that’s not our core competency, and we do delegate this responsibility to the source backend. We could, for instance, decide to stop sending the file to s3 and that would give a different guarantee of persistence that becomes much harder to retain if we actively promise a SLA. (That being said, this is very, very unlikely: I can’t imagine the world at this time where we don’t go with s3 simply because of that super solid durability)
That being said, it’s really, really important to us to not lose our clients’ data: it’s behind security but above correctness in our internal priority scheme. We’ll take bugs over losing your data, and as a software company, you can imagine how much we focus on correct, bug-free software. It’s always, always a good idea to have a backup somewhere, but to give you a sense of the state of things now, your data is 10000000000x more secure on s3 as an uploaded attachment in Asana than on the very best hard drives based on the failure rate of high-quality hard drives.
To clarify, @MattBramlage works at Asana!
@MattBramlage , great answer