!!! Aborted: subvolume is readonly

[sbouniol]

Good Morning, I apologize in advance if I am asking something silly but I am just trying to backup a simple btrfs subvolume to another FS as a stream and it seems that btrbk refuse to take a snapshot of a read-only subvolume? I am probably missing something... any suggestions on how to deal with it?

my conf file:

root@HAL:/etc/btrbk# cat btrbk-ub.conf
raw_target_compress   xz
raw_target_compress_threads 2
#raw_target_encrypt    gpg
#gpg_keyring           /etc/btrbk/gpg/pubring.gpg
#gpg_recipient         btrbk@ffsb42.com
snapshot_dir            btrbk_snapshots
volume /media/BIG
  subvolume ub/dodo/190725-0610
    snapshot_dir btrbk_snapshots
    target raw /media/google-drive/btrbk/ub
     # incremental  no

my output:

root@HAL:/etc/btrbk# btrbk -c btrbk-ub.conf  -vv -l debug run
btrbk command line client, version 0.27.1  (Sat Aug  3 11:48:41 2019)
Using configuration: btrbk-ub.conf
Initializing volume section: /media/BIG
Resolving btrfs mount point for: /media/BIG
### readlink -e /media/BIG
Command execution successful
Real path for "/media/BIG" is: /media/BIG
### cat /proc/self/mountinfo
Command execution successful
Btrfs mount point for "/media/BIG": /media/BIG (mount_source=/dev/sdb1, subvolid=5)
### btrfs subvolume list -a -c -u -q -R /media/BIG
Command execution successful
Parsed 640 total subvolumes for filesystem at: /media/BIG
### btrfs subvolume list -a -r /media/BIG
Command execution successful
Parsed 631 readonly subvolumes for filesystem at: /media/BIG
### btrfs subvolume show --rootid=5 /media/BIG
Command execution successful
Parsed 11 subvolume detail items: /media/BIG
found btrfs root: /media/BIG
Initializing subvolume section: /media/BIG/ub/dodo/190725-0610
Resolving btrfs mount point for: /media/BIG/ub/dodo/190725-0610
### readlink -e /media/BIG/ub/dodo/190725-0610
Command execution successful
Real path for "/media/BIG/ub/dodo/190725-0610" is: /media/BIG/ub/dodo/190725-0610
Btrfs mount point for "/media/BIG/ub/dodo/190725-0610": /media/BIG (mount_source=/dev/sdb1, subvolid=5)
**WARNING: Skipping subvolume "/media/BIG/ub/dodo/190725-0610": subvolume is readonly**
Completed within: 1s  (Sat Aug  3 11:48:42 2019)
--------------------------------------------------------------------------------
Backup Summary (btrbk command line client, version 0.27.1)

    Date:   Sat Aug  3 11:48:41 2019
    Config: btrbk-ub.conf

Legend:
    ===  up-to-date subvolume (source snapshot)
    +++  created subvolume (source snapshot)
    ---  deleted subvolume
    ***  received subvolume (non-incremental)
    >>>  received subvolume (incremental)
--------------------------------------------------------------------------------
/media/BIG/ub/dodo/190725-0610
**!!! Aborted: subvolume is readonly**

NOTE: Some errors occurred, which may result in missing backups!
Please check warning and error messages above.

[digint]

The "subvolume" config line must be a regular (read-write) subvolume, as btrbk will make a snapshot of it, which then will be sent to the target. This generally makes no sense for readonly subvolumes.

Now what you probably want is to make a raw backup from an already existing snapshot (== readonly subvolume) /media/BIG/ub/dodo/190725-0610. For this, there is "btrbk archive", but unfortunately this does not support raw targets (yet).

Possible workaround:

1. (if there is no parent read-write subvolume of 190725-0610) create read-write subvol

   # btrfs subvolume snapshot /media/BIG/ub/dodo/190725-0610 /media/BIG/ub/dodo/190725-0610.readwrite

2. use the readwrite subvolume in your config

   subvolume ub/dodo/190725-0610.readwrite

Btrbk will then make a new snapshot of 190725-0610.readwrite and sent this to the target on "btrbk run".

You can also try rename 190725-0610 to the btrbk naming scheme (e.g. 190725-0610.20190101), then this (your original) readonly snapshot should also be transferred when running "btrbk run -p" (always use -n/--dryrun first).

[digint]

Note: Added btrbk archive --raw option, which was quite simple: 3e409037202ac31ed664e5f53c7bd9e9f0c72dea

[sbouniol]

ok so that's what I figured... but then I have even more questions... :-)

1) first and foremost, I noticed your note about enabling --raw option for archive, so if I understand properly this will take an existing readonly snapshot and just "archive it" to my target. The only difference between the archive and the backup is that the archive does 1 copy as-is while the backup checks for changes and only do incremental correct? And how can I use it? (do I need to buildit from the sources? - that sounds scary but I would try)

2) in the option you provided, creating a read-write snapshot doesn't actually use any space on btrfs correct? it is smart enough to know that the content is the same... isn't it?

3) Could I just change my existing snapshot to read/write while running the backup then switch it back? I won't modify anything in it would it?

[digint]

The only difference between the archive and the backup is that the archive does 1 copy as-is while the backup checks for changes and only do incremental correct?

• backup (i.e. "btrbk run") handles creation/deletion of snapshots as well as backups, see btrbk(1) COMMANDS.

• archive is meant to make a backup of your btrbk backup disk. It also works incremental. Note that only subvolumes with btrbk naming scheme are archived (suffix .YYYYMMDD).

And how can I use it? (do I need to buildit from the sources? - that sounds scary but I would try)

btrbk is a perl script, there is no need to build anything. Fetching btrbk from the master is as easy as:

cd /tmp/
wget https://raw.githubusercontent.com/digint/btrbk/master/btrbk
chown +x btrbk
sudo ./btrbk --version

in the option you provided, creating a read-write snapshot doesn't actually use any space on btrfs correct? it is smart enough to know that the content is the same... isn't it?

yes. btrfs subvolume snapshot only adds some meta data.

Could I just change my existing snapshot to read/write while running the backup then switch it back? I won't modify anything in it would it?

If you are talking about using btrfs property set: This is a low level command, don't use this unless you know what you are doing: it might break incremental backups as it breaks received-uuid relationships.

[bronger]

I think I have a use case for backupping a read-only subvolume. I use send/receive to sync two computers. I use the read-only property to mark the computer that is currently allowed to work with the subvolume (i.e., as some sort of locking mechanism).

Note that the parent snapshot for send/receive is read-only always, so I don’t thwart incremental backups.

I my case, btrbk fails with exit code 10. I don’t know whether all other tasks have been done nevertheless, but even if they did, I cannot distinguish this exit code from other errors (that I must not ignore).

As a workaround, I make the subvolume read-write temporarily for the btrbk run.

[ceremcem]

I think correct behavior would be "backup readonly snapshots as usual, but only for once".

[bronger]

I think correct behavior would be "backup readonly snapshots as usual, but only for once".

They may have become read-write and then read-only again in the meantime.

[ceremcem]

They may have become read-write and then read-only again in the meantime.

@bronger Would "making a subvolume writable again" break the logic in my proposal? btrbk will process the writable snapshots anyway.

What I say can be summed as follows:

...(btrbk logic)...

if a subvolume is readonly; then 
    ensure that you have that snapshot (by using UUID/Received UUID) within 
    the backups and do not take any more snapshots. Maybe append a postfix, like ".ro"
    to indicate that the original subvolume was readonly (which will be useful when you want to 
    restore).
fi

...(btrbk logic continues)...

[bronger]

Before we dive into a more and more convoluted discussion:

What is the downside of taking snapshots for backup no matter whether the source subvolume is read-only or not?

[luxagen]

I think I have a use case for backupping a read-only subvolume. I use send/receive to sync two computers. I use the read-only property to mark the computer that is currently allowed to work with the subvolume (i.e., as some sort of locking mechanism).

This. I also do things this way, and btrbk's inability to gracefully handle this situation makes it far more work than it would otherwise be, in terms of both configuration and maintenance.

[jaysonwcs]

I'm currently using an immutable system I built myself with Arch. I create a read-write snapshot from my current system and then make the updates there. But before I do this, I would like to make a snapshot from my current system folder without changing it to read-write. I was able to do this with snapper, but I would rather use BTRBK. Couldn't this option of making snapshots and backups from read-only subvolumes be configurable?

[luxagen]

I'm actually in the process of developing a Perl program to deal with this. The idea is to have a config file that ties snapshot_name to a mount point, and the script, when run, inspects which snapshot is mounted there, and if there's a later one from the same set, mounts it in place of the old one. The idea is to run it on a 15-minute cron job so that when btrbk sends a newer snapshot, the other machine will update quickly.

It would probably be nicer to have the functionality in btrbk, of course, but this is still an improvement.

Jayson or anyone else interested: I'll be putting this on Github once I have a working version, so check out the metadata on commits for my RotKraken project if you'd like to message me.

[luxagen]

Hi Jayson,

A first version of the tool is now complete: https://github.com/luxagen/btram . Please get in touch with any problems or suggestions.