-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Settings backup/restore #11090
Comments
Hello. I use SeedVault (integrated in LineageOS, GrapheneOS etc.) for secure (encrypted) backup apps and data to my device (USB) or my server (NextCloud). But Nextcloud is opted-out from backups so it is not possible to save app data by SeedVault :( Please can you allow encrypted backups? I think it is good compromise. There is more info: https://github.com/seedvault-app/seedvault/wiki/FAQ And an example of commit: Thanks. |
Migrating for the first time in many years to non-rooted phone (with GrapheneOS ROM) and it is a major pain how many apps disable backup feature. This is how trivial it is to enable: grote/Transportr@4dc38f4 |
We disabled it recently because it caused problems when restoring in our case, and it wasn't easy to diagnose and fix. It's not always that easy... |
Hm, I see, is it still a plan to restore in the future though? UPD: For context I had to create 14!!! bug reports with a tiny selection of apps I have installed on my phone (they all fit on one screen without scrolling). |
Seconding this. I really is a PITA. Maybe the settings could be server side? With Nextcloud being a core app that many things can connect to, I wouldn't imagine it would be easy, but at the very least the auto uploads would be nice to have backed up and restored in an XML |
Adding some more thought to this: other Nextcloud apps using the Single-Sign-On feature could continue working if both sides save some mutual tokens. Relevant for the Nextcloud News app: nextcloud/news-android#1225 (comment) |
@AlvaroBrey What were the problems restoring the backup ran into? If it is about the login credentials, Nextcloud should be able to exclude them from the backup (or, after restore, immediately delete them). Then it may ask the user again for its credentials so the potential new phone does not use the same credentials as the old one. |
This decision should ultimately be made by the user. However, the creds might be encrypted using / stored in the on board TPM and I'm not sure how to backup those. This shouldn't be a problem if the team adopts an iterative approach to backups instead of a project waterfall. Small, incremenal updates and features. You could start with a simple json settings export saved in the cloud instance for example. |
I can understand why this might be desired, but it can ran into problems if not properly implemented throughout the whole ecosystem. If one migrate from an old to a new device by restoring a backup without disabling the first device, both might use the same credentials. I do not know if this may be a problem for Nextcloud (at least the device name in security settings could be wrong if not updated). On Apple's forced app backup, the migration of credentials breaks apps which depend on the fact that this credential might be only used by one device at the same time. (saw a migration to new phone, Signal messages were received by either one of two iPhones, depending on which one was faster).
👍 sounds like a good starting point. That JSON file could then also be given to Android's Backup system, so the Nextcloud app may also already insert domain & username when logging in. |
See #10637. Esentially restoring backups from previous Android versions (which is done automatically on install if your Google Account is configured to do it) could lead to invalid permissions/sharedpreferences states As I understood back then it's not unfixable, but it would take time to diagnose and fix the backup config and app start logic so that only the relevant things would be restored while leaving the app in a consistent state |
If I read the thread correctly, the invalid permission problem can be worked around by fiddling with the folder settings / adding the rights manually. That's a minor inconvenience. Imho still better than no backups at all but I understand why it might be easier to just disable (native) backups. That's why I've been suggesting this:
from the beginning. NC app already exports a VCF file and stores is in the cloud instance. A subset of settings (like upload folders, auth info for SSO, etc.) can be exported as a, say, JSON file and stored in the cloud as well. The restore part would then be under full control of the app. Not ideal, not native, but still much better than no backups at all. |
In my opinion Nextcloud Android app has quite reasonable default settings, so I do not change much after restoration. But I really miss the ability to export/import auto-upload folders settings. The best solution would be to store these settings in the cloud - upon first login a list of folders would appear with a checkbox next to each item, which the user would have to check to confirm. It would be a revolution comparable to the introduction of the ability to log in with a QR code, which greatly sped up the process of restoring the app. |
That would also be a probably nice solution, but I assume it would be hard to get that right (especially in terms of UX) when a user has multiple phones or migrates from one or the other. However I would still prefer leveraging the Android system backups for that, as that would allow users to some more hazzle, esp. when the Nextcloud app also backups the access token or at least instead of requiring users to type in their server address & user name, it may also just ask to refresh the access token after a backup restore. |
Yes, this is exactly the sort of thing that needs to be backed up as app data for the NextCloud app using the Android backup and restore facility.
I disagree. This is data that should be automatically and silently backed up and restored with the app using the Android backup and restore facility.
Exactly. The Android backup and restore facility would store these settings, per device not per-user (who can have many devices).
100%
Again, 100%. In fact, backing up and restoring user data per app is the default for all apps. App developers have to actually choose to opt-out of it which is what this app has done. Not sure what is (or was, maybe it's working now) broken about it. Maybe it's time to revisit it? It is almost 2 years later now. |
Currently broken Signed-off-by: Álvaro Brey <[email protected]>
OK, I agree with you that the best option would be an Android backup system. But for some reason the Nextcloud team does not want to implement this solution. In such a situation maybe it would be worth thinking about the function of exporting auto-upload settings to a file with the possibility of restoring them later. One more point. As I guess, the refusal to implement Android backup system is related to security issues. But after all, such a backup does not have to contain any sensitive data. Let me give an example of how this is implemented in the K-9 Mail application. The user has the ability to export settings to a text file. It contains all the settings of the application itself and the settings of the account (or accounts if there is more than one) but without passwords. The user, upon first starting the application, has the option to import these settings, after which he must enter the account password. Why couldn't such a solution be supported by Nextcloud? |
I want my backups automated for all apps at once. I don't want to go to each app periodically and manually export/import configuration.
What issues exactly? Backups can be client-side encrypted. |
I too would prefer an automatic backup. But if there isn't one, a manual export to a file is better than nothing.
Don't ask me - ask the Nextcloud developers. From what I remember the topic has been discussed for a long time. |
even an app-specific config export can be automated in case of a cloud application. The solution is obvious - save the exported configuration automatically in the linked Nextcloud instance(s) and automate restore on reinstall. It's still slightly less convenient because one must first log in to the instance but with QR login this is trivial. |
If the Nextcloud devs are not even going to go to the effort of flipping a switch so that Android backs up the data (it is encrypted, so security FUD does not have a place here) what makes you think they are going to spend time writing code to do export/import? Android backup is the lowest hanging fruit here. |
I wouldn't say it's so simple. According to some just enabling the backups can possibly break the restore to a state that requires expert knowledge to fix (wrong permissions) and may not even be fixable on a non-rooted phone if I understand the issue correctly. That's not exactly something you can roll out to all the enterprise users for example. There are a lot companies who use Nextcloud internally and their users don't care about Nextcloud one bit - to them it's just "this sharepoint thingie IT gave us" and these are the users who may suffer the worst consequences. Or, rather, their IT would. That's why I propose a solution that is entirely under the control of Nextcloud and doesn't rely on any 3rd-party solutions which may or may not break under certain not-so-predictable circumstances. |
I do occasional ROM tests and it is always pain to restore Nextcloud app to working order - mostly several auto-upload folders I use which are (nearly) always the same. I use SeedVault for most of my backups but NC doesn't allow backup.
An obvious solution for a cloud app would be, to, err, store its settings in the cloud :) App can export the settings and save it in the connected NC instance in the same way contacts and calendars are backed up.
Alternative solution (and simple from code perspective) would be to allow the app to have its data backed up by Android backup provider, which is now disallowed.
A poor man's fix might be adding a "export/import settings" option in settings, though this is essentially the same as the first suggestion.
The text was updated successfully, but these errors were encountered: