Open thedavidmeister opened 7 years ago
For light wallets, the database is already minimal.
For full wallets, do I understand it correctly that the suggestion is to backup only user-related information, and in order to restore, the user will need to sync the entire DAG from scratch and then add his data from a small backup?
@tonyofbyteball yes, that sounds right, "backup the DAG" sounds like its own functionality that doesn't need to be conflated with backing up the user's data.
So, the suggestion is to have two backup options:
@tonyofbyteball well, assuming there's a clear split between the two in the db structure, backing up less data means less can go wrong.
i don't personally have a use case to back up the DAG, but maybe you might want to do something academic with it... but it is currently in the backup, so i assumed there is a reason?
co-signers of multisig wallets are stored only in the app's data directory
Well, you can thank me for making byteball 12.5 gigabytes more scarce than intended. #FML I only backed up the wallet seed and uninstalled it from my phone.
Why in the world is it set up that way? Either there needs to be a single recovery phrase for all wallets created, or individual backed up wallet seeds.
OK so, according to https://wiki.byteball.org/backups (and the app itself):
But, if i understand correctly (please correct me if i'm wrong):
.sqlite
database has 59 tables and 113 indexes.sqlite
database could be equal to a full backup of the entire DAG if you're running a full hub, which can be many GB and in the future TB or even PBSo, the use-case of only wanting to preserve/secure/transfer the basic right to spend your bytes on the network in the most minimal and robust way (no chance of unrelated data being corrupted in the backup/restore process and ruining your day) is not really supported atm, but IMO should be.
I've been lurking in the
#helpdesk
chat in slack and see people complaining about corrupt databases, often corresponding to backup imports.It seems these corruption issues would be far less likely and much easier to debug if the size of the backup itself was kept as small as possible.