Dropbox versions

I use a save/backup scheme that seems to fit in with what L&L generally recommends.

I save my current working project (.scriv) to my Dropbox folder, because sometimes I use my desktop Mac mini, sometimes I use my Macbook Air laptop. (Scrivener 2.6, Mac OSX 10.10.2 on both.)

My backups, set at the Prefs/Backup tab, are directed to the local drive of each of those machines and selected to “only keep 25”.

That all seems to work fine, and along with my daily Time Machine backups and weekly SuperDuper backups, I feel relatively safe. (Yes, I was careful to say “relatively”!)

My question is about Dropbox. It occurred to me that the version history Dropbox provides could be helpful in the event of a problem, or indeed simply to look up something earlier than my 25-deep backups.

Looking at my stuff via the Dropbox website, if I go down to the next level from the Project .scriv folder, there is a .scrivx file. If I right-click on that, I see an option to view Previous versions. But if I download one of those Previous versions files, it won’t open.

I’ve seen various comments here, and elsewhere on the L&L site, about problems with Dropbox and Scrivener project packages.

Does this mean that the otherwise very useful versioning facility at Dropbox is no use at all for Scrivener projects?

A Scrivener project is comprised of all the files and folders inside the scrivener project folder, not just the .scrivx file. Dropbox will handle each of those files independently so, in short, no, I’m afraid there’s no direct way to use the Dropbox versioning system to recover a consistent set of an old scrivener projects as a whole.

For more info on the Scrivener project file structure I suggest reading through Appendix E
Project Bundle Format on the manual.

This is why I send my (.zip compressed) Scrivener project backups to cloud storage. Aside from the convenience of having access to my backups from any computer, it means that I can take advantage of any versioning (such as DrobBox’s) to recover those .zip archives that have exceeded the “keep only” limit. Since such cloud sync services require a local folder on my hard drive, Time Machine backups will keep track of them nicely too, should anything happen to sync service data, and so I have no worries about something catastrophic happening at dropbox.com. If it did, I could still grab all my ZIP-compressed backups from Time Machine and put them in my Google drive folder, or Spider Oak, or whatever other sync service is available to help me maintain an offsite backup.

Note that this is only possible because archiving your backups using the built-in ZIP compression option makes all those files and folders into a single file, for purposes of recovering a project after it’s been deleted.

It’s a shame, isn’t it?

Being able to go back to a Dropbox “Previous version” of the whole project folder/package would be so nifty, if I understand correctly.

You would only need the one saved file per project (which adds a little to your Dropbox space), and Dropbox would do the work to provide old versions.

With robertdguthrie’s zip-compressed method, admirable though it is in itself, those zipped files will surely mount up and mount up, because you add a new one each time you back up (and I presume they gradually add a great deal to your Dropbox space).

The 2 GB basic free space Dropbox offers always seemed like loads when I first joined up, but it soon goes.

You can set the maximum number of backups to ‘keep’ in Scrivener, so it deletes the oldest backups to make room for the new. Since Dropbox only counts files that haven’t been deleted against your quota, you don’t lose space to files that you can nevertheless recover. The ‘versions’ of files that Dropbox keeps go back 30 days, and your backups will likely go back even further, to the tune of 30 days + age of backup when it was deleted.

If you want to keep a running history of the documents in your project, look up the various ways you can trigger snapshots, including binding that function to File->Save/CMD-S.

This is far less problematic than trying to pick out the individual files you want to restore from a project with hundreds, maybe even thousands of files. Each entry in the binder can have a nearly unlimited number of files on the disk associated with it; one file for synopsis, one for document notes, one for every snapshot. And then there’s all the metadata kept in the .scrivx file, which changes constantly whenever you add or modify documents (date added, date modified, title, position in the binder, etc…), or keywords, labels, statuses, custom metadata, references, comments, footnotes…

The technical implementation which makes Scrivener snappy and full-featured also make messing with the underlying project structure difficult and potentially disastrous.

I’m having trouble getting my head around that. Probably just me. But could you explain in a bit more detail? I’m not sure what exactly you’re saying about how Dropbox will deal with, say, a 25-only set of zipped Scriv backups.

I’m saying you can recover deleted files from Dropbox up to 30 days after they were deleted, but those files, which have been deleted but can be recovered, don’t count against your dropbox quota.

Earlier, there was regret expressed that one cannot go in and revert a file located in a project via Dropbox.com (because it’s a bad idea to manipulate parts of a project outside Scrivener). Those “versions” are under the same 30-day constraint as deleted files are. The version of your file that is 31+ days old is lost. But an automatic backup on dropbox goes back 30 days + the age of the backup when it was deleted.

So let’s say you only keep 5 backups, but you have Scrivener set to keep them in a Dropbox/ScrivBackups folder. You trigger one backup a day, every day, by shutting down Scrivener at night. That means that after 5 days, you have 5 backups, the oldest of which is five days old. On the sixth day, you shut down Scrivener and the backup process produces another backup, and then deletes that oldest backup (which is now six days old). Dropbox.com will let you restore that backup for another 30 days, making it possible to restore a backup that is 30+6 days old.

In a month’s worth of daily work, triggering a backup each and every day, you’ll end up with 5 easily obtained backups under Dropbox/ScrivBackups and 30 other backups that you can restore by going to Dropbox.com and un-deleting them. If you back up more often than once a day, there’ll be even mnore than the 30 + 5 in the hypothetical above. If you take days off, or don’t shut down Scrivener every day, there’ll be fewer backups available to be un-deleted.

My main point: You can always get to a backup that is older than 30 days old without maxing out your dropbox quota, and it’s going to be older than any dropbox “version” of any file in your project. Therefore: automatic backups are not consolation prize for not being able to restore a version… they’re better because they go back further.

Thanks for taking the time to do that, Mr Guthrie, it makes a lot more sense now to me.

And now I’m wondering about changing my backup scheme, bearing in mind what you’ve explained.

I still need my project .scriv stored in a cloud-sync’d folder, so that I can work on desktop or laptop as the need arises, and as I said, I currently use Dropbox for that.

But I think I’ll switch my backups to a Dropbox-sync’d folder, for what I now think of as The Guthrie Method.

So I’ll also move my project .scriv, to a folder sync’d to one of my other cloud accounts (I have Google Drive and Copy available).

I’m curious to know if anyone else viewing this post has thought about all this and is using such a method?

I would advise against moving your “live” .scriv project to Google Drive. It has a history of corrupting projects without any help from absent-minded Scrivener users.

Instead, I’d reverse that arrangement; keep your active projects on Dropbox, point your zip-compressed backups at google drive. By default, GD has more space anyway, so you can crank up the “keep only” backups to 25.

I didn’t think the versioning was reckoned to be as good and/or reliable on Google Drive.

I think, as Robert implies, it’s mainly a matter of which cloud services have been found by experience to have a history of corrupting unzipped Scrivener projects, and which haven’t. Unzipped Scrivener projects are in fact folders of hundreds, or potentially thousands, of individual files, very frequently updated during live use, and some cloud services seem to be able to handle this, and some don’t. As far as I remember, Google Drive is one of those which users’ experience suggests have more difficulty in doing so, and therefore greater risk of corrupting unzipped projects. Speaking for myself, the main requirement of a backup location is reliability; for me versioning is certainly desirable, but secondary.

This article summarizes the most commonly used cloud sync software caveats and provides some useful tips and tricks.

Oh, yeah, good point. I was focusing (in that moment) on the risk to your ‘live’ project when trying to keep it on Google Drive.

Having mulled over all this, my inclination now is to go as follows.

Save my main project .scriv to a folder sync’d to Dropbox. This primarily to give me cloud access from desktop or laptop as required.

Direct zipped autosave-on-close backups to another folder sync’d to Dropbox. This to provide reliable versioned, um, versions, as per Mr Guthrie’s scheme.

No great danger sync’ing both to Dropbox, I think, because I’ll have the files and folders on my desktop and laptop hard drives, too, and also on my various Time Machine and SuperDuper backups. And Dropbox does seem to be the (crossing everything crossable at this point) best cloud service.

(Also on the subject of cloud reliability, has anyone here successfully and painlessly used Copy for syncing .scrivs? I use my Copy account primarily for saving and sharing image files, because of its generous free space, and it’s been fine for that.)

I also use Cubby, which gives 5GB for free, allows you to designate any folder as a “Cubby” (including folders on external drives) rather than putting it all into one folder like Dropbox, and in my experience is just as reliable as Dropbox.

I keep my active projects in Cubbies (one for my personal stuff and one for my collaboration with a friend) and have the zipped Scrivener back-ups directed to Dropbox. I also do a complete bootable backup of my MBA (which is my primary working computer) virtually every weekend using Chronosync, which gives me a further backup of what is in my Dropbox and my Cubbies.

PM me with your email address and I’ll send you an invite if you wish — if you take it up, I get an extra GB of space.

Mr X