Definitive Answer - Scrivener and Time Capsule

Does anyone have a definitive answer on whether Time Machine/Capsule backups are reliable? I think that, if I were to answer my own question, I’d say no, based on this (and when conducting backups - since Time Machine/Time Capsule is a continual backup system - with Scrivener open.)

  • The Scrivener file I am backing up is massive (over 4 gigs, with multimedia files in it.) When I finally examined the Time Capsule backups, I was horrified to find that they varied in size from day to day, even though my Scrivener file was (logically) simply growing. Some days they were smaller, some days they were bigger. This leads me to believe that there’s something about the way Time Capsule interacts with (large?) Scrivener files that damages the integrity of the backup. I didn’t bother to attempt a restore, since it seemed obvious that restoring a Scrivener file from a backup 1/3rd the size of the original wouldn’t yield the desire result.

I have since removed the multimedia from my Scrivener master document, reducing it to a much more manageable size (165mb), since the multimedia items are static and don’t really need to be in there. At the moment, the Scrivener backups seem to be stable. Again, I have yet to restore - but if the large file backups lack integrity, than in theory, I’d surmise, the small file backups should also (potentially) suffer from the same problem. If Time Machine is at any time, in any situation, unreliable with Scrivener is open, then - as a backup system - I’d say it cannot be relied on at any time.

The solution I am currently working with, then, is with an AppleScript that quits Scrivener, then does a backup of the master Scrivener file via a sync utility (ChronoSync) to an external disc. This gives me a once-a-day backup.

My goal is transparent backups without user intervention - this is because it isn’t me using Scrivener. I am supporting a user who isn’t sophisticated (in other words, the kind of user for whom Time Machine is created for.)

I have seen these issues discussed on the boards at various times, but if a definitive answer could be give in one post, that would be quite helpful. So, here are the questions:

  • Is Scrivener, with it’s all-in-one storage scheme, fundamentally at odds with Time Machine’s constant backup system (meaning: would Time Machine’s backups made when Scrivener were open have the potential to lack integrity, depending on what was happing in/with Scrivener.)

  • Is any backup system that copies the Scrivener file while Scrivener is open (other than Scrivener’s own backup command) similarly at risk?

If this is the case, I’d consider this a major flaw in an otherwise brilliant program. Not because Scrivener doesn’t lack its own highly functional backup feature - it does - but because it is incompatible with one of the most important advantages offered by the Mac operating system. I have worked with Time Machine and panicked users extensively, and it is absolutely brilliant; it is a transparent life-saver that can recover lost files (and entire systems), often over the phone, in a matter of minutes or hours. I would also guess that - if Scrivener is not 100% safe to use with Time Machine - many users aren’t aware of this, and are relying on that element of the Mac operating system to safeguard their data. After examining my client’s previous large Scrivener file, and seeing that the backed up files varied wildly in size, it seems almost certain that the system isn’t functional with Scrivener.

As a substitute, or better, a stop-gap until the developers can find a way to make Scrivener Time Machine/Time Capsule (I keep using both terms because, perhaps, this issue may be more related to the over-the-air Time Capsule backups - though again, I’d argue that if there’s any hint of unreliability in the schema, the whole thing is flawed) compatible, I’d say that Scrivener needs a “hands-free” backup system - something that provides a real-time backup of the working Scrivener file with no user intervention, which can then be backed up by Time Machine, and which can then be restored by a Scrivener “routine” specifically designed and advertised as a “post Time Machine recovery mode.”

Scrivener is awesome - I use it myself - but as a giant repository, it needs to be fully Time Machine compatible, as other (lesser!) storehouse-type (Yojimbo, Soho Notes) programs are.

Perhaps my assumptions are wrong. I welcome having my arguments being picked apart, piece by tiny piece!!!

  • Dan

Dan: I’ve only had to resort to my time capsule backup once, when my MacBook hard drive died, and I can’t say I’ve checked every file since I restored it via TC, but everything that was supposed there apparently was back in place after I restored the contents of the old dead drive on the shiny new one via TC. good luck!

I’ve had good luck with Scriv and TM. I’ve had to restore my entire writing director and everything seems fine.

Because Scriv files are packages, it’s possible TM is only backing up what changed within that package.

Can’t say about TM with Scrivener because thankfully I haven’t lost anything there. However, when iTunes crashed out on me, yet again, I though aha yer bugger, I’m safe, I’m using Time Machine now :smiley: Only to find that TM hadn’t backed up all the important info iTunes requires :cry: .

Now, if TM can’t even backup one of it’s own stablemates properly I’d be a tad wary. I use lifeboat as an extra backup now and it appears to backup everything.

I appreciate all these answers, but I would love it if somebody from L&L could reply:

Does Scrivener’s file format work with Time Machine?

For my test it did.


  1. Create scriv project.
  2. create random content
  3. Let TM execute auto backup
  4. wait a day
  5. delete scriv file (move to other location)
  6. restore from TM
    7 diff the packages.

step 7 shows files match.

I wonder is the failures being reported are due to the backup interval being SHORTER than the time needed to complete a backup.

Just a thought.

Hi, I’m afraid my only answer is: I don’t know, as I don’t use Time Machine myself. Scrivener’s file format is a package format, which is fairly standard on OS X - RTFD is a package format, for instance. So there is nothing about the format per se that would mean it isn’t supported by Time Machine. However, there is an important difference in how RTFD editors open and save RTFD files compared to how Scrivener opens and saves .scriv files. If you open an RTFD file in TextEdit, for example, the entire RTFD file gets loaded into memory. When you save it, the RTFD file package itself gets completely overwritten by the new data. By contrast, when Scrivener opens a .scriv file, it only opens the files inside the .scriv package that it requires for that session - the information about the binder and then any text files that you open during the session. When Scrivener auto-saves, only the files inside the package that have been edited get overwritten. For a backup system looking for changes to files, this can be an important difference: if an RTFD file changes, so does all the files inside the RTFD package, so everything in it - RTFD folder and all its contents - will get backed up. If a .scriv file changes, though, only certain files within the package will have actually changed, so it will be up to the backup system how to handle this. If it decides to backup the whole package (all its contents regardless of what has changed), then everything is fine and dandy. If it only backs up the changed files, though, you would essentially have a folder with a .scriv extension containing a handful of files but not the entire project for that backup - and Scrivener would most likely not be able to open that project given that it relies on certain files being present; certainly, the project would be corrupted.

With time machine, I would have thought it would be able to put the whole project together when you went to open it, but I’m not sure. At any rates, the above issues are the main ones concerning backing up Scrivener files. This is why many users choose to back up by zipping first. (The next update automates this, allowing you to back up automatically on open or close and at given time intervals.)

Hope you helps that find out what is going wrong in your case.
All the best,

Something else to consider also is that TC backups are COMPRESSED. Since you are using multimedia then the variations of compression could cause various sizes and times on the backup.


If you have 100 Jpgs and you back them up then the compression may save about 3% of space or 0% of space depending on if the compression supports compressing a compressed item (jpg).

But take a lot of text and compress it and you may get a compression savings of 70% or higher.

So lets say on Monday you add 50 JPGS 1- PDFS and about 10 text files. The compression savings would be hardly noticed.

But now on tuesday you instead have 100 pages of text and that gets compressed. Your compression savings would be much greater making the file size actually smaller due to the amount of compression savings.


A SCR file with say 100 JPGS and 5 text files compressed then the next day 95 JPGS and 100 text files. The 95/100 could actually come out smaller due to better compression savings even though the actual file size could be almost 150% bigger than the 100/5.

If that makes any sense?