Cannot Create Timeshift Backup on BTRFS with Root Subvolume Configuration Issue

“I’m trying to set up Timeshift to back up my Garuda Linux system onto a secondary BTRFS drive, but I’m encountering an error: Cannot create Timeshift Backup on BTRFS: system disk with root subvolume (@). My /etc/fstab file is configured with multiple BTRFS subvolumes for /, /home, /root, etc., but Timeshift doesn’t seem to recognize them properly. I’ve already tried creating a specific @timeshift subvolume on the backup drive and editing the fstab entry to match, but the error persists. I would appreciate any guidance on how to correctly set up Timeshift with BTRFS subvolumes for backup. Thank you!”

garuda-inxi
System:
Kernel: 6.11.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=400c2f0d-8924-468c-8c78-7fcabce37e16 rw rootflags=subvol=@
quiet loglevel=3 ibt=off
Desktop: KDE Plasma v: 6.2.3 tk: Qt v: N/A info: frameworks v: 6.8.0
wm: kwin_wayland vt: 1 dm: SDDM Distro: Garuda base: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: TUF Z370-PLUS GAMING v: Rev X.0x
serial: <superuser required> part-nu: SKU uuid: <superuser required>
UEFI: American Megatrends v: 3004 date: 07/12/2021
CPU:
Info: model: Intel Core i7-8700K bits: 64 type: MT MCP arch: Coffee Lake
gen: core 8 level: v3 note: check built: 2018 process: Intel 14nm family: 6
model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xF8
Topology: cpus: 1x dies: 1 clusters: 6 cores: 6 threads: 12 tpc: 2
smt: enabled cache: L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB
desc: 6x256 KiB L3: 12 MiB desc: 1x12 MiB
Speed (MHz): avg: 800 min/max: 800/4700 scaling: driver: intel_pstate
governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800
8: 800 9: 800 10: 800 11: 800 12: 800 bogomips: 88796
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities: <filter>
Graphics:
Device-1: NVIDIA TU106 [GeForce RTX 2070] vendor: Micro-Star MSI
driver: nvidia v: 565.57.01 alternate: nouveau,nvidia_drm non-free: 550.xx+
status: current (as of 2024-09; EOL~2026-12-xx) arch: Turing code: TUxxx
process: TSMC 12nm FF built: 2018-2022 pcie: gen: 3 speed: 8 GT/s
lanes: 16 ports: active: none off: DP-1,HDMI-A-1 empty: DP-2,DP-3
bus-ID: 01:00.0 chip-ID: 10de:1f02 class-ID: 0300
Device-2: Logitech Webcam C270 driver: snd-usb-audio,uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-5:2 chip-ID: 046d:0825
class-ID: 0102 serial: <filter>
Display: wayland server: X.org v: 1.21.1.14 with: Xwayland v: 24.1.4
compositor: kwin_wayland driver: X: loaded: nvidia unloaded: modesetting
alternate: fbdev,nouveau,nv,vesa gpu: nvidia d-rect: 4480x2520
display-ID: 0
Monitor-1: DP-1 pos: primary,top-left res: 2560x1440 size: N/A modes: N/A
Monitor-2: HDMI-A-1 pos: bottom-r res: 1920x1080 size: N/A modes: N/A
API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia wayland: drv: nvidia
x11: drv: nvidia inactive: device-1
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 565.57.01
glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
memory: 7.81 GiB display-ID: :1.0
API: Vulkan v: 1.3.295 layers: 1 device: 0 type: discrete-gpu
name: NVIDIA GeForce RTX 2070 driver: nvidia v: 565.57.01
device-ID: 10de:1f02 surfaces: xcb,xlib,wayland
Audio:
Device-1: Intel 200 Series PCH HD Audio vendor: ASUSTeK
driver: snd_hda_intel v: kernel alternate: snd_soc_avs bus-ID: 00:1f.3
chip-ID: 8086:a2f0 class-ID: 0403
Device-2: NVIDIA TU106 High Definition Audio vendor: Micro-Star MSI
driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
bus-ID: 01:00.1 chip-ID: 10de:10f9 class-ID: 0403
Device-3: Logitech Webcam C270 driver: snd-usb-audio,uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-5:2 chip-ID: 046d:0825
class-ID: 0102 serial: <filter>
Device-4: HP HyperX QuadCast driver: hid-generic,snd-usb-audio,usbhid
type: USB rev: 1.1 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-6:3
chip-ID: 03f0:0491 class-ID: 0300 serial: <filter>
Device-5: SteelSeries ApS Arctis 7
driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
lanes: 1 mode: 1.1 bus-ID: 5-2.4:4 chip-ID: 1038:12ad class-ID: 0300
API: ALSA v: k6.11.6-zen1-1-zen status: kernel-api tools: N/A
Server-1: PipeWire v: 1.2.6 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: kernel
port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15b8 class-ID: 0200
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: <filter>
IF-ID-1: docker0 state: down mac: <filter>
Info: services: NetworkManager, sshd, systemd-timesyncd
Bluetooth:
Device-1: TP-Link UB500 Adapter driver: btusb v: 0.8 type: USB rev: 1.1
speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 5-2.3.3:8 chip-ID: 2357:0604
class-ID: e001 serial: <filter>
Report: btmgmt ID: hci0 rfk-id: 0 state: down bt-service: enabled,running
rfk-block: hardware: no software: no address: <filter> bt-v: 5.1 lmp-v: 10
status: discoverable: no pairing: no
Drives:
Local Storage: total: 2.28 TiB used: 526.14 GiB (22.6%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Kingston model: SKC3000S1024G
size: 953.87 GiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: EIFK51.2 temp: 29.9 C
scheme: GPT
ID-2: /dev/nvme1n1 maj-min: 259:2 vendor: Samsung model: SSD 970 EVO 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: 2B2QEXE7 temp: 30.9 C
scheme: GPT
ID-3: /dev/sda maj-min: 8:0 vendor: KIOXIA model: EXCERIA SATA SSD
size: 223.57 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
tech: SSD serial: <filter> fw-rev: 15.5 scheme: GPT
ID-4: /dev/sdb maj-min: 8:16 vendor: OCZ model: TRION100 size: 223.57 GiB
block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s tech: SSD
serial: <filter> fw-rev: 11.2 scheme: GPT
Partition:
ID-1: / raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
used: 17.3 GiB (7.7%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
used: 584 KiB (0.2%) fs: vfat dev: /dev/sda1 maj-min: 8:1
ID-3: /home raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
used: 17.3 GiB (7.7%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-4: /var/log raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
used: 17.3 GiB (7.7%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-5: /var/tmp raw-size: 223.27 GiB size: 223.27 GiB (100.00%)
used: 17.3 GiB (7.7%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 46.98 GiB used: 0 KiB (0.0%) priority: 100
comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 12 dev: /dev/zram0
Sensors:
System Temperatures: cpu: 33.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Memory: total: 48 GiB available: 46.98 GiB used: 4.74 GiB (10.1%)
Processes: 371 Power: uptime: 2m states: freeze,mem,disk suspend: deep
avail: s2idle wakeups: 0 hibernate: platform avail: shutdown, reboot,
suspend, test_resume image: 18.74 GiB services: org_kde_powerdevil,
power-profiles-daemon, upowerd Init: systemd v: 256 default: graphical
tool: systemctl
Packages: pm: pacman pkgs: 1422 libs: 388 tools: octopi,paru Compilers:
gcc: 14.2.1 Shell: garuda-inxi default: fish v: 3.7.1 running-in: konsole
inxi: 3.3.36
Garuda (2.6.26-1):
System install date:     2024-11-04
Last full system update: 2024-11-09
Is partially upgraded:   No
Relevant software:       timeshift NetworkManager dracut nvidia-dkms
Windows dual boot:       Probably (Run as root to verify)
Failed units:
❯ cat /etc/fstab
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=F95B-D5C5                              /boot/efi               vfat                    umask=0077                             0 2
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /                       btrfs                   subvol=/@,noatime,compress=zstd        0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /home                   btrfs                   subvol=/@home,noatime,compress=zstd    0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /root                   btrfs                   subvol=/@root,noatime,compress=zstd    0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /srv                    btrfs                   subvol=/@srv,noatime,compress=zstd     0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /var/cache              btrfs                   subvol=/@cache,noatime,compress=zstd   0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /var/log                btrfs                   subvol=/@log,noatime,compress=zstd     0 0
UUID=400c2f0d-8924-468c-8c78-7fcabce37e16   /var/tmp                btrfs                   subvol=/@tmp,noatime,compress=zstd     0 0
tmpfs                                       /tmp                    tmpfs                   noatime,mode=1777                      0 0
/dev/nvme1n1p1                              /home/shyuuhei/Game     ntfs                    nofail                                 0 0
/dev/nvme0n1p1                              /home/shyuuhei/Backup   btrfs                   subvol=/@timeshift,noatime,nodiratime,nofail              0 0

I don’t think it is possible, although we removed it since a long time.
See here, also in the links.

4 Likes

The message in your screenshot says this is not supported.

Is there some reason you do not want to use Snapper for this purpose? It is preconfigured in Garuda Linux, with automatic snapshots, bootable snapshots in the Grub menu, etc. You can easily modify your snapshot configuration with Btrfs Assistant if you want to make changes.

5 Likes

I’m actually new to Linux. I don’t know which one is better. All I want to do is backup it to a second disk.

Thanks for your comment

1 Like

A Btrfs snapshot can only be created within the same Btrfs filesystem. When you take a snapshot, you aren’t actually saving another copy of the filesystem or anything like that…rather, you are kind of saying to the filesystem, “Please remember the exact state the filesystem is in at this moment.”

Another disk can’t do this; since it isn’t part of the filesystem, it can’t “remember” the state of it. You can join multiple disks into a single Btrfs filesystem, but I’m pretty sure that is not what you want in this case.

All that to say: for actually taking the snapshots, they need to be stored on the same disk you are snapshotting. If you want the ability to restore snapshots, you will need them to be on the same disk anyway.


For backups, you can send your snapshots (or any Btrfs subvolume) to another device using btrfs send and btrfs receive.

sudo btrfs send /path/to/snapshot | sudo btrfs receive /path/to/backup

It’s simple enough to add to scripts, systemd services, etc. It even works over SSH.

See also the relevant ArchWiki article:

https://wiki.archlinux.org/title/Btrfs#Send/receive

Send/receive

A subvolume can be sent to stdout or a file using the send command. This is usually most useful when piped to a Btrfs receive command. For example, to send a snapshot named /root_backup (perhaps of a snapshot you made of / earlier) to /backup, you would do the following:

# btrfs send /root_backup | btrfs receive /backup

The snapshot that is sent must be readonly. The above command is useful for copying a subvolume to an external device (e.g. a USB disk mounted at /backup above).

The subvolume will be created on the receiving end. It does not need to be created manually.

Another example which creates: /mnt/arch-v2/subvolumes/@var:

# btrfs send --proto 2 --compressed-data '/mnt/arch/snapshots/@var' | btrfs receive '/mnt/arch-v2/subvolumes/'

The parameters --proto 2 and --compressed-data used in the example might be useful for more efficient sending (assumes compressed data).

You can also send only the difference between two snapshots. For example, if you have already sent a copy of root_backup above and have made a new readonly snapshot on your system named root_backup_new, then to send only the incremental difference to /backup, do:

# btrfs send -p /root_backup /root_backup_new | btrfs receive /backup

Now, a new subvolume named root_backup_new will be present in /backup.

See Btrfs Wiki’s Incremental Backup page and #Incremental backup to external drive on how to use this for incremental backups and for tools that automate the process.

There is also support for incremental backups (so you are not sending a full snapshot of the filesystem with every transaction). See this article for some tools for getting started if you are interested in that: https://wiki.archlinux.org/title/Btrfs#Incremental_backup_to_external_drive

I have been using btrbk for this purpose for a couple years now and it has been excellent. Although…now that I look at the list I just linked, snap-sync and snapborg look pretty interesting. :eyes:

No worries, keep asking questions…and welcome! :wave:

4 Likes

I understand now, thank you very much. Although I can’t backup to another disk, I can send existing backups to another disk. So, when I want to move these backups to the main system, should I move them back to where the operating system is installed?

You cannot create snapshots of one disk from another disk, but you can send snapshots from one disk to another disk.

Filesystem snapshots are not backups. They are useful for some of the same things that a backup is useful for (restoring the system, recovering a lost file, etc), but should not be considered a backup because in the case of disk failure your snapshots will not help you.

By contrast, snapshots which have been copied over to another device are backups. At that point, they are no longer bound to the filesystem; they are a proper copy of your data which could be used to restore your system in the event of disk failure, filesystem corruption, loss of the device, etc.

That’s right, you can move them back to the device the same way.

sudo btrfs send /path/to/snapshot_backups | sudo btrfs receive /path/to/regular_snapshots

If you are using Snapper or Timeshift for restoring your snapshots, you can make /path/to/regular_snapshots the ordinary snapshot directory, and then restore your snapshot in the typical way.

3 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.