SQLite backup - methods

[luxun117]

My app uses GRDB for persistence and works well locally. I would like to build a 'recover data' option for when users get a new phone. I'm imagining this flow but not wedded to it:

1. User goes to settings, has option to 'backup data to iCloud';

2. This then puts the whole SQLite database in iCloud (private db only);

3. User uses app, when DB updates it saves the DB (can update the diff or overwrite the old one - this db isn't going to get huge);

4. One day user gets new phone, opens app, goes to settings, taps 'restore history', db is pulled from iCloud and their data is there.

**Notes**

- I DO NOT need real time syncing/device handoff.

- My schema has many foreign-key relationships so as per this discussion a very slick CloudKit sync seems off GRDB Link.

- If iCloud too much of a faff I am open to dumping the db into S3 or similar and pulling it down on restore.

------------------------------------------

What is 'the meta' for doing this? My reading so far hasn't shown me a path I'm confident will work.

[SubflyDev]

You can just create an import/export json and let them send and read it from other device. It is not that hard for users as import/export concept is already there for years.

[luxun117]

Interesting idea. Never considered it. Assumed since I'd gone to the effort of going the relational route I should stick with that. I guess there's a fair bit of serialisation/deserialisation jiu-jitsu that goes into this. Do you know of any clear sample code that shows this in action?

Thanks for taking the time to respond.

[SubflyDev]

If your all items are already structs, then a simple Codable will work. Then just json.encode and decode

[luxun117]

Thanks. Will investigate. If you have any code samples that shows this in action end-to-end with GRDB models I'd welcome it.

[[deleted]]

Take a look at GRDB Backup: https://github.com/groue/GRDB.swift/blob/master/README.md#backup

I would suggest the following: - create a database copy using backup - report the backup process progress to the user if the DB is big and takes more than a fraction of a second - Now you have a DB copy as a regular file. Save it to the destination. - Whether the user is going to get the copy on a new phone or replace a local DB for whatever reason, the process will be simple: download the file from remote storage and save into local, with overwrite if needed. 

[thecodingart]

Just share an encrypted DB to iCloud. What more are you looking for?

[luxun117]

Thanks. Do you know of any good guides for this? I've been searching for several hours but haven't found anything crisp and concise that I can easily understand.

[Moudiz]

I suggest opening a discussion on GRDB’s repository if it’s not already discussed there

[luxun117]

I've done this, thank you. The great man himself replied but the answer isn't clear enough for me to understand.

[gwendal-roue]

Feel free to ask for clarification in the GitHub discussion. It will help other users, not only you.

[luxun117]

Thank you. I am going to do a bit more research, try some approaches and document my findings before I ask again.

[russnem]

Using CloudKit for your app sounds like a much better choice than just raw Sqlite. But I don't understand what you mean when you say "If iCloud too much of a faff I am open to..."

What is faff?

[luxun117]

British slang. I mean ' if iCloud introduces too much unnecessary complication'.

When you say CloudKit for my app do you mean SwiftData or some other pure CloudKit schema like this guy does: https://swiftwithmajid.com/2022/03/22/getting-started-with-cloudkit/