I’m not aware of any change in L&L’s advice regarding use of cloud backups. And if anything, the complexity of the ‘Sync’ file options (both Mobile Devices & External Folders) has actually increased. Although as the ‘Sync’ option only automatically takes place when loading or closing the project you might be OK.
I use the Sync to External Folders in Dropbox to edit RTF files on my Android. And if I wasn’t so wedded to Dropbox I’d personally be happy to use any other cloud option. Be aware that even using Dropbox I have run into synching problems so just ensure you have a manual backup made as often as you not prepared to lose work. In my case this is at the completion of every completed draft of a chapter.
Google Drive specifically cannot be trusted with live Scrivener projects.
A Scrivener project contains several interconnected files. Most important of these is the .scrivx file, which is the index used to build the Binder. If you create or delete a file from your project, the .scrivx file has to be updated to reflect that change. The fundamental issue with Google Drive appears to be that it doesn’t necessarily upload changes in the order in which they occurred. This makes it possible for a change to the actual contents of the project to be uploaded, but not the corresponding change to the .scrivx file, or vice versa, with potentially catastrophic results.
Thank you for these replies, which confirm again what only makes sense. Google drive has enough unreliability just keeping routine Word files and similar in sync across two devices, without adding all that Scrivener a project requires to the mix.
As a bit of a nitpicky point, be very clear to distinguish between cloud sync and cloud backups. Cloud backup services that provide an actual point-in-time copy of your project(s) in the cloud are a very good idea.
OneDrive, GoogleDrive, DropBox, Box, iCloud, etc. are cloud sync services, not cloud backup services.
Unnecessarily complex. Zero need to zip and unzip files to work on.
If you are working on 1 computer only, have your Scrivener projects on that computer and work on them directly. Set auto backup on close with 25 backups so you can always go back in time. Have backups Zip and point them to save on cloud of choice. I also incremental backup entire system on daily basis.
If you are working on multiple computers have Dropbox installed on all and save to the local Dropbox folder. With (very) basic precautions it is rock solid. If using Dropbox have your Zip backups stored on a different cloud or local NAS etc. Live work and backup should be on different platforms.
Main point, if something goes wrong, don’t panic and start unzipping backups. Sit for a while and figure out what went wrong before you start poking around.
While ZIP backups are indeed safer, they are not necessary if your backup practices are otherwise sound. Manually managing the transfer between systems also poses a non-zero risk that you’ll either forget to transfer to the project to a system where it’s needed, or mistakenly open an older version of the project.
The method I use has been written up in our knowledge base as well. I use a combination of synchronisation, Scrivener’s automatic backups, and a simple workflow, where on device switch I pull the latest backup from the stack to the local disk and work on it from there. How one manages that side of it is quite flexible. My approach is to remove the old copy and unzip the replacement in one shot. This keeps each device clean, consisting of nothing but the backups (synced) and one copy of the project which is always assumed to be old when starting up the device.
The result is extremely low risk, all you are actually syncing are singular .zip files, and when you’re done you close the project and the automation between Scrivener and sync tool handles the rest for you.
Consequently the method also works with just about anything out there, since it requires so few moving parts. This allows you to stick with your preferred system, even if that system itself struggles to work with more active, heavy-duty file formats.