What software are you using that backs up the system state (not just files)?
Current backups using Duplicity seem to have the files, but lost the system state.
Something that allows a snapshot/rollback feature if something goes wrong, would be ideal.
Easy, SYSGEN to tape! Boots the system cold from tape to the config state at time written to tape. Can also be used to build whole new systems with replacement hardware:
:JOB SYSGTAPE,MANAGER.SYS,PUB.
Priority = ES; Inpri = 8; Time = UNLIMITED seconds.
Job number = #j40.
SAT, NOV 20, 2021, 11:44 PM.
HP3000 Release: C.65.00 User Version: C.65.00
MPE/iX HP31900 C.25.06 Copyright Hewlett-Packard 1987.
All rights reserved.
STREAMED BY TRACY,MANAGER.SYS (#S1) ON LDEV# 20
STREAM DATE: SAT, NOV 20, 2021, 11:44 PM
+-------------------------------------------------+
| WELCOME TO THE EMPIRE MACHINE |
| Other games suspended unless requested. |
| EMPIRE5 started 21 JUN 2021 expires 21 JUN 2022 |
+-------------------------------------------------+
- MILLBORN GAME REQUIRES AN HP TERMINAL EMULATOR -
:COMMENT STREAM FILE $OLDPASS
:COMMENT STREAMED BY TRACY,MANAGER.SYS,PUB ON LDEV 20
:COMMENT RUNNING PROGRAM MAIN.PUB.VESOFT
:COMMENT ON SAT, NOV 20, 2021, 11:44 PM
:FILE SYSGTAPE;DEV=7
:CONTINUE
:SYSGEN
SYSGEN version E.03.03 : catalog version E.03.03 SAT, NOV 20, 2021, 11:44 PM
Copyright 1987 Hewlett-Packard Co. All Rights Reserved.
**note** Retrieving NMMGR configuration data...
** First level command **
io log (lo) misc (mi) spu (sp)
sysfile (sy)
basegroup (ba) keep(ke) permyes (pe) show (sh)
tape (ta)
clear (cl)(c) exit (ex)(e) help (he)(h) oclose (oc)
redo
sysgen> TAPE VERBOSE;STORE=^SLTLIST.JOB.SYS
redo
sysgen> TAPE VERBOSE;STORE=^SLTLIST.JOB.SYS
143 non-user files will be written to tape
dumping TAPEIPL.MPEXL.SYS to tape
dumping ISL.MPEXL.SYS to tape
dumping UPDATE.MPEXL.SYS to tape
dumping INSTALL.MPEXL.SYS to tape
dumping DISCUTIL.MPEXL.SYS to tape
dumping ODE.MPEXL.SYS to tape
dumping ODEDATA.MPEXL.SYS to tape
dumping A1002AI.MPEXL.SYS to tape
dumping A1002AM.MPEXL.SYS to tape
(remaining files not shown for brevity)
STORE/RESTORE VERSION C.65.26 (C) 1986 HEWLETT-PACKARD CO.
SYSGEN ^SLTLIST.JOB.SYS;*SYSGTAPE;LDEV=7;REELNUM=1;SLTDATE=62276;TIME=388829704
SAT, NOV 20, 2021, 11:49 PM
:RUN TAPECTRL.PUB.ORBIT;INFO="E,7"
TapeCtrl.3.02
Ejecting LDev 7...
LDev 7 ejected.
END OF PROGRAM
:EOJ
CPU sec. = 333. elapsed min. = 19. SUN, NOV 21, 2021, 12:03 AM.Thatās probably written in ALGOL. Wonāt run on flimsy modern hardware. Do you happen to know a real solution?
It was straight faced humor on my part.
Sadly no. And I suspect it was written in C, because it is native 32 bit for the OS.
Although in Jan Iāll be coming out of retirement to support a client with 250+ such systems. For them, it is real.
What system state other than files are you referring to??
There may be firmware and other flashed settings (in theory).
Obviously the contents of RAM are system state other than files but ā¦
Purism actively tries to avoid loading firmware from disk. Hence even if the system state including firmware could be saved, Purism tries to avoid allowing the firmware to be restored. For example, āyourā snapshot/rollback is someone elseās low level system compromise.
ā¦All the configuration files.
I recently restored Duplicity backup, and while my data files where there, the config files werenāt. I set it to backup the home folder. Not sure how it decides what files to backup and which to not, but it seems it didnāt get the config files.
Iām looking at moving to Timeshift to solve the problem.
Anyone else using this? Your experience?
At random levels of difficulty:
I presume this solution will make a bootable clone? But the downside is it has to copy the entire hd every- ime, not just modified files, correct?
(In a pinch if my primary system goes down, while getting it back up, a bootable clone from external HD would at least give me a working desktop, while I recover the primary drive.)
All of those solutions would make a bootable copy, but this one is simplest to copy/restore.
But the downside is that it will scan the entire drive, yes.
Yes. Hence, for example, a clone that is directly usable on another computer (of the same architecture) or on the same computer.
True.
So you have three options.
They each have their own advantages and disadvantages.
The upside of the first option is that the total amount of time to do the backup is quite consistent. It nearly always would take longer than either of the other two options but is consistently slow.
Another upside of the first option is that it works without regard to what technology is used to represent the partitions on the drive and what type of file system is on the partition(s).
A complication is how encryption interacts with your backup methodology. Letās suppose that your root file system is encrypted. If you use dd then you can backup without entering the decryption key (without even knowing it) and the backup copy is not a security risk (it is no more and no less penetrable than the original). However if one of the reasons to do backup is in case you forget or lose your encryption key then the backup is then useless for that purpose. By contrast, if you backup the decrypted contents of a disk then the backup copy becomes a security risk. You need to protect the backup copy in some way.
You can partially mitigate the issue of backing up the entire disk by piping dd through gzip. So you read the entire disk but often would not have to write the entire disk to the backup medium (because if most of the disk is āemptyā, it will compress down to almost nothing). The downside of that is that you lose the ability to have a directly usable clone. If you needed to actually use a clone then you would have to restore it to a disk first. Again, there are interactions with encryption.
I use dd to backup my x86 computers and dd | gzip to backup my ARM computers (including the Librem 5).
PS You can probably disregard my previous reply because I completely misunderstood the distinction that you were making. (Perhaps the Duplicity documentation covers the answer to your question.)
Iāve used Timeshift on an Arch-variant with an unencrypted Ext4 drive and found it easy to use. Did one successful system restore just to see if it worked.
Iām considering using it again on Byzantium but am encountering the occasional anecdote of people having problems using it to backup a system on a LUKS drive (problem is at time of restore). Here is one guide I found for restoring from Timeshift on LUKS Ext4 drives using live media.
Did you try Timeshift? Working for you?
Anyone using Timeshift with LUKS/Ext4 on PureOS?
Would LUKS + BTRFS + Timeshift be preferable?
Any other methods for system backup/rollsbacks?
Thanks
I did a cursory test with Timeshift. It worked on an unencrypted drive.
Iāll do another full test once Iāve finished the transition to Qubes, this time on an encrypted drive.
If it canāt reliably handle encrypted drives, then its a now go.
I vouch for this solution, btrfs specifically. System states can be saved by simply creating readonly snapshots (which can later be turned back into rw). Backups (using btrfs send/receive) are super efficient as they only transfer differences between snapshots, not everything all the time.