Backup is inefficient in space and time

[DDvO]

Backup data takes much more space than it should (or at least reports).

Even in cases where the backup process reports that it took some 500 MB, the actual storage size is around 1500 MB. And when re-doing a backup after a few minutes, at least in some cases this again takes rather long time and much more space is taken. ~Looks like backups are not incremental?~ Update: maybe this is just in cases where the earlier run was incomplete because of missing storage space.

Moreover, looks like a possibility is missing for the user to delete backups that are no more needed, in order to re-gain space.

This inefficiency is a big issue, both when using local storage (because usually not very much space is left on the device) and when using remote storage, where transfer often is painfully slow and in my case took about two hours. Even worse, on any intermittent (e.g., network) error, backup fails (is not resilient to such issues), and on retry it partially takes, in total, even more space and time.

[grote]

Even in cases where the backup process reports that it took some 500 MB, the actual storage size is around 1500 MB.

That is most likely, because the other 1000MB are the apps themselves (APKs). We don't include those in the notification to not give users false security about how much data was backed up.

And when re-doing a backup after a few minutes, at least in some cases this again takes rather long time and much more space is taken. Looks like backups are not incremental? Update: maybe this is just in cases where the earlier run was incomplete because of missing storage space.

Yes when the backup fails, the system re-inits a complete copy of the backup. It even wants us to delete the old one which we don't do for your convenience.

Moreover, looks like a possibility is missing for the user to delete backups that are no more needed, in order to re-gain space.

This is https://github.com/seedvault-app/seedvault/issues/100

This inefficiency is a big issue, both when using local storage (because usually not very much space is left on the device) and when using remote storage

Thanks for letting us know that this is a big issue for you. Provided that we find a way in https://github.com/seedvault-app/seedvault/issues/566, it may help with this.

[DDvO]

Even in cases where the backup process reports that it took some 500 MB, the actual storage size is around 1500 MB.

That is most likely, because the other 1000MB are the apps themselves (APKs).

Hmm, this might be, but I doubt that those around 25 apps that allegedly got backed up correctly take as much as 1000 MB.

We don't include those in the notification to not give users false security about how much data was backed up.

So your notification just includes the data size? That is misleading. Why not report both the data and apps sizes?

And when re-doing a backup after a few minutes, at least in some cases this again takes rather long time and much more space is taken. Looks like backups are not incremental? Update: maybe this is just in cases where the earlier run was incomplete because of missing storage space.

Yes when the backup fails, the system re-inits a complete copy of the backup. It even wants us to delete the old one which we don't do for your convenience.

I see.

Moreover, looks like a possibility is missing for the user to delete backups that are no more needed, in order to re-gain space.

This is #100

Good to know. Yet not very promising that that FR is meanwhile nearly 4 years old.

This inefficiency is a big issue, both when using local storage (because usually not very much space is left on the device) and when using remote storage

Thanks for letting us know that this is a big issue for you. Provided that we find a way in #566, it may help with this.

Interesting. What also could help more or less is to compress (using gzip) the apps and data, like for instance TitaniumBackup does.