Backup Delay On Closing

The amount of time Scrivener is taking to do a backup on close is so long that I find I’m minimizing instead of closing the program down. Something’s wrong. I tried searching the forum and couldn’t find what the problem might be. Thoughts? Suggestions? Thx

Numbers will help here; Use a timer to record how long it takes to create a backup. Also, check the backups folder to see how big that backup was. Then we can pontificate on the nature of the delay, and possibly offer solutions. Also, does the backup folder reside on the internal disk, or is it sent to a network drive or a usb flash drive, or some other destination?

I’ll clock it next time but again, it’s so long I try to avoid closing the program down. The backup is on the internal hard drive. Thanks.

Not knowing your level of patience, that could mean 10 seconds :unamused: , 10 minutes :neutral_face: , or 10 hours :open_mouth: .

I haven’t much patience, as my bride will attest, but I just clocked 2 minutes, 15 seconds. I’m a journalist who has sound recordings of 6-8 interviews that range from 10 minutes to a half hour. Any chance there is an overload that is the culprit?

Backup will indeed duplicate the entire project each time, so if the project is quite large, it could take a while to back up. What I would do is locate the project in Finder, and press Cmd-I to “Get Info”. Give it a moment to calculate, and then give us the number it prints in the top-right. Even without our consultation though, I can tell you that if it is greater than 100mb or so, it will take a bit to backup. At your rates I’d estimate it is even a bit higher than that.

If that is the problem, there are some things we can do to optimise that. The easiest is to go into your Backup preferences and disable zip compression. Zip can save space, and also makes the backups more portable across different computers (that’s more important if you use cloud or off-site backup services), but it also adds a considerable amount of CPU time to the backup procedure. Not only does your data need to be duplicated on the disk, it needs to run through a compressor byte-by-byte. So give that a shot and if it results in something your level of patience can tolerate: that is the level of action I would take. It leaves you with a safe, frequently backed up project, with only a very minimal drop in total security (like I say, Zips are a bit safer, but if they are just sitting on your hardrive there is no effective difference).

The second step you can take is “outsourcing” your bulk research. Export it all from the Binder, then trash the stuff in the Binder you exported, and empty the trash after double-checking that all of the files are safely outside of Scrivener. Now use the File/Import/Research Files as Aliases... menu command to bring only the links to these resources into the Binder. They will have a little arrow badge on their icons to indicate they are only links—but otherwise they will function as normal Binder items. You will now need to maintain your actual research data outside of Scrivener somewhere. This will dramatically reduce the overall size of your project, leaving it possible to leave the Zip option on. Thus, this may be the preferable option if you do rely on off-site or the cloud for backup storage.

The third step is the least recommended, but if all else fails you can disable backups for this one project. Do so in the File/Back Up/ sub-menu. Other projects will continue routine backups, but this one will be your responsibility to keep safe.