Will that script backup password protected files?
What is a password protected file? It will backup all files below ~purism.
The files for WayDroid are password protected so I can’t back them up with deja dup. Hoping this will work
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
cat file > /dev/null
1 Like
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.
You can set the backup location to the memory card. Open app, see Preferences. Set a schedule, and forget it.
Worth setting this from @Kyle_Rankin, too.
1 Like
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 while tar 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.
2 Likes
Backups (in both cases) should be done when the phone is not really in use, at least /home/purism is quite.
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.
Yes depending on a new file created after the backup would be operator error. If it is habitual I would call it an undocumented procedural error.
The problem is when the operator is a part of the OS. You can’t eliminate that on a running system, and attempting backups on a running system without knowing the guarantees of running software is the error.