Howto: Couchbase Lite Backup & Restore?

#1

Hi!

We’d like to implement a backup/restore procedure of an entire Couchbase Lite database using the iPhone. So the user is able to see stored snapshots of his data and restore the full database from the snapshot he likes. How would we implement this best? Unfortunately I’ve not found any info on this topic so far :frowning:

This is our current setup:

  1. The user stores all of his data locally inside one Couchbase Lite database using iOS Models.
  2. The local database is synchronized to a remote bucket using the sync_gateway.

INFO: The data of all users is synchronized into this remote bucket. But every user sees only his own data on his iPhone. This is accomplished by using channels: The sync only replicates one channel per user.

With this setup given, how would we implement a per user backup and restore procedure?

#2

One idea is to add channels of the documents, representing version, and if you want to restore to a certain version, set the proper channel

Regards,
Vlad

#3

Altough this looks like it may work; it’s a bit odd introducing new channels on a daily basis in all documents just to be able to reset the database to an earlier stage?

Isn’t it possible to “tag” a channel and afterwards reset to this tag? Similar as it is possible in Git for example?

Or anything similar which is as simple as this?

#4

snej showed me a possible solution on this on GitHub

For backing up the database locally:

  1. Stop the sync process
  2. Close the connection to the currently used database
  3. Copy the *.cblite and the corresponding * attachments folder
  4. Open again the connection to the currently used database
  5. Kick off the sync process

To restore the database:

  1. Close the connection to the currently used database
  2. Replace the currently used database with a backup done before
  3. Open the connection to the just restored database
    4. Create new revisions of every document in the restored database to force the client’s data be synced to the server - how? (see below)
    5. Kick of the sync process
    6. Doe some sort of cleanup after the initial sync - how? (see below)

Unfortunately I have no clue, how to create new revisions of each document without modifying it’s data. How could this be done?

Also I think I have to delete all documents which are newer than the backup after the sync process has finished the first time, to avoid cluttering the local database with newer remote documents? How could I be sure the initial sync has been completed after the restore has taken place?

#5

Hi @mandelkind, about creating new revisions, check this doc http://developer.couchbase.com/documentation/mobile/current/develop/references/couchbase-lite/couchbase-lite/revision/saved-revision/index.html

and here you can read on how to observe and monitor the replication http://developer.couchbase.com/documentation/mobile/current/develop/guides/couchbase-lite/native-api/replication/index.html

Regards,
Vlad

#6

Hi @vladoatanasov,

Thank you very much for your suggestions till now. I was able to implement the backup / restore process using the newRevision function of the CBLDocument.

But now I’m stuck with the following scenario:

After restoring the database locally, couchbase lite begins to sync with the server. And if there are documents stored on the server which weren’t present in the backup they are obviously synced back to the device.

Usually this is great, but in my scenario this shouldn’t happen. The servers data should be replace by the clients restored backup. How could I force this?

Any Idea?

#7

Hi @mandelkind,
I’m not sure about the exact behaviour that you are trying to implement, but if you don’t want new revisions after the backup has been restored, why don’t you just stop pull replication?

Regards,
Vlad

#8

@vladoatanasov

Wouldn’t these revisions be synced to the device as soon as the pull replication will start again?

#9

Hi @mandelkind, sorry for the late reply. Yes, revisions will be synced once you run replication again. One thing you can do, is to create new revisions on the documents, if the rev number on the device is bigger than the one on the server, pull won’t occur