Most people did not have to worry about this because they were lucky. Most people I asked don’t worry because they don’t have backups whatsoever, but will worry when it’s too late, just like this student only 6 years ago: https://www.bbc.com/news/av/world-africa-41257345
Most others who didn’t worry in the past decade had a subscription to Apple Cloud, where until recently their data was not securely encrypted.
Based on that, the average consumer’s backup solution is no backup. Yay, we’re already there!
But we aim at being a premium brand, so yeah, we still have a ways to go to match Apple.
On the file system level, there is no such thing. You need only permission, for example being root, to read or copy the file. Perhaps you mix it up with encrypted files for which a human needs a password to “understand” the contents of the file. But, root can backup the file to some place without knowing its content. Just do a test with such a file as root
Haven’t tried the backup icon yet. Although it appears the backup is internal to the L5, not over USB. Haven’t tried it yet. I should, it feels so Nerdy, if I can only get a USB hook up to a reel-to-reel tape drive, (with drivers)… hmmm 6250bpi.
But you really have no guarantee about the quality of the backup i.e. whether - if you had to restore it - you would have a fully operational phone.
Unless you quiesce the phone properly, certain files that are in use at the time of the backup may be effectively corrupt on the backup. (The effect of that may range from none, through minor annoyance to serious.)
That’s why I use Jumpdrive to do a backup of the entire eMMC drive. Yes, that means taking an outage on the phone. (For me the outage is under 10 minutes but I expect it would take longer the more crap you have on the eMMC drive.)
Such a tar archive is never meant for giving a full operational device after restore. It only contains your “user land” files below ~purism and can, for example restore, your lost chatty SMS/calls database.
In case of a not working/booting phone the first necessary step would be flashing the OS.
Unless you have knowledge of the internals of the database software, you can’t do this. I mean you can but the result may be broken, corrupt, unusable, worse than before the restore.
The point is that tar is not synchronised with the database, so if an SMS came in whiletar is accessing the .db file, so the .db file is being updated in internal ways at the same time as the content of the .db is presumably being accessed sequentially by tar, the result that has been copied by tar may be corrupt and unusable. Since you can’t control whether an SMS comes in during your “backup”, you can’t guarantee the quality of the backup. You might get lucky.
For me, if I had a not working/not booting phone, I would use `dd` to restore the disk image of the eMMC drive (image made using Jumpdrive). I would not flash the OS.
This is basically what I do with all my computers. The only difference is that for regular computers I am using Live Boot, rather than Jumpdrive.
Wrong. I would just restore after flashing the full /home/purism and everything would be in place. Making dd copies of entire disks is just wasting of space. Imagine this with my 500 GByte laptop
Well yes but for the Librem 5 and for my Raspberry Pi devices I pipe dd through gzip so it’s not as bad as just imaging the entire 32 GB disk (in the case of the Librem 5).
It’s not wrong. You can accidentally copy a file with half the data as it’s being written. Then you face different degrees of data loss, unless you know what shape your file takes internally.
Imagine having a file “am a happy bunny”, starting the backup and then fixing the typo. Note that this requires shifting the contents of the file. Will you get “am a happy bunny”, “I am a happy bunny”, or “I aa happy bunny”? The first two are passable because your backup happened before or after the database write. The third one happened during a write operation and you get corrupted data because the database was not designed for that.
Btw: How this app Backups works? With tar also? I saw that I can specify the directories to backup, which means somehow on file/dirs level with cp or tar or …?
The difficulty in that is that it’s very hard to “not use” something for the average person. Is the session manager trying to save window positions right now? The shell trying to save command history?
It’s much easier to ensure that the device is not used by actually booting from a separate OS.
Not that I do it for my backups (I use snapshots, which have the exact problems.)
The bottom line is that it will work well for the content that you create overtly (e.g. LibreOffice documents or e.g. media files) but not so well for any file that is system-maintained.
There are technologies to address this but if you believe in keeping it simple, as I do, then Live Boot / Jumpdrive.
High end backup software that I used to work with would post changes to files that were updated during the backup at the end of then backup. It would also take a snapshot of memory. (Users were frozen for 5 minutes.)
Too bad if the updated file now depends on a file that wasn’t there during the backup In the end, you must know the shape of the data. Clever methods are not fool-proof.
(I use snapshots, which have the exact problems.)