I’m posting here so not to hijack a wishlist post, where Ioa said:
That sounds really scary. How big is the risk, and if it’s even remotely a “risk” why haven’t I heard about this difference between backups before?
I backup regularly, but don’t close Scrivener down unless I really need to (maybe up to once a fortnight?). So what’s the best advice? I can’t believe this is a case of don’t trust the “Backup on saves” backups, so what’s the skinny? What could go wrong? What data could I lose?
(Preface to say this is just my understanding off what Ioa said and how the projects work.)
This is about the binder.backup file that’s stored inside the project and is really only needed if something completely drastic and unlikely happens that requires Scrivener to attempt to restore your project from that file. The binder autosaves regularly along with the rest of the project when you make a change there, and as Ioa said in the risk of needing the binder.backup file is extremely low:
There’s really no difference in the type of backups that you’re making with the auto-backup feature to backup the entire project. The binder.backup file only updates when you open the project and begin working, and the auto-backup triggered by opening the project will run before that updates. So the binder.backup file will have the same modified date and time in that auto-backup as in the previous “on close” backup and on any “on save” backups from the previous sessions. Once you begin working, the binder.backup file updates (once) and then any “on save” and the “on close” backups will have the more current binder.backup file, up until you next close and open the project and begin working.
So at this point (and Ioa did say in his post that this is getting improved for future updates), you’ll want to periodically close and re-open the project so that the binder.backup file in the project gets updated, and that updated file will be part of your backups. But again, under normal circumstances Scrivener isn’t using that file to build your projects. (Strictly speaking, you could remove the file from the project entirely and your project would still work fine; Scrivener would just create a new one in the background.) And if you’re regularly making backups anyway, chances are that if one did get corrupted you’d be fine just going to the most recent backup and restoring from there.
That is all correct. That conversation was strictly about the internal backup components that Scrivener invisibly creates within the project itself, and they have nothing to do with the standard backups you can create in the File menu, or that the scheduler creates for you according to your automatic backup preferences. Those take a snapshot of the whole project, binder.backup included, and so are more useful for general recovery cases. Setting your preferences to backup on save is just as safe as backup on close.
Binder.backup is more of a technical tool at our disposal that we can use to help people out of a jam if needed. It isn’t obvious how to use it (but it’s actually pretty easy; it’s just a zip file).
Great, thanks folks. I’m up to speed (I think).
But to confirm…
All my backups will contain a backup of the binder as it is at the time the backup is made.
There is a “hidden” “binder backup zip”, that is updated on project close.
The latest available “binder backup zip” is included within each regular backup, it’s not going to be 100% in sync with the live backup, but it could be useful for the most one in a million instances.
Am I right? If so then I’ll continue with things as per usual.
Correct. Standard backups include everything and the kitchen sink. If it is inside the .scriv package, it’s in the backup. They’ll be the latest version of everything in the project, from the time of the backup.
Actually on project open right now, as that is a convenient point to determine whether or not the binder file is clean and uncorrupted, ensuring the internal binder.backup is not a duplicate of a bad .scrivx file. Scrivener loads your project using the primary binder .scrivx file, and if that is successful, it backs it up right then and there into the Files sub-folder inside the .scriv package. If it cannot open the project because the .scrivx file is corrupted it will fail to open the project and warn you that something looks wrong.
Correct. If you leave the project open all week, but your backup preferences are set to backup on manual save, then you should be safe and can continue working as you have. The only suggestion I would make for backup on save is to make sure that the total number of backups Scrivener keeps for each project (also configured in the preferences pane) high enough so that you have more than a day’s worth. That’s more for your safety than the program’s; by that I mean, if you make a set of bad edits and forget to snapshot, if your backup roll-off is too small, you might end up losing the good versions of the files you changed, if you are in the habit of saving manually often.
I use backup on save as well, and I think of it entirely as “make a backup” rather than “save the project”. Auto-save already has it saved, so manual save is (for myself) purely for making a backup and I make it a point to trigger a backup after every 1,000 words typed or edited, roughly.
But the “on project open” auto-backup runs before the binder.backup is modified, yes? That’s the way it looks checking the timestamps on everything. I suppose it’s mostly irrelevant, but I’m curious now. (Well, not really irrelevant, since it would be a backup of the last known good version that way. Right. That makes sense in my head.)
To clarify for Jenny and anyone else reading:
The automatic backups created according to Scrivener’s backup preferences, and backups created using File > Backup To, all back up everything in project. These backups essentially create copies (or zipped-up copies) of the entire project, so that if anything bad happens, you can open these backups and work on them.
The “binder.backup” up file is something entirely different and something that in general users do not need to worry about. It is an extra level of security built into the .scriv file. A .scriv file is essentially a bundle (or folder) full of files. Along with all of the RTF files that represent your text, a .scriv folder also contains a .scrivx file, which contains the binder structure - this file is therefore very important; if it is corrupt or lost, then the project cannot be opened. For this reason, every time the project is saved (regardless of backup settings - remember that this is entirely separate), the following happens:
a) If it is the first time the project is being saved since it was opened, the existing .scrivx file is backed up as binder.backup.
OR
b) If it is not the first time the project is being saved since it was opened, the existing .scrivx file is backed up as binder.autosave.
2) The existing .scrivx file is overwritten with a new file made from the project’s current structure.
Thus, binder.backup always contains the binder structure file as it was the last time the project was successfully opened, and so should never be corrupt. If Scrivener cannot open the .scrivx file for some reason, it will therefore try to open the binder.autosave backup, and if that fails, it falls back on the binder.backup file. This means that if a project’s binder structure file gets corrupted during a computer meltdown, the worst that should happen is that the next time you open the project, the binder is out of date by a session - which is much better than the project not opening at all.
But as I say, this has nothing to do with automatic backups, which are by far the best way of ensuring you have good backups of your project.
Yes, the on-project-open backup of the entire project is created before the project is opened at all - I think. I’ll have to check that, though. This is a good point, as if a project is corrupt and the backup is made before the project is opened, Scrivener might not realise it is corrupt and so make a backup of the corrupt version that overwrites a good version. Hmm. That is definitely something I need to check.
All the best,
Keith
Great thanks Keith.
And while we’re on the subject of backups. Is there any chance a “backup every hour” or similar option will be available at some point? A have my backups set to run on save, but if I’m zoned out working I can forget to cmd-s for quite a while! A behind the scenes backup that doesn’t interrupt the flow would be wonderful, but not essential (for me) as my zipped backups only take a couple of seconds to run anyway.
Probably not. I actually code that for early betas of 2.0, but the trouble is that it interrupts your work to back up. It also causes the Dock icon to bounce if you’re not in Scrivener, and backing up in a background thread isn’t really an option, especially if zipped files are used. It was dropped for these reasons.
All the best,
Keith
Just to follow up on this:
I checked the code and it does happen in the right order - the backup happens after the main window has loaded, which is after the project data has loaded - so backups should only ever be made on open if the project is not corrupt.
Best,
Keith
I’d be really happy with that though… Do you think when applescript is enabled, this feature is something that could be hand rolled? Either from within Scrivener, or via an external script “calling scrivener”
I suppose when that does happen, as long as it gave access to the File > Backup Now command, you’d be able to set up an automatic timed backup, yes.
I thought… there’s got to be a way of doing this without needing specific apple script support in Scrivener, and there is (which works for me and my paranoid wish to backup regularly).
I’ve written an AppleScript that will run the File / Backup Up / Backup Now menu item, and then I’ve scheduled this using Cronnix (A GUI front end for cron).
Yes, there’s the expected interruption when the backup runs, but I can live with that (I think). I’ve got the script telling me it’s about to backup (May change this to a growl) which gives me a bit of notice. My backups take about one sip of tea, so no big deal.
Currently the script only runs when Scrivener is open, and only when my mac is active (Has been idle for less than 3630 seconds). This way it gives me a backup every hour, but only when I’m working. If I stop working, the backups will run once more, then stop until I’m back.
Script is here if anyone is interested:
dl.dropbox.com/u/1844583/Scriven … ppleScript
Cronnix is here:
macupdate.com/app/mac/7486/cronnix
Just be sure to schedule the command correctly EG
/usr/bin/osascript “/Users/Jen/WhereMyScriptsLiveExample/AppleScriptBackupScrivener.AppleScript”