It seems like there is a pattern of computer crashes and lost work in a lot of the posts here asking for help. I’m wondering if there’s an easy way to describe how a Scrivener project is constructed, so users can plan their projects and be prepared to recover easily.
Here’s my shot at it:
One way to think about a Scrivener project is to remember that the the Binder is “just” a sophisticated XML file that points to the actual text files. If your computer crashes while Scrivener is open, the only files that could get corrupted are the XML file and whatever text file is open at the time. Knowing that, points to a strategy of breaking down your working text into smaller files that are put back together during the Compile process. That way, only a relatively smaller amount of text is at risk during a computer crash. And finally, setting up the backups so that a manual save also creates a Dropbox backup will create multiple fallbacks.
I think that’s a clear basic description, and good advice. Specifically WRT setting up backups, one of the simplest things one can do is to check the Saving settings in Tools > Options > General. “Save after period of inactivity” should be set to a pretty low value, so that the program is automatically saving your work every few seconds. I have mine set to 15 seconds; the default may be 2 seconds, but I found that that didn’t give me time to think better of a thing before it was saved. IAC, if the computer crashed, only my last 15 seconds of work would be lost. It could be, of course, that those 15 seconds will have produced the most insightful and beautifully formed prose of the past hundred years; but that seems unlikely.
Correct me if I’m wrong, but I think that Tools>Options>General>Saving is not creating a backup. It’s just saving the XML file and the currently open RTF file after the set time period. Which means that a computer crash will (most likely) corrupt both if they are still open. That’s the common thread in a lot of these posts. A lot of people thought the Saving setting was making a backup, but it doesn’t. It just saves what’s open at the time. Tools>Options>Backup is the menu system to get an actual backup.
Saving does not create a backup, but saving often and breaking down your project into smaller files will both reduce the amount of material at risk in a crash or other failure.
Thanks Tom, and Katherine. I understand that a save is not as good as a backup. But my understanding is that the text is safely saved onto disk, not just hanging around in volatile memory. Now what happens to an open project (i.e., the XML file that is the “one ring to bind them all”) in a crash I do not know.
No.
The time is about inactivity, not the time span between saves. So in your case you need to sit still and don’t write for 15 seconds before Scrivener saves your work. This means that if you write for a long time, 30-40 minutes or even an hour, and only pause for 5-10 seconds now and then, Scrivener will never save during that time. As soon as you do something, hit a key or work with the mouse/touch pad, the timer is reset to zero again.
They are two different things. Save is what Scrivener does with your active project whenever you are inactive for a few seconds (or as in your case 15 seconds) whereas backups are complete copies of the previous version of your project. The backups save you when your live, active project breaks down, or if you make some changes that screw things up (moving around in the Binder in a way that was no good), etc.
So, you need a short time frame (2-5 seconds) for the automatic Save function, AND Backup on project close to another location, nowhere near where you keep your live project.
Sorry–failed to understand my own process! You’re quite right; but the way I work I’ll essentially never work for 30 minutes without a 15-second pause to think somewhere. Plus I tend to be pretty compulsive about manual saves (a habit picked up from my early days with computers when the power went out and I lost an hour’s work). Still, 15 seconds may be extreme; I may need to scale that back.
The thing is, if that XML file gets corrupted, your project is hosed. If you don’t have a viable backup, then you’ve probably got to rebuild the thing by creating a new project, importing the rtf’s into the new project, and recreating your binder and metadata from scratch. What a pain in the ass.
While I understand the reasoning behind this approach, personally my goal is to avoid ever being in the position where I would need to resassemble a project from rtf docs. I don’t believe there is much to be gained, from a project restoration perspective, by breaking your project into smaller chunks. (While I typically do break my projects into smaller chunks, that structure is intended to facilitate my writing, not project recovery.) Losing the binder XML file is what causes the problems, and breaking your text up into smaller chunks won’t help you if your binder is kaput.
Now this is something I can agree with! Make project backups early and often. The easiest, most foolproof project recovery is the one done from a zipped backup. So I take frequent backups via Ctl-S. In my writing sessions, I treat Scrivener’s “Ctl-S manual project backup” like I do MS Office’s “Ctl-S save”. Eventually I will delete most of those backups, except for the last one from each day.
My projects are fiction and 100% text, so they never get so large that making a backup takes longer than a couple of seconds. I am currently 50k words into a novel, and making a backup is so fast I don’t even see it happen, so sometimes I feel compelled to go to the backup folder to verify it! Each backup is about 1 MB, so the size is negligible.
My zipped backups sync to OneDrive, so throughout my writing sessions they are being stored “off-site”.
For someone with much larger projects, I understand this might not be a viable approach. However, I would still consider ways to mitigate that, for instance storing photos and video outside the project.
I rambled a bit above, so to sum up my approach :
Planning the projects: I keep my projects small enough in size that I can and do back them up many times during a writing session. When/if disaster strikes, my last backup is usually only five to ten minutes old, so during any given session, my “at risk” writing is whatever I’ve done in the last five to ten minutes.
Easy recovery: Recovery from a zipped backup is quick and easy,
JimRac - Totally agree with everything you said. Setting up Ctrl-S to manually make a backup at Dropbox is by far the easiest and safest way to be able to easily recover a project. I have Scrivener set to keep the latest 10, and whenever I pause to think about something, I’ll hit Ctrl-S in those moments. It happens a lot during a session, so most of those backups are good enough.
I fully acknowledge that I am a bit nutty on the topic of backups… …but…may I ask why you are only keeping the last 10? And not 25?
Asking because when you have an issue with a Scrivener project, for example your project gets corrupted for some reason, you will likely open and close the project many times trying to figure out what’s wrong, and each time you do that you overlay a good backup with a bad one. By the time you realize you have to restore from backup, you may not have any good ones left!
I’ve unfortunately seen that sort of thing too often on these boards.Granted, these posters as a rule have the default setting to keep only 5, and I can see someone open and closing their project that many times in a minute or two.
10 is better than the default, but if you do have a problem, you need to pretty much recognize it right away and move your good backups out of the designated backup folder, so they don’t get overlaid by a backup of the garbled project.
25 seems like such a better cushion.
I prefer infinity myself, but I’m on the extreme edge of the meter.
This means that you basically have 10 almost identical backups, right? So if you inadvertently did something that made your project a mess, like an unwanted move of documents in the binder (this is not too uncommon, people drag-'n-drop when they were trying to do something else) which you don’t observed, a few thinking pauses later your original project structure has disappeared.
But having a very large number of backups require a lot of disc space, especially if your projects include a lot of bulky research material, like images.
So there is not one simple solution. You have to think about how you work, the size of your projects and what kind of disaster you are trying to avoid.
Whether you need to keep more of Scrivener’s automatic backups depends in part on what you are doing with backups generally. I only keep 5, but I also have a Time Machine volume (sorry, Mac only), rotating external backup drives, and an offsite backup service.
It’s also important to remember that data corruption (through either software failure or user error) is only one of several bad things that can happen to your data. Hard disks fail. Computers – especially portable computers – can be stolen. Homes can burn. You need a backup strategy that protects against all of these. Scrivener’s automatic backups are a good start, but shouldn’t be the only thing between your data and disaster.
Time, too. Because a backup is a full copy of the entire project, creating it takes much more time than simply saving what you’re currently working on. Plenty of people have projects up into the gigabyte range. Copying one of those every few minutes would eat up disk space and probably would disrupt the person’s ability to get work done.
Any time I mess with the structure of the Binder in any significant way, I Save As a different file, usually with a new version number - MyProject1, MyProject2, etc. If I am happy with the new structure, I’ll go back and delete all but the last two backups of the previous version.
You missed one word in my post: inadvertently. If you by accident e.g move things in the Binder without really noticing, there is no Undo to fix this, and you might not notice it until later. Or by mistake delete something important.
Backups are meant to save you from misstakes and mishaps, including user error, so it might be wise to at least think about this.
A question: Why press ctrl-S? Is it to create a new backup? In Word one needs to save manually every now and then but Scrivener’s automatic save-function makes it redundant, so why do manual saves?
If you set Scrivener to make a backup when doing a manual save, it creates a new backup. Just letting it save every few seconds doesn’t achieve that. So, worst case, you do a manual save without having it make a backup (or let it do its auto-save) and THEN the computer crashes while you still have the project open. The Binder is corrupted and you have to go back to the latest manual backup. With a new backup each time, it’s not very far back.
I keep an eye on the Binder closely enough that ‘inadvertent’ just isn’t likely to happen, but I see your point.
It certainly seems that way. If you don’t include posts related to syncing, the number of posts here with corrupted Windows Scrivener projects vs. corrupted Mac projects feels like 100:1 !
Windows has orders of magnitude more crappy drivers and software than shims into the OS than the Mac does, too. Everybody insists on using their favorite garbagewear and then complains all the time when Windows crashes. Even back in the Windows 3.1 days, I’d see this. It’s why I stopped troubleshooting computers for friends and family – I got tired of being expected to fix their technology when they refused to change their bad behaviors.
You’re quite right; but the way I work I’ll essentially never work for 30 minutes without a 15-second pause to think somewhere. Plus I tend to be pretty compulsive about 
…but…may I ask why you are only keeping the last 10? And not 25?