ZFS How to rebase clones onto a new snapshot while preserving data?

A

Annalesa

· I installed a base system on zroot/ROOT/base
· I took a snapshot of it: zroot/ROOT/base@snap
· I created two clones from that snapshot:
· zroot/ROOT/default (mounted at /, used for daily driver software)
· zroot/ROOT/build (used for installing compilers and dependencies like FreeBSD-set-devel)

· zroot/ROOT/base contains only the FreeBSD-set-optional and kernel. I use it for quick dependency tests and then rollback to @snap to stay clean.

I recently performed system updates inside zroot/ROOT/base and created a new snapshot: zroot/ROOT/base@snap_new.

Goal:
I want both zroot/ROOT/default and zroot/ROOT/build to be rebased on base@snap_new.

If I update the system in the three database, it will take three times space.
 
Name "rebase" does exist for git but not for zfs.
What are you trying to do ?
Rename ?
zfs rename -r tank/home@monday tuesday

I think you did not make a clone, (not necessary)

Note , snapshot is read only ;
clone is read write made out of read only snapshot

just snapshot recursively zroot ; all one in a go. Then you can send any sub-datasets to any destination.

After backup i do sometimes :
zfs list zroot | grep "@"
----> give me all snapshots of zroot
| awk '{print $1}'
----> give me column 1
| xargs -I {} zfs destroy {}
---> destroy all and only all snapshots of zroot

[USE with care]
 
Alain De Vos said:
Name "rebase" does exist for git but not for zfs.
What are you trying to do ?
Rename ?
zfs rename -r tank/home@monday tuesday

I think you did not make a clone, (not necessary)

Note , snapshot is read only ;
clone is read write made out of read only snapshot
Click to expand...
zroot/ROOT/default is based on zroot/ROOT/base@snap before，I want zroot/ROOT/default to be based on zroot/ROOT/base@snap_new
 
All speculation on my part, i'll talk about things based on my understanding of ZFS, which may be entirely wrong.
  1. Snapshots are immutable, they are read only, static references/copies of a dataset at a given point in time. So one cannot change a snapshot by design.
  2. A Clone is a writeable entity on top of a snapshot and basically represents the changes to the snapshot.
If we assume/agree on those 2 facts, then looking at what you are trying to do is take two clones which are differences from snapshot A and apply those differences to snapshot B (similar to the way git rebase works: figure out diffs from current to branch point, replay those diffs to current position).

Is that a reasonably correct understanding of what you have and what you want?
If so, I don't think it's possible (but I don't know everything) but perhaps someone else knows
 
mer said:
All speculation on my part, i'll talk about things based on my understanding of ZFS, which may be entirely wrong.
  1. Snapshots are immutable, they are read only, static references/copies of a dataset at a given point in time. So one cannot change a snapshot by design.
  2. A Clone is a writeable entity on top of a snapshot and basically represents the changes to the snapshot.
If we assume/agree on those 2 facts, then looking at what you are trying to do is take two clones which are differences from snapshot A and apply those differences to snapshot B (similar to the way git rebase works: figure out diffs from current to branch point, replay those diffs to current position).

Is that a reasonably correct understanding of what you have and what you want?
If so, I don't think it's possible (but I don't know everything) but perhaps someone else knows
Click to expand...
Clone 1 is A@snap +B
I want it to become A@snap_new +B
 
Just delete A@snap clone
Just delete A at snap snapshot.
Just clone A at snap_new ?

Current
Code: 
zfs list | sort
Could give insight into current situation.

But be carefull you dont want unbootable system
Code: 
kenv | grep mount
 
It means comparing the differences between two snapshots. Remove the differing parts from the clone, and copy the remaining parts to a new clone based on the new snapshot.
 
Poor man solution could be :
Code: 
mount snapshot old to /A
mount snapshot new to /B
create mountpoint /C (union)
use "clone" to copy all from /A to /C
overwrite with "clone" /B to /C
You have union in /C
Now you can unmount /A /B and delete snapshots.
Might take some time or I miss understood question.
 
The only real difference between 'build' and 'default' environments seems to be a bunch of additional packages. Make a note of what you installed there; pkg prime-list is useful. Then nuke the 'old' build environment and create a new one based on the current 'base' BE. Add the packages from the 'prime-list'.

There is no 'data' to preserve, only installed packages. Those are easily reinstalled. Just make sure your home directories are stored outside the BE. Which the current installer should set up in a separate dataset (zroot/home).
 
There is /usr/local.
I've put /usr/local/etc & /usr/local/www softlinks.
I ditch remove everything from /usr/local , at once quick , lost nothing. But like SirDice says have pkg prime-list. Run , Done.
 
SirDice said:
The only real difference between 'build' and 'default' environments seems to be a bunch of additional packages. Make a note of what you installed there; pkg prime-list is useful. Then nuke the 'old' build environment and create a new one based on the current 'base' BE. Add the packages from the 'prime-list'.

There is no 'data' to preserve, only installed packages. Those are easily reinstalled. Just make sure your home directories are stored outside the BE. Which the current installer should set up in a separate dataset (zroot/home).
Click to expand...

SirDice said:
The only real difference between 'build' and 'default' environments seems to be a bunch of additional packages. Make a note of what you installed there; pkg prime-list is useful. Then nuke the 'old' build environment and create a new one based on the current 'base' BE. Add the packages from the 'prime-list'.

There is no 'data' to preserve, only installed packages. Those are easily reinstalled. Just make sure your home directories are stored outside the BE. Which the current installer should set up in a separate dataset (zroot/home).
Click to expand...
I'm a root user and I place my data everywhere, not in a separate dataset
 
Annalesa said:
I'm a root user and I place my data everywhere, not in a separate dataset
Click to expand...
Maybe stop doing that. Separate data from OS and software.

Annalesa said:
· I installed a base system on zroot/ROOT/base
· I took a snapshot of it: zroot/ROOT/base@snap
· I created two clones from that snapshot:
· zroot/ROOT/default (mounted at /, used for daily driver software)
· zroot/ROOT/build (used for installing compilers and dependencies like FreeBSD-set-devel)

· zroot/ROOT/base contains only the FreeBSD-set-optional and kernel. I use it for quick dependency tests and then rollback to @snap to stay clean.
Click to expand...
Rereading this bit, I'd do this the other way around. Upgrade zroot/ROOT/default like normal. Destroy 'build' and 'base' and create new blank ones, all it has is some packages. Set this up so you can destroy and recreate them at a moments notice.
 
My layout, it can give "an idea",
x@myfreebsd:/SSD/home/x $ zfs list | grep SSD | sort | grep -v poudr
Code: 
SSD                                           247G   237G   144K  /
SSD/SSD_now                                   115G   237G   112K  /SSD
SSD/SSD_now/home                             37.7G   237G    96K  /SSD/home
SSD/SSD_now/home/x                           37.7G   237G  30.0G  /SSD/home/x
SSD/SSD_now/ollama                           72.3G   237G  72.3G  /SSD/ollama
SSD/SSD_now/root_KEEP                         652K   237G   652K  /SSD/root_KEEP
SSD/SSD_now/usr_local_etc                    5.59M   237G  5.59M  /SSD/usr_local_etc
SSD/SSD_now/usr_local_www                    60.4M   237G  60.4M  /SSD/usr_local_www
SSD/usr                                       128G   237G  1.74G  legacy
SSD/usr/local                                 114G   237G  28.7G  /usr/local
SSD/usr/obj                                  5.30G   237G  5.30G  /usr/obj
SSD/usr/ports                                4.62G   237G  4.62G  /usr/ports
SSD/usr/src                                  3.03G   237G  3.03G  /usr/src
SSD/var                                      3.98G   237G   787M  legacy
SSD/var/cache                                 237M   237G   212K  /var/cache
SSD/var/cache/pkg                             237M   237G   237M  /var/cache/pkg
SSD/var/db                                   2.98G   237G   202M  /var/db
SSD/var/db/grafana                           27.8M   237G  27.8M  /var/db/grafana
SSD/var/db/influxd                            560M   237G   560M  /var/db/influxd
SSD/var/db/mariadb                           3.41M   237G  3.41M  /var/db/mariadb
SSD/var/db/pkg                                152M   237G   152M  /var/db/pkg
SSD/var/db/postgres                           814M   237G   814M  /var/db/postgres
SSD/var/db/prometheus                        1.26G   237G  1.26G  /var/db/prometheus
SSD/var/log                                  3.34M   237G  3.34M  /var/log
 
You must log in or register to reply here.
Back
Top