Is snapshot only suppose to work for a single document or for the complete project?
When I make a snapshot, only a single document is affected. Also, I noticed that it’s not always possible to make a snapshot, pressing the icon is not doing anything. Am I using this option wrong?
If you use the command Document -> Take Snapshot (CMD-5), it will only take a snapshot of the document that you are currently working on.
In Preferences -> General, you can enable the option to take a snapshot of all documents that have been changed in some fashion when invoking the Save (CMD-S) command. That’s what I use.
Thanks, I didn’t know that. I never used Snapshots before, first time today 
I also use that preference, and as well I set the option to create a backup copy of the entire project with Cmd-S as well—in the Backups preference pane. So when I “save”, I gets snapshots of everything I’ve touched since the last save and a full project backup.
That aside, the snapshot and snapshot with title commands themselves also work on multiple file selections. If you have a chapter with 12 files in it and want to work freely within that chapter, you can select all 12 and snapshot them at once.
Other than the obvious limitation of not being able to snapshot unless the item is capable of having its text edited, the other thing to watch for are files/folders that are empty. If there is nothing to snapshot, the command is disabled.
I think the snapshot command will also fail if there are no changes since the last snapshot of that file.
Katherine
I prefer back-up on project close for the backups. It has forced me into the habit of closing each project every couple of days, which in my mind prevents accidental backing up of projects that have somehow been corrupted by remaining open for days/weeks at a time. Of course, there is probably no sound basis for such thinking.
Am I right in saying though that each file has to be selected in the Binder? E.g. If I’m working in Scrivenings mode, with just the chapter folder/top level file selected, a Snapshot will only be taken of that folder/top level file. At least that is how I always thought it worked.
Hi Kinsey, My apologies, as slightly off-topic, but if I understand you correctly, you are only taking a backup of your work every couple of days? You do realize that this approach puts up to a couple of days of your work at risk of loss?
For example, if you start your Scrivener session on Monday morning, work through Tuesday without closing your session or taking a “Backup Now”, and on Wednesday morning your hard drive has an unrecoverable failure, you will have no Scrivener backups available to you to recover your work, so anything you did on Monday or Tuesday is lost.
Just wanted to make sure you understood the risk of your approach.
Jim
On the matter of snapshots being disabled if the file hasn’t been modified: that’s a tweak that will be made to 3.0, yes. In 2.8 you can take snapshots over and over without editing the file.
That’s correct. If you want to snapshot 12 files you have to select the 12 files. It would be risky to assume that when one snapshots a folder they intend to also snapshot all descendants of that folder. I have some folders in front of me here that would cause thousands of snapshots to be created if that were how things worked. 
In practice this isn’t a huge problem if that’s actually the behaviour you want. Just use the Edit/Select with Subdocuments menu command (Opt-Cmd-A) and then Cmd-5.
A back-up is not the same as a snapshot. The former is a safety version of the entire project to be used in case disaster ever strikes.
A snapshot is intended for individual documents - for example, you’re about to do some heavy editing of a chapter; if you take a snapshot first, you can revert to it if your editing goes badly wrong. Or you may wish to compare the current version with an earlier version, perhaps to use the best aspects of each.
What Jim said. In my experience, the vast majority of permanent data loss associated with Scrivener could have been prevented with appropriate backup practices.
I strongly recommend closing Scrivener and any other critical applications when you’re away from your computer for an extended period, and shutting the whole system down at night.
Katherine
This is very much a matter of personal preference. I wouldn’t dream of rebooting except every few weeks to give the system a spring clean. However, I’ll certainly start taking your advice about restarting Scrivener on a regular basis … however, I wouldn’t want a back-up every day (for example) - is there a way to restrict back-ups to e.g. weekly?
Thanks for all the concern folks. I do indeed know the difference between a Snapshot and a Backup Scrivertid. And for brevity I hadn’t included the point that, apart from backup on close, I manually force a backup twice daily - I merely mentioned it because I used to use Ioa’s strategy, but changed according to my needs. I have a pretty robust backup strategy involving time machine, Carbon Copy Cloner, and rotating offsite hard disks. Fingers crossed I never need them.
Apologies to the OP for derailing the thread, but thanks for the clarity Ioa. That’s the behaviour I was expecting. I like to make sure I understand things correctly, as behaviour can change. E.g. Devonthink used to recommend storing databases in users’ Documents folder, but with Sierra that advice changed. Their documentation was very slow to reflect best practise.
Well, it’s your data… I’ve found that the best way to think of the backup interval is as the amount of data that you’re willing to lose.
No, it’s not possible to limit Scrivener’s automatic backups except with the options in the Preferences → Backups pane.
Katherine
Not necessarily. The most current version is still available on the Dropbox server if you keep it there, ready to be opened when the hard drive is restored… 
Hi Lunk,
Perhaps on a Mac. On Windows, if the project is open when the hard drive crashes, in my experience at least, there is a high likelihood of project corruption in one form or another, even on the DropBox version. So you are correct in that the user may be able to fully recover the project, but it would involve accessing and copying text from the project’s individual RTF files. Quite a PITA!
Only if the HD broke down while uploading to Dropbox, but Dropbox can restore broken files…
Lunk, it’s been my experience (based on personal experience and numerous scenarios on these boards) that open Scrivener projects in Windows can become “corrupted” when Scrivener crashes. (power failure, program failure, HD failure)
This can result in any number of issues, from loss of the text a single doc (but all else is good) to scenario where the project won’t even load (probably because XML is broken).
If you are saying that having the project files reside in DropBox is a foolproof antidote to any of these scenarios, well then, we’ll have to agree to disagree… 
There are no such thing as a foolproof technical system. It’s all a question of probabilities. And, as my teacher in statistics used to say: Low probability for an event does not mean that it doesn’t happen. It means that it DOES happen, but seldom.
Even so, having the live project in ones Dropbox folder is one way of lowering the risk of data loss, as is having a solid incremental backup system, like Time Machine on OS X, and closing the project and making a zipped backup of it when one stops working on it. The more safety systems you have, the less is the risk of losing anything.
Yes, it’s my data … which is in Time Machine and in the Dropbox online folder, so I’m covered for that.
On Scrivener backups though, could I uncheck “Backup when project is closed” and substitute it with “Backup when manually saved”?
That is the combination of settings that I use myself. I prefer being able to open projects without the intention of editing them, just to browse them and look up something, without generating a new backup. For those projects I do commit work to, I have the habit of backing them up before closing them.
Depending on how much use the project is getting and how important the changes are (as Katherine put: what I would not be willing to lose), when I’m spending all day working hard in one project, I’ll probably back it up three or four times. So that’s why I like that manual option, as it’s really easy to hit Cmd-S now and then.