Dear L&L,
I back up my Home Directory on my Mac using ChronoSync 10 from Econ Technologies. The software has these options available for copying package files:
‘Package handling - ‘Standard’ treats packaged files as a whole. ‘Merge’ attempts to merge changes of the packaged files. ‘Dissect’ treats packaged folders as regular folders and examines their content.’
Which option is compatible with live Scrivener projects that have not been zipped as backups?
Thank you so much.
Frankly I do not know without thinking very hard, but as a long time Chronosync user I would say you are best asking Chronosync support for guidance. Or their extensive FAQ may elaborate on these options. Scrivener files are managed by the Scrivener app and if “Active” and/or open, probably anybody’s guess if you are getting a good copy.
A best practice for Scrivener, in my opinion and as documented by Scrivener, is to backup to zip using Scrivener standard feature to a folder different from the project “package” folder. Back up frequently as you want. Then use Chronosync to back up those backup zips as frequently as you want.
Thank you. I’ll ask Econ Technologies, but it’s unlikely they know about the file system of Scrivener. Allowing ‘Merge’ or ‘Dissect’ could compromise their integrity by enabling ChronoSync to change the files within them. I’m asking this question specifically because changing these settings will have a wider impact on backups than just Scrivener projects. To be on the safe side, it may be best to avoid using live Scrivener projects as a backup source.
Yes, IMHO, when using Chronosync. But keep (or start?) using TimeMachine as a full system backup as a matter of routine, also IMHO.
Synced cloud files should not be thought of as a backup. When something goes wrong the automatic syncing instantly propagates the badness. Backups proper speaking only go in one direction.
Why are you backing up your live project directly when Scrivener is already automatically backing it up (multiply, and according to customizable settings). What you should be backing up is your Scrivener backup folder.
Totally agree! But the product “Chronosync” is not a cloud based sync service. Its best described as a front-end to the “rsync” terminal command. https://www.econtechnologies.com/chronosync/overview.html
It’s a good product.
I am not aware of the intricacies of how ChronoSync handles “package” folders with these settings, but I would be cautious about merging as that will almost certainly cause problems. For example it probably would not handle deletions, meaning if you empty the trash in Scrivener then there should be a lot of files and folders that are cleaned out of the project. Merging may bring them right back, causing a bunch of “recovered files” the next time you open the project.
From the description, Dissect is probably best, to have it handled like a normal folder hierarchy. It should in theory have the same result as Standard, only instead of wasting a lot of time rewriting the entire folder if only one thing inside of it changes, just the parts that change will be handled. That’s the part I would ask their support for clarity on. My guess is that Standard is probably the safest option all around, but the most expensive in terms of backup time.
It’s not an onerous task, though, after using the initial “wizard” to stup. One time and should take but a minute or so to exclude the Scrivener project folder. In Chronosync Task setup, click on Analyze button, followed by the “exclude” button at top. Click on the folders you wish to exclude.
Assuming there is one “root” folder for all Scrivener projects (each as subfolders/packages), then it’s one click check.
Thanks a lot. This is exactly the information I was looking for.
Sure thing, and I would add also that the way Time Machine and most backup systems work is probably closest to Dissect as well. When I say standard is “safest” I mean that in an over-the-top level of safety that a full disk image backup would resemble, as opposed to a long series of incremental change snapshots. There is more complexity in the latter, but this is still quite safe. As I say, most backup systems depend upon that to keep backup times from taking many, many hours every time.
Yes, you are absolutely right. I’ve only ever wanted ChronoSync to copy absolutely everything, mostly so I wouldn’t accidentally leave something out. I learned the hard way that excluding folders from the Library, although unrelated to Scrivener, can cause problems when needing to retrieve something from them later.
You using TimeMachine routinely? It gets everything (including global and user Library et. al.), works great to restore individual files (where mistakes are made and I’ve made plenty), recovery from a hard disk crash (which I have had a few over the years), and to setup a new machine … way to go.
Do TimeMachine in addition to your Chronosync copies, IMHO.
Don’t know the program but I would be very wary of letting any backup utility merge changes. Could reck untold damage on a Scrivener Project.
Yes, I’ve been using ChronoSync for some years, and it’s always worked well. I’m just now scratching my head over whether incrementally backing up my Scrivener projects will compromise their integrity. - As far as I am aware, the only dependable cloud service for syncing Scrivener projects is Dropbox because of past synchronization difficulties. That’s why I had a feeling that backing them up might be problematic too. - Thank you so much again.
Yes, thanks, that’s what I thought too. I wouldn’t dare to use the merge option for Scrivener projects myself. The problem here is that if I change the backup settings, they change globally for all my backups. Therefore, I need to consider whether it would be easier to exclude the live Scrivener projects as a backup source.
I’ll help you decide.
Yes, exclude the source Scrivener project folder from Chronosync copy. Include the separate Scrivener backup folder (which then captures all the zip’ed files).
For something meant to function as a backup, that is a level of maintenance and fiddling that I wouldn’t want to bother with. There is no risk at all in including the folder structure of a Scrivener project in your backup! It’s just a bunch of files in folders like any other part of your user folder.
Excluding them would mean that a full restoration would entail having to go through all of your zipped backups and extracting them back where they should go, one by one, and hoping that each one of them is perfectly up to date (ideally they should be, but we can know with more certainty that the original data they come from will be up to date).
To my mind anyway, that defeats the purpose of a backup, which should include everything outside of volatile data that has no purpose being backed up (like the Caches folder in Library). That’s the kind of thing exclusion should be used for, rather than important data—even if you do have other copies of that data elsewhere in the user folder.
If you are concerned about the backup settings for Scrivener project packages to be different than the rest of your Chronosync Task setting, you can exclude from the one Task, and add another Task only for the Scrivener packages and use the Chronosync settings you want.
OK, if I treat packaged folders as regular folders and examine their content by setting the value to “Dissect,” Scrivener projects can be included in the backups. I was too careful because I believed that changing Scrivener project files outside of the program could damage the project’s integrity, and because of the known issues of Scrivener with cloud services. Your feedback is appreciated. I’ll try my backups like this from now on. Thank you so much.