[disk failure] Questions related to LEAP 15.3

Greetings,

I just had a disk failure, the linux system disk is dead and I have to remove it and reinstall.
To avoid losing so much time I wonder if it is possible to have a operating system on usb stick or DVD to be booted that is configured as a “real” OS on disk ?

I think admins call it “portable” OS or “persistent usb stick”.

In an other alternative is this possible to make a rescue disk wich conserves the settings (servers like nfs, named, mysql etc…) that could be booted on usb stick to keep on working even if the “real” system is down
the time we replace the hard disk and reinstall ?

As the system must be power-down when exchanging disks and the system must run the installer during the installation, you can not run a rescue or whatever system at the same time.

It maybe useful to run a rescue (or similar, depends on naming) from a DVD/USB -mass-storage during the time you are going to purchase the new disk. But that is up to you. You can of course install a system on e.g. an USB-mass-storage device (it is just a “disk” as any other mass-storage device) and configure that with the same configs as you like, But you still will need of course the user data (/home, maybe more) or any other data your applications (web-server?) use. Thus you can boot from such a device and then still have to restore from your latest backups before you have the “same” system as you had before.

I experienced with ubuntu a usb stick with “persistent” datas on it. so you could bring your OS with your own configuration wherever you like and boot it on computers.
Once booted you get your system like “you were at home”.

I wonder if it was possible to do this with LEAP 15.3 or 15.4.

Risks of disk failure are mitigated by backups. Incremental sending of btrfs snapshots to a different local or remote drive is an efficient way: https://forums.opensuse.org/showthread.php/575437-backup-btrfs?p=3159349#post3159349

When you have a system that is “a copy” of your “normal” system, you can boot from it and have “the same”. But of course when you just edited a file and your disk broke before a backup was made, that “reserve” system will NOT have that changed file.
(I said the same above, but in different wording. I hope you get it now, it is trivial in any case).

HDDs, SSDs & USB memory sticks are all mass storage devices. The primary difference some might say is speed, while others might say lifetimes. Because USB uses a different bus than HDD & SSD, device enumeration order can vary the device names of all these devices. Otherwise, it really doesn’t matter where you install. The usual situation is because you boot installation media on USB, the target USB will have a lower priority name. This makes it important to properly manage bootloader configuration so that when the target stick becomes the boot device, the bootloader is looking at the correct device. IOW, if you normally boot from NVME, the installation stick typically will be sda, and the target sdb. After installation is complete, you remove the installation stick, so the former target stick becomes sda, while some components of boot configuration may still be pointing to a second disk. This type of bootloader confusion is less troublesome if using UEFI booting instead of legacy/BIOS, because the newer firmware’s method of identifying the boot device is more sophisticated.

Source partition:

6700k:~ # df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       135G  8.6G  125G   7% /
6700k:~ # btrfs subvolume list -t /
ID      gen     top level       path
--      ---     ---------       ----
256     31      5               @
...
265     1654    256             @/.snapshots
266     1739    265             @/.snapshots/1/snapshot
267     94      265             @/.snapshots/2/snapshot
...
290     1563    265             @/.snapshots/25/snapshot
291     1631    265             @/.snapshots/26/snapshot
6700k:~ # 

Full backup:

6700k:~ # **btrfs subvolume create /backup/.snapshots/**
Create subvolume '/backup/.snapshots' 
6700k:~ # **mkdir /backup/.snapshots/2** 
6700k:~ # ****time btrfs send /.snapshots/2/snapshot | btrfs receive /backup/.snapshots/2/****
At subvol /.snapshots/2/snapshot 
At subvol snapshot 

**real    0m39.922s **
user    0m5.886s 
sys     0m41.274s

Incremental backup

6700k:~ # **mkdir /backup/.snapshots/26**
6700k:~ # ****time btrfs send -p /.snapshots/2/snapshot /.snapshots/26/snapshot | btrfs receive /backup/.snapshots/26**** 
At subvol /.snapshots/26/snapshot 
At snapshot snapshot 

**real    0m10.001s **
user    0m1.088s 
sys     0m10.454s 
6700k:~ # 

Destination:

6700k:~ # df -h /backup/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5        49G  7.1G   42G  15% /backup
6700k:~ # btrfs subvolume list -t /backup/
ID      gen     top level       path
--      ---     ---------       ----
278     433     5               .snapshots
279     433     278             .snapshots/2/snapshot
280     436     278             .snapshots/26/snapshot
6700k:~ # 

The gecko linux (it is OpenSUSE) allows the USB to be persistant just “dd” the image to a USB drive. It is available as 15.4 or Tumbleweed. I use this for disaster recovery and have one in my pocket - never know when you might need it.,

Thanks larryr and all you guys, I will install a 15.4 on the system this week-end.
Then I will backup the system on another partition (I hope it will be possible to hide it in GRUB2 to not have it in the boot menu).
Once done, I will try to make the necessary to have a “bootable portable” USB stick with my re-configured system (I have the whole backups so it won’t be a burden but relabel the partitions correctly and modify /etc/fstab in consequence).

The services on this computer were: nfsd, named, cupsd, mysqld (replication), and I think it was all… yes it worked also as a firewall but a cheap one ^^

I’ve lost 0% of crucial datas only the OS was on the disk that died after 17 years of zealous services !! (factory date 2005).