0

I have btrfs over luks over lvm on a physical ssd drive. I've done some crap with apt and break my system. I want to reverse it to previous state.

When i boot on a live usb and decipher my luks drive and mount btrfs partition, here what i get

# btrfs subvolume list ./ (when in my luks drive) :
ID 256 gen 202072 top level 5 path @
ID 257 gen 202063 top level 256 path @/home
ID 258 gen 202063 top level 256 path @/var
ID 259 gen 202072 top level 256 path @/.snapshots
ID 271 gen 185 top level 259 path @/.snapshots/12/snapshot
[...]
ID 1739 gen 202073 top level 259 path @/.snapshots/1480/snapshot
[...]

I want to restore the ID 1739 snapshot over @ to reboot my system on it with /home and /var mounted in it.

How can i do that ? (i've read some of the btrfs doc and some stuff online but nothing that match what i want)

I don't understand if restore is the good option, or if i should use btrfs send/receive or btrfs sub snapshot. Restore require the partion to be unmounted, but i don't understand what target it wait for. and if i move @ to breaked_@ and run btrfs sub snapshot breaked_@/.snapshots/1480/snapshot/ @ in the mounted btrfs root, it create me an @ without .snapshots subfolder nor @/home nor @/var. What should i do ?

btrfs restore -D -t 1480 /dev/disk/by-uuid/ede[...] ./@ of course don't work, or because it's mounted, or because when it's not mount, ./@ doesn't exist. In this case it fail this way :

ERROR: tree block bytenr 1480 is not aligned to sectosize 4096
couldn't read tree root
could no open root, trying backup super

And the same if i try it with 1739 instead of 1480.

(I also tryed to use timeshift but with luks encrypted drive, it doesn't understand anything).

Move the root from one subvolume to another in BTRFS is the nearest case i found, but if i copy the snapshot content, it will be added to what's already in @, and if i delete @ before copying i'm afraid to delete all snapshots with it.

This question is similar to How to rollback a btrfs snapshot for root [ / ] after failed system update so any answer on one side will probably resolve the two questions. But no reponse since 2 year, i post mine with it's specificity and extra details. I hope to have more luck with the community. I've also posted it on github btrfs-progs repository issue system.

To better understand how all of this should work, here is the /etc/fstab of the crashed system (inside btrfs root partition) :

/dev/mapper/vgmint-root   /           btrfs   subvolid=256,subvol=/@,rw,relatime,compress=lzo,ssd,space_cache=v2   0 0
# /boot was on /dev/nvme0n1p2 during installation
UUID=f4ea[...]            /boot       ext4   defaults   0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=4773-82E0            /boot/efi   vfat   umask=0077 0 1
/dev/mapper/vgmint-swap   1 none      swap   sw         0 0

btrfs subvolume list /mnt/ full result :

ID 256 gen 202080 top level 5 path @
ID 257 gen 202080 top level 256 path @/home
ID 258 gen 202080 top level 256 path @/var
ID 259 gen 202072 top level 256 path @/.snapshots
ID 271 gen 185 top level 259 path @/.snapshots/12/snapshot
ID 669 gen 32079 top level 259 path @/.snapshots/410/snapshot
ID 1103 gen 82780 top level 259 path @/.snapshots/844/snapshot
ID 1104 gen 82781 top level 259 path @/.snapshots/845/snapshot
ID 1125 gen 84805 top level 259 path @/.snapshots/866/snapshot
ID 1180 gen 95864 top level 259 path @/.snapshots/921/snapshot
ID 1357 gen 142396 top level 259 path @/.snapshots/1098/snapshot
ID 1358 gen 142498 top level 259 path @/.snapshots/1099/snapshot
ID 1384 gen 146456 top level 259 path @/.snapshots/1125/snapshot
ID 1400 gen 147708 top level 259 path @/.snapshots/1141/snapshot
ID 1467 gen 155992 top level 259 path @/.snapshots/1208/snapshot
ID 1468 gen 156011 top level 259 path @/.snapshots/1209/snapshot
ID 1476 gen 156421 top level 259 path @/.snapshots/1217/snapshot
ID 1477 gen 156423 top level 259 path @/.snapshots/1218/snapshot
ID 1508 gen 160880 top level 259 path @/.snapshots/1249/snapshot
ID 1522 gen 162353 top level 259 path @/.snapshots/1263/snapshot
ID 1564 gen 171472 top level 259 path @/.snapshots/1305/snapshot
ID 1588 gen 176804 top level 259 path @/.snapshots/1329/snapshot
ID 1612 gen 182891 top level 259 path @/.snapshots/1353/snapshot
ID 1625 gen 184737 top level 259 path @/.snapshots/1366/snapshot
ID 1626 gen 184738 top level 259 path @/.snapshots/1367/snapshot
ID 1627 gen 184744 top level 259 path @/.snapshots/1368/snapshot
ID 1628 gen 184747 top level 259 path @/.snapshots/1369/snapshot
ID 1629 gen 184755 top level 259 path @/.snapshots/1370/snapshot
ID 1630 gen 184757 top level 259 path @/.snapshots/1371/snapshot
ID 1631 gen 184765 top level 259 path @/.snapshots/1372/snapshot
ID 1632 gen 184767 top level 259 path @/.snapshots/1373/snapshot
ID 1633 gen 184785 top level 259 path @/.snapshots/1374/snapshot
ID 1634 gen 184786 top level 259 path @/.snapshots/1375/snapshot
ID 1635 gen 184809 top level 259 path @/.snapshots/1376/snapshot
ID 1637 gen 184872 top level 259 path @/.snapshots/1378/snapshot
ID 1638 gen 184909 top level 259 path @/.snapshots/1379/snapshot
ID 1639 gen 184910 top level 259 path @/.snapshots/1380/snapshot
ID 1643 gen 185306 top level 259 path @/.snapshots/1384/snapshot
ID 1644 gen 185307 top level 259 path @/.snapshots/1385/snapshot
ID 1645 gen 185310 top level 259 path @/.snapshots/1386/snapshot
ID 1646 gen 185314 top level 259 path @/.snapshots/1387/snapshot
ID 1647 gen 185315 top level 259 path @/.snapshots/1388/snapshot
ID 1648 gen 185317 top level 259 path @/.snapshots/1389/snapshot
ID 1651 gen 185646 top level 259 path @/.snapshots/1392/snapshot
ID 1665 gen 187383 top level 259 path @/.snapshots/1406/snapshot
ID 1682 gen 189636 top level 259 path @/.snapshots/1423/snapshot
ID 1706 gen 192710 top level 259 path @/.snapshots/1447/snapshot
ID 1720 gen 194266 top level 259 path @/.snapshots/1461/snapshot
ID 1736 gen 196318 top level 259 path @/.snapshots/1477/snapshot
ID 1739 gen 202073 top level 259 path @/.snapshots/1480/snapshot
ID 1740 gen 196753 top level 259 path @/.snapshots/1481/snapshot
ID 1741 gen 196775 top level 259 path @/.snapshots/1482/snapshot
ID 1742 gen 196784 top level 259 path @/.snapshots/1483/snapshot
ID 1743 gen 196862 top level 259 path @/.snapshots/1484/snapshot
ID 1744 gen 196866 top level 259 path @/.snapshots/1485/snapshot
ID 1745 gen 196868 top level 259 path @/.snapshots/1486/snapshot
ID 1746 gen 196869 top level 259 path @/.snapshots/1487/snapshot
ID 1747 gen 196878 top level 259 path @/.snapshots/1488/snapshot
ID 1748 gen 196886 top level 259 path @/.snapshots/1489/snapshot
ID 1749 gen 196901 top level 259 path @/.snapshots/1490/snapshot
ID 1750 gen 196902 top level 259 path @/.snapshots/1491/snapshot
ID 1778 gen 199404 top level 259 path @/.snapshots/1519/snapshot
ID 1791 gen 200900 top level 259 path @/.snapshots/1532/snapshot
ID 1792 gen 201015 top level 259 path @/.snapshots/1533/snapshot
ID 1793 gen 201131 top level 259 path @/.snapshots/1534/snapshot
ID 1794 gen 201246 top level 259 path @/.snapshots/1535/snapshot
ID 1795 gen 201361 top level 259 path @/.snapshots/1536/snapshot
ID 1796 gen 201476 top level 259 path @/.snapshots/1537/snapshot
ID 1797 gen 201591 top level 259 path @/.snapshots/1538/snapshot
ID 1798 gen 201706 top level 259 path @/.snapshots/1539/snapshot
ID 1799 gen 201821 top level 259 path @/.snapshots/1540/snapshot
ID 1800 gen 201936 top level 259 path @/.snapshots/1541/snapshot
ID 1801 gen 202051 top level 259 path @/.snapshots/1542/snapshot
ID 1802 gen 202079 top level 5 path tmp_@

tmp_@ is the result of my previous attemp to recover the system. I probably can delete it. (it don't have /home and /var populated).

3
  • Only Ubuntu and official flavors of Ubuntu are on-topic here, refer askubuntu.com/help/on-topic where you'll find other SE sites where you question will be welcome if you don't want to use a Linux Mint forum. (One advantage of Ubuntu is it's many support options, you opted for Linux Mint so take advantage of its support options, or SE Unix & Linux found in the on-topic link)
    – guiverc
    Mar 15, 2023 at 4:42
  • 2
    It seems you lack a lot of general knowledge about the BTRFS filesystem. I strongly recommend to you to read the official documentation. Trying out just some commands you've found somewhere in the internet might destroy all of your data. I'll write a short tutorial soon, but you probably need to do some additional research.
    – paladin
    Mar 15, 2023 at 9:32
  • You could try the following: 1. Backup your entire BTRFS volume, 2. mount your BTRFS volume with mount --options subvolid=256,noatime /mnt/ on another OS, 3. do a cd /mnt/ and delete all directories and files, which are not /home, /var nor /.snapshots 4. do a cp -a /mnt/.snapshots/1480/snapshot/* /mnt/. && echo done || echo failure (This will take up a lot of time to do, depending on the amount of data.), 5. umount /mnt/, reboot and hope for the best.
    – paladin
    Mar 16, 2023 at 8:07

1 Answer 1

2

btrfs restore, btrfs send, btrfs receive are all the wrong commands. What you need to understand first, all snapshots are by-default read-only subvolumes. Only the current, active "snapshot" (default subvolume) is marked writeable. So what you need to do is to change the default subvolume to the subvolume of your desired snapshot, make the subvolume of your desired snapshot writeable and delete all "newer"/"younger" snapshots to prevent irritation.

Important Hints: snapshot ID is unequal to subvolume ID and this tutorial is not tested

Another Hint: in regular you would use the linux programm snapper to roll back to former snapshots, but personally I had not so good experiences with this program, but you should give it a try, but also here, backup first your data

  1. make a complete backup of your entire BTRFS volume (strongly recommended)
  2. mount your BTRFS filesystem from another operating system with the following command mount --options subvolid=5,noatime /dev/mapper/lvm/encrypted_btrfs /mnt/ (you need to change /dev/mapper/lvm/encrypted_btrfs to your actual path)
  3. get the default subvolume by using command btrfs subvolume get-default /mnt/ and remember the ID and path of the current default subvolume (on my system the default subvolume ID is 259 and path is @/.snapshots/1/snapshot)
  4. let us name a variable for the default subvolume path as DSPATH=$(btrfs subvolume get-default /mnt/ | cut --delimiter=@ --fields=2)
  5. double check the ro-flag of the current default subvolume with btrfs property get -ts /mnt/@$DSPATH, it should print ro=false
  6. let us name another variable for your future new default subvolume path as NEWDSPATH=$(btrfs subvolume list /mnt/ | grep -F "ID 1739" | cut --delimiter=@ --fields=2)
  7. double check again the ro-flag, but this time of your future new default subvolume with btrfs property get -ts /mnt/@$NEWDSPATH, it should print ro=true
  8. temporary make the BTRFS-ROOT subvolume your default subvolume with btrfs subvolume set-default 5 /mnt/ (the subvolume with ID 5 is always the BTRFS-ROOT subvolume)
  9. delete all subvolumes of "snapshots" which are younger/newer (have a greater snapshot number than your desired snapshot) with btrfs subvolume delete /mnt/@/.snapshots/GREATER-THAN-1480/snapshot and also delete your former default subvolume with btrfs subvolume delete /mnt/@$DSPATH
  10. make your future new default subvolume writeable with btrfs property set -ts /mnt/@$NEWDSPATH ro false
  11. now really make your future new default subvolume the default subvolume with btrfs subvolume set-default 1739 /mnt/
  12. umount with umount /mnt, reboot with your original operating system and pray that it works

Hint: It might be necessary to rename the snapshot directory name of the directory where your new default subvolume is stored and/or to edit some of the snapper configuration files, otherwise snapper (the linux program which manages snapshots) might go into an error, because it cannot find some of the snapshots. If you are unlucky, this also might result into a system start error, which prevents to boot the system.

6
  • btrfs subvolume get-default /mnt/ return : ID 5 (FS_TREE) and so, DSPATH is not a path.
    – 1000i100
    Mar 15, 2023 at 22:05
  • That means that your current default "subvolume" is the BTRFS-ROOT subvolume itself (that's the default value for BTRFS). Would you please post your /etc/fstab file in your original post?
    – paladin
    Mar 15, 2023 at 22:16
  • fstab is added to the original post, and i also update btrfs subvolume list /mnt/ result.
    – 1000i100
    Mar 15, 2023 at 22:39
  • I see, if that's the untouched orignal fstab, that would mean that your operating system had not setup snapper and thus snapshots for BTRFS in a proper way. Have you manually installed snapper? Please also post the complete result of btrfs subvolume list /mnt/, after mounting mount --options subvolid=5,noatime /dev/mapper/vgmint-root /mnt/.
    – paladin
    Mar 15, 2023 at 22:53
  • I don't remember having installed any versionning software. timeshift is by default on linux mint, but not compatible with my setup. I perhaps have snapper installed, how can i verify that ?
    – 1000i100
    Mar 16, 2023 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .