Hi all,
Snapper snapshots on a BTRFS are stored in read-only subvolumes.
I want to reduce the disc space required by older snapshots on a backup disc by removing parts of their data.
How can I do this? Or in other words: How can I turn the snapshot temporarily read-write?
Thank you very much!
Kallistos
Don’t mess with snapshots directly you will totally break things
Use the btrfs and snapper utilities to remove ones you don’t want.
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.snapper.html
Hi gogalthorp,
I absolutely understand your point and I surely wouldn’t mess around with my system recovery snapshots on the root partition.
Here I am talking about backup copies of my private /home directory from my private PC on an external HD and for them I use snapper simply as the creation and management tool. I keep these copies to be able to retrieve older file versions, recover individual files or restore the /home directory in case a HD crash. They are not system relevant and I will never have to rollback into them or something like that.
Nevertheless, as the external backup HD is formatted as an BTRFS the individual copies are kept in snapshot subvolumes and I would like to understand whether there is any way to switch such a subvolume from read-only to read-write?
Okay…I have found the solution for my purpose here:
https://unix.stackexchange.com/questions/149932/how-to-make-a-btrfs-snapshot-writable
The respective code is:
1- To remove read-only flag from snapshot subvolume:
--> btrfs property set -ts [FONT=courier new]PATH_TO_SNAPSHOT/snapshot ro false[/FONT]
2- To set read-only flag to snapshot subvolume:
→ btrfs property set -ts PATH_TO_SNAPSHOT/snapshot ro true
[FONT=arial]Removing the read-only flag looks like this:[/FONT]
xxx:/mnt/whiteBoxHD/.snapshots/1 # sudo btrfs subvolume show /mnt/whiteBoxHD/.snapshots/1/snapshot <== Show me information on the given subvolume!
.snapshots/1/snapshot
Name: snapshot
UUID: 00250e2e-f40a-f845-a356-d21e1fce840e
Parent UUID: 0693f08e-d788-1a43-be60-d910a22cd8e2
Received UUID: -
Creation time: 2018-05-13 22:37:39 +0200
Subvolume ID: 603
Generation: 611
Gen at creation: 611
Parent ID: 602
Top level ID: 602
Flags: readonly <== Read-only flag is set
Snapshot(s):
xxx:/mnt/whiteBoxHD/.snapshots/1 # sudo btrfs property set -ts /mnt/whiteBoxHD/.snapshots/1/snapshot ro false <== Remove read-only flag!
xxx:/mnt/whiteBoxHD/.snapshots/1 # sudo btrfs subvolume show /mnt/whiteBoxHD/.snapshots/1/snapshot
.snapshots/1/snapshot
Name: snapshot
UUID: 00250e2e-f40a-f845-a356-d21e1fce840e
Parent UUID: 0693f08e-d788-1a43-be60-d910a22cd8e2
Received UUID: -
Creation time: 2018-05-13 22:37:39 +0200
Subvolume ID: 603
Generation: 611
Gen at creation: 611
Parent ID: 602
Top level ID: 602
Flags: - <== Read-only flag has now been removed
Snapshot(s):
With the read-only flag removed I could delete individual directories from the snapshot and then set the read-only-flag back to TRUE.
As gogalthorp rightly stated this operation should certainly not be done with system-relevant snapshots but with mere backup data, as in my specific case, I think it should be no problem. If I run into trouble for whatever reason I am going to warn you here…
Thanks again and best regards,
Kallistos
I doubt many people will use Btrfs snapshots as a backup tool for user data instead of fallback tool at the system level.
IMO this thread proves that it is not designed for what you use it for. I also think there are miriads of backup tools available for all sorts of backup scenarios wanted.
Snapshots are not backups. They are dependent on the main file system and if that is gone or corrupted snapshots are useless even if on another drive… In essence they are restore points which is not the same as a backup. THey are sort of but not exactly like a diff. SO you should not rely on them for full restorable backups
Let me give it one other try to explain what I’m doing: I am using rsync to backup my /home directory on an external HD and I am using snapper to create a series of copies of that backup to be able to walk back in time.
In other words: I am snapshotting a backup, which should make it clear that snapper is not being used as a backup tool and that the a-snapshot-is-not-a-backup-warning does not apply.
If anybody knows of a better backup tool than rsync or a better snapshotting tool than snapper I will certainly be curious to read about it.
The only issue that I actually had was that I retrospectively decided to throw away parts of the backupped and snapshotted data and that I, for the first time, realized that snapper-snapshots are read-only (which I otherwise do appreciate). With the related switch to overcome the read-only situation on my backup disc identified I do not really understand why the process should be flawed or why I should favour a different software.
Merry Christmas!
Kallistos
It is written in bash. Thus easily to see what is done. I do not use it directly, but created a script of my own based on the principles. Use it already for years, thus before Btrfs and it’s snapshots existed.
Hi Henk,
Thanks a lot for this suggestion: At the first reading, rsnapshot indeed promises to be a valuable alternative to the rsync+snapper combination.
Also, in the meantime it has occurred to me that using snapper as a tool to create and maintain backup-snapshots has of course one major drawback: Snapper requires root privileges.
On the other hand, that would exclude only ordinary users of multi-user environments from applying rsync+snapper but not system admins backupping and snapshotting e.g., a complete /home partition and to a lesser extent the single user/superuser on a PC like myself.
Personally, I just found that snapper is speedy, reliable and easy to configure and thus useful and convenient not only for snapshotting root partitions. As it works absolutely fine with my setup I am going to stick with it for the time being…
You are welcome. It is always good to know anout alternative solutions and then decide based on your requirements.