Recovery starts with the Live USB
You ran dnf upgrade on a Friday afternoon. Monday morning, the screen shows a black cursor and a dracut emergency shell. Or the disk controller threw a warning and the filesystem is now read-only. You need to get back to a working state. The path depends entirely on what you backed up and how the system broke.
Boot the Fedora Live USB before you panic. The broken system cannot save itself. You need a working environment to inspect the disk, mount partitions, and run recovery tools. Insert the USB, reboot, and select the boot option for the Live environment. If your firmware offers a boot menu, use it. If not, interrupt the boot process and select the USB from the firmware setup.
What breaks when the system fails
A broken system usually means one of three things: the bootloader lost track of the kernel, the root filesystem has corruption that prevents mounting, or a package update left the system in an inconsistent state. Recovery is just reversing the damage.
The boot chain is a sequence of handoffs. UEFI loads GRUB. GRUB loads the kernel and the initramfs. The initramfs mounts the root filesystem and hands control to systemd. A restore operation must satisfy every stage. If you restore files but leave a stale initramfs, the kernel cannot mount the root. If you restore the root but miss the EFI partition, GRUB cannot find the kernel. Map the failure to the boot stage. The fix follows the break.
Restoring with Timeshift
Timeshift is the standard tool for system snapshots on Fedora. It captures the state of the filesystem at a point in time. If you took a snapshot before the failure, you can roll back to that state.
Boot the Live USB and open a terminal. Install Timeshift in the live environment. The live system is ephemeral, so the installation goes to RAM and disappears on reboot. This is normal.
sudo dnf install -y timeshift
# Install timeshift in the live environment. The package manager resolves dependencies from the repos.
sudo timeshift --list
# List available snapshots to verify the backup is readable and identify the snapshot ID.
Locate the snapshot you want to restore. The list shows the date, time, and description. Note the snapshot ID. Identify the target partition. Use lsblk to find the root partition. It is usually the largest partition on the boot drive.
sudo timeshift --restore --snapshot '2024-05-20_14-30-00' --target /dev/nvme0n1p2
# Restore the specific snapshot to the target partition. Replace the snapshot ID and device path.
# Timeshift handles the extraction and permission restoration automatically.
Timeshift restores the filesystem state. It does not fix hardware. If the disk is failing, restore to a new drive.
Restoring Btrfs snapshots
Fedora Workstation uses Btrfs by default. Btrfs supports native subvolume snapshots. These are instant, zero-copy rollbacks. If your root filesystem is Btrfs, you can restore directly from the subvolume structure without external tools.
Boot the Live USB. Mount the Btrfs partition. Btrfs mounts the whole filesystem tree, so you access subvolumes via paths.
sudo mount /dev/nvme0n1p2 /mnt
# Mount the Btrfs partition. The mount point becomes the root of the Btrfs filesystem tree.
ls /mnt/@/home
# Verify the subvolume structure. Fedora uses @ for root and @home for home by default.
If you have a backup subvolume, create a snapshot of it to restore the root. This preserves all metadata and is faster than file-level extraction.
sudo btrfs subvolume snapshot /mnt/backup_root /mnt/@
# Create a snapshot of the backup subvolume. This is instant and preserves all metadata.
# Replace backup_root with the name of your backup subvolume.
If you used Timeshift with Btrfs, the restore command is the same as the ext4 case. Timeshift detects the filesystem type and uses the appropriate backend.
Btrfs snapshots are instant. Use them for frequent rollbacks, not long-term archives.
Restoring with rsync or tar
If you used rsync or tar to maintain a backup, you are doing a manual restore. This gives you granular control but requires more steps. You must restore files, rebuild the bootloader, and regenerate the initramfs.
Mount the target partition. Ensure the mount point matches your original installation layout. If you have a separate /boot or /home, mount those as well.
sudo mount /dev/nvme0n1p2 /mnt
# Mount the target root partition. Ensure this matches your original installation layout.
sudo rsync -aAXv --delete /path/to/backup/ /mnt/
# -a preserves permissions and attributes. -A keeps ACLs. -X keeps extended attributes.
# --delete removes files from target that are gone in backup. This ensures an exact mirror.
The -aAX flags are the gold standard for system backups. -a alone misses SELinux contexts and capabilities on some setups. Always include -AX for system restores. If you used tar, extract to the mount point with sudo tar -xzvf /path/to/backup.tar.gz -C /mnt.
Rsync restores files. It does not restore the bootloader. You must reinstall GRUB after the sync.
Rebuilding the boot chain
After restoring files, the system will not boot yet. The bootloader and initramfs need to match the current kernel and disk layout. You must enter a chroot to run commands inside the restored system.
Bind mount the virtual filesystems. The chroot needs access to devices and system info to run commands correctly.
sudo mount --bind /dev /mnt/dev
# Bind mount devices. The chroot needs access to block devices and other hardware interfaces.
sudo mount --bind /proc /mnt/proc
# Bind mount proc. The chroot needs access to process information and kernel parameters.
sudo mount --bind /sys /mnt/sys
# Bind mount sysfs. The chroot needs access to hardware topology and driver information.
sudo chroot /mnt
# Enter the restored system environment. Commands now run as if you booted the installed OS.
Regenerate the initramfs. This ensures the initrd contains the correct drivers for your hardware and filesystem. If you restored from an old backup, the kernel might be newer than the initramfs.
dracut --force
# Regenerate the initramfs. This rebuilds the initrd for the current kernel.
# --force overwrites the existing initrd even if it appears up to date.
Reinstall the bootloader. Fedora uses UEFI on most modern hardware. The command differs for BIOS and UEFI. Check your firmware type. If you have an EFI System Partition, use the UEFI target.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi
# Install GRUB for UEFI systems. The efi-directory points to the mounted EFI System Partition.
# This writes the bootloader to the ESP and registers it with the firmware.
grub2-mkconfig -o /boot/grub2/grub.cfg
# Regenerate the GRUB configuration. This scans for kernels and updates menu entries.
exit
# Exit the chroot. You are back in the Live environment.
Reboot before you debug. Half the time the symptom is gone once the bootloader and initramfs are fresh.
Fixing SELinux contexts
Restoring files with rsync or tar can drift SELinux contexts. If you restored from a backup taken on a different system or with different package versions, contexts might not match the current policy. SELinux denials will prevent services from starting.
Run restorecon to relabel files to their default contexts. This fixes denials caused by file permission drift.
sudo chroot /mnt
# Enter the chroot again if you exited.
restorecon -Rv /
# Relabel all files to their default SELinux contexts. This fixes denials caused by file permission drift.
# -R processes directories recursively. -v prints files that are relabeled.
exit
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux hides the problem and reduces security. Fix the context instead.
Run restorecon after any manual file restore. SELinux denials are the silent killer of recovered systems.
Verify the recovery
Reboot the system. Remove the Live USB. Watch the boot process. If the system starts normally, log in and check the logs.
journalctl -b -p 3
# Show errors from the current boot. If this is empty, the system recovered cleanly.
systemctl list-units --failed
# List any units that failed to start. Investigate these if services are missing.
If you see errors, check the specific unit. Use journalctl -xeu <unit> to get detailed logs and explanatory text. The x flag adds explanations and the e flag jumps to the end. Most sysadmins type this muscle-memory style.
Run journalctl first. Read the actual error before guessing.
Common pitfalls
Restoring to the wrong partition overwrites data. Always verify the partition layout with lsblk before mounting or writing. Look for the partition size and filesystem type to confirm you have the right target.
Missing the EFI partition breaks UEFI boot. If you restore the root but skip the EFI System Partition, GRUB cannot load. Ensure you mount /boot/efi and include it in your restore process if your backup covers the whole disk.
Initramfs mismatch causes dracut emergency shell. If the kernel in the backup is different from the initramfs, the system cannot mount the root. Always run dracut --force after a restore.
SELinux denials block services. If you restore files without preserving contexts, services like sshd or httpd may fail to start. Run restorecon -Rv / after the restore.
Config drift in /etc. Files in /etc are user-modified. Files in /usr/lib ship with packages. If your backup is old, restoring /etc might overwrite changes you made after the backup. Check /etc after restore and merge changes if needed.
Check lsblk twice. Mounting the backup to the wrong partition overwrites your data.
Choose your recovery tool
Use Timeshift when you want a one-command rollback to a known-good state after a bad update.
Use Btrfs subvolume snapshots when your root filesystem is Btrfs and you need instant rollbacks without external tools.
Use rsync when you require granular control over file selection and are restoring to a different disk layout.
Use tar when you are archiving the system for cold storage and plan to restore on hardware with a different architecture.
Stay on the Live USB if the installed system cannot mount the root filesystem due to severe corruption.