View Single Post
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old February 24th, 2016, 01:08 PM
Quote:
Originally Posted by EightBitz View Post
The cloud isn't for backing up your realms, it's for synchronizing (plus the other stuff mentioned above and in the FAQ). Synchronizing is not the same as backing up. Backups are still done on your local machine.

To clarify the difference:
A backup is an offline copy of your realms that is never used as a live copy or never modified in any way. Backups protect against data corruption or unintended changes, because in such cases, you can restore your backups, and your realms will be restored to how they existed at the time the backups were created. If you've been vigilant about taking backups, this will be a reasonably recent copy.

Synchronization means that you have two active copies (one on your computer, and one in the cloud), and any changes you make are then copied to the other. So if something is corrupt, the corruption will either prevent the synchronization or propagate with the synchronization. If you make unintended or unwanted changes, they will also propagate.

TL;DR, the cloud offers synchronization, not backups. Backups prevent data loss. Synchronization propagates data loss.
I believe you're grossly simplifying things with your final conclusion above. Everything you said up to that point was sound, but that conclusion is NOT what users should walk away thinking. Since at least some already have, I need to clarify here, as the assertion will be misleading to others who don't have all the technical background and understanding that you've got.

I'm going to start with traditional syncing in an IT environment, where synchronization performs both automatically and transparently. It is also performed blindly, since the purpose of its use is typically something like automatic fail-over. In that environment, your assertion that synchronization propagates data loss is quite accurate. But that's NOT the RW model.

Within RW, there are three major differences from the normal approach in IT...

First, the RW syncing process is entirely user initiated. This means the user can choose when to trigger the sync, so if he knows he messed something up (e.g. deleted something he wants back), he can simply opt not to clobber the server with the local errors.

Second, the RW syncing process is selectively two-way. Combined with being user-initiated, a user can readily use the cloud as a backup. If he deletes something locally and wants it back, or something gets corrupted locally, or the user's disk fries, he can simply retrieve what's on the server and pull it down to his local computer. If you have two separate computers (e.g. desktop and laptop), you even have a second level of backup. If you make changes on Computer1, then sync it to the cloud, then realize that was a mistake, you can switch to Computer2 and force the cloud to take what's on Computer2, effectively restoring the cloud. You can then pull everything down from the cloud onto Computer1, restoring it.

Lastly, the RW syncing process performs extensive data validations to catch potential data-integrity problems BEFORE they get onto the server. Many of the dreaded "Sync -500" errors that users have encountered over the years are exactly this situation. There are occasionally bugs on the desktop client that result in localized data-integrity conflicts. The syncing logic vets all the data that comes up from the client to make sure it's error-free. If an error is encountered, the changes from the local computer are rejected by the server, and the issue is reported. In this way, issues with bad data are blocked from even getting onto the server, preserving a pristine version of the realm.

In general, the only way for synchronization to propagate data loss within Realm Works is when the user deletes the data and then the user explicitly performs a sync. And if the user has a second computer, he can use the trick I described above.

As an added fail-safe, RW automatically makes a new backup of your database every time you launch the product, keeping the last 10 copies. So users can also restore from a local backup at any time if they make changes that they want to undo.

I hope this post makes the whole process clear to everyone.
rob is offline   #9 Reply With Quote