I used DropBox for automatic backups. I used iCloud for tertiary backups of those DropBox backups. I used Dropbox exactly as Literature and Latte recomended in their how to vids. This notion that problems must be the user’s fault is absurd. Scrivener rebuilt my document structure. DropBox didn’t. Scrivener new decided to build a new folder in my project’s binder called “Recovered Files” and to move document and document fragments from other places in my project’s binder, into that “Recovered Files” folder and to append the phrase “(Conflicts)” to these document names. In many cases, these documents are fragmented and in no way represent the actual state of those documents in the most resent save (prior to the curuption of the project). Many of my project’s binder documents are completely missing. I manually made copies of the dropbox stored backups and moved these to a special folder within my mac’s iCloud iDrive shared documents folder. iCloud performed this function correctly and consistently and without problems. Neither Dropbox nor iCloud seem at all to be the problem. The problem was with my primary Scrivener projects (not the backups), and those were being saved locally to a folder within my root user folder (my user account).
Apparently, I did not notice this problem right away as my manuscript is large, has many tens of binder documents, so the “Recovered Files” folder was deep down at the bottom of my scrolling binder area. Scrivener sent no warning when this occurred.
If this was a year ago, I think it’s safe to say that no one in this conversation has any way to determine exactly what happened, short of spending money on forensic analysis of the drive. (If then.)
If “Recovered” or “Conflict” files were created in the project, then a synchronization error occurred. The exact cause and nature of that error are likely impossible to determine at this point.
Generally speaking, ZIP backups are safe with pretty much any cloud service. Unzipped project folders expose the contents of the project, making them more vulnerable to damage. We recommend having multiple backups for critical data.
The “Recovered Files” folder is created when the project is damaged by a third party tool and Scrivener discovers orphaned files upon loading up the project. The most common cause for that problem is if the project is stored on a cloud drive and is accidentally edited twice without fully syncing (so yes, user error is often to blame). By creating that Recovered Files folder, Scrivener makes it easier for you to see which parts of the project conflicted when that syncing error happened, so you can sort out those conflicts by hand. So given all of that, it’s safe to assume that there was a syncing conflict, but as kewms mentioned, it’s impossible to know the exact circumstances if this happened that long ago.
I do hope you read and also followed all the guidance in section 14.1 of the Scrivener User Manual. Three simple rules that should be known and followed by all Scrivener users who chose to put their files in a folder synced with cloud-based services.
I feel for you. I haven’t had a transfer loss, but I’ve had dozens of backups full of holes.
Dropbox + multiple machines a few years ago taught me never to save direct to the cloud. All it takes is one machine’s program not loading the entire file, then saving empty chapters over the copy in Dropbox.
There are data companies that often do a good job recovering data. They ain’t cheap, but it’s worth a try. Forensic data recovery involved byte by byte examination using an electron microscope, among other tools. The Starr Report printed the results of fairly successful results even after an effort was made to deliberately destroy the files,
However, if you’ve been using the same drive for a year chances of recovery are low.
I crashed the HD on my IBM Thinkpad as I was arriving at the Mathura station on the train from Delhi (mid 2008). I had purchased an extra warranty that covered the new HD but to get the data off of it I had to go a special data recovery agency that IBM recommended. It was India so the costs were not prohibitive for me but it still took a lot of time. After that bitter experience I always made sure I had lots of backups. However, backing up a PC at that time was not a simple process (maybe it is today) and I was never sure if my backups would work. In 2009 I switched to Macs. One of the things I really like about Macs is Time Machine and how it makes backing up you data so simple. And, of course I also back up import items on DropBox.
Super. Just so you and those reading are aware, Dropbox (and others like it) is a syncing service. If you rely on a sync method for backup, then if/when the synched backup on your local device or server (inevitably–things happen) becomes corrupt/deleted/whatever and (probably) you don’t notice, then on next sync after that event, poof , your so-called backup is gone.
I also “copy” into Google Drive (Dropbox getting too expensive) very important stuff to be recovered quickly if needed. But I don’t rely on it if things don’t work out.
Thank you for emphasizing this. Dropbox is wonderfully convenient. I use it constantly myself. But it is not a backup service and should not be trusted with the only copy of important data.
But Apple promises me—on their iCloud webpage, with its several meters of colourful, warm and happy images to scroll through, in order to read small, distantly placed and carefully written positive and affirmative paragraphs, none of which distills down to a single tough and complicated piece of information to frustrate myself with—that my data will be safe with them!
There’s a narrow interpretation of the word backup that leaves out Dropbox, because it propagates deletions and doesn’t save versions forever.
Personally, I’ve retrieved gigabytes of data from Dropbox more often than I have from Time Machine … and I’ve seen Time Machine fail on two perfectly good external drives. It’s annoying that I can’t delete old backups of things I’ll never want again, too. People count Backblaze and others as backups. I suspect they are more convenient than Time Machine, but not as convenient as Dropbox.
Still, I do use Time Machine and sync with ChronoSync to an external hard drive (not to mention the hard drives of four Macs in the house, mirrored by Dropbox and synced to three Time Machine drives), so I am decidedly not using Dropbox as the only copy of important data.
I would say the definition of what is or is not a traditional backup system is more simply stated as something that copies in one single direction only (from the volatile environment to the backup medium), ever, unless you specifically come along and give it commands to change your file system to some degree of specificity.
Anything that changes your local system on the fly, without your intervention, for whatever reason (be it deletion propagation, or a PDF file corrupting silently and unnoticed, or a mistaken edit to a file you have open auto-saving), is not a backup. Whether you personally have retrieved gigabytes from such a service or not really does not change the definition.
There is a word for the kinds of tools that do that: synchronisation. Why do we need to conflate that with the concept of a backup? I can give you one reason: effective and misleading marketing programs.
Still, I do use Time Machine and sync with ChronoSync to an external hard drive (not to mention the hard drives of four Macs in the house, mirrored by Dropbox and synced to three Time Machine drives), so I am decidedly not using Dropbox as the only copy of important data.
Of course you do, because that would be very risky.
P.S. Time Machine isn’t a good backup either, though it is one in the standard definition. The main problem is that it’s plugged into your computer at all times and is thus subject to the same circuit and environmental hazards as the computer. It’s better to think of it as a glorified and long-term system level Undo command. It can also be, as you note, a bit unreliable. I don’t trust it, but it has come in handy now and then.
Not necessarily. E.g. I use multiple TM drives, some of them are only physically connected for and during the backup (only). And you can backup to a NAS, located virtually anywhere.
Sure, you can treat a TM drive more like a traditional backup and only plug it in now and then, or in rotation with others. It’s not quite the same as having an hourly full backup though, so I would of define that has a hybrid “Time Machine”. The hourly aspect of it is nice to have, but I wouldn’t depend on it for my only backup, is more what I was getting at.
Absolutely, yes. By the way, Time Machine creates hourly backups even if no TM drive is connected at all (give it a try!). On the same internal drive that’s mostly in danger, of course. So that alone wouldn’t be a “backup”, rather kind of an advanced recycle bin.
But a good backup strategy is like an onion. You put layer upon layer, each one farther away from the potential catastrophe. Common sense. TM is really good. But it’s users… depends.
Traditionally, the key aspect that determines whether a copy is a backup or not is something we call “point-in-time.” Once you create the backup, it represents a specific point in time of the history of whatever is being backed up. Further changes to the source data will not cause changes to that backup copy.
Versioning often comes close, but many versioning implementations require the user to stitch together the various versions of files to create that true point-in-time copy, and most sync engines are optimized around trying to copy changes as soon as they are noticed, rather than taking discrete snapshots of the data being backed up as a whole.
