ZSys alters unmanaged datasets #203
Comments
|
I was experimenting between two VMs freshly installed and heavily inspired by OpenZFS - ZFS on Root for Ubuntu 20.04. I installed a first VM Upon installing a package on the receiver side, I realized that
Important as well that during the zfs send, I'm pushing out the ZFS properties ( |
lgosselin
changed the title
lgosselin
changed the title
|
I finally found a little time to experiment a little further. I'm still running with Ubuntu 20-04 LTS, but with zsysctl 0.4.8 & zsysd 0.4.8 (so upgraded compared to the initial post). I have a On the backup server, I have : ## Backup dataset is a placeholder for backups coming from several machines
# zfs get canmount,mountpoint rpool/backup
NAME PROPERTY VALUE SOURCE
rpool/backup canmount off local
rpool/backup mountpoint /backup inherited from rpool
## A child dataset per machine
# zfs get canmount,mountpoint rpool/backup/machine2
NAME PROPERTY VALUE SOURCE
rpool/backup/machine2 canmount off local
rpool/backup/machine2 mountpoint /backup/machine2 inherited from rpool
## machine2 replicated pools and datasets, ZSys enabled
# zfs list -H -o name -d 2 rpool/backup/machine2
rpool/backup/machine2
rpool/backup/machine2/bpool
rpool/backup/machine2/bpool/BOOT
rpool/backup/machine2/rpool
rpool/backup/machine2/rpool/ROOT
rpool/backup/machine2/rpool/USERDATA
rpool/backup/machine2/rpool/data
## ZSys inspects `backup` because of the familiar structure
# zsysctl list
ID ZSys Last Used
-- ---- ---------
rpool/ROOT/ubuntu_8ok5om true current
rpool/backup/machine2/rpool/ROOT/ubuntu_weigra true 2021-03-25 12:30:14
# The last entry should not be considered. It is a state from another machine.
## A little more details
# zsysctl machine show --full
Name: rpool/ROOT/ubuntu_8ok5om
ZSys: true
Last Used: current
Last Booted Kernel: vmlinuz-5.8.0-48-generic
System Datasets:
- bpool/BOOT/ubuntu_8ok5om
- rpool/ROOT/ubuntu_8ok5om
- ...
...
User Datasets:
User: root
- rpool/USERDATA/root_8ok5om
...
Persistent Datasets:
- rpool/backup/machine2/rpool/data
- rpool/backup/machine2/rpool/data/dumps
...
# Only `data` and its children are flagged as persistent, here. It would help to have ROOT, BOOT, USERDATA as well.
## Grub scripts seems to also inspect unmanaged datasets
# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: vmlinuz-5.8.0-50-generic in rpool/ROOT/ubuntu_8ok5om
Found initrd image: initrd.img-5.8.0-50-generic in rpool/ROOT/ubuntu_8ok5om
...
cannot open 'bpool/BOOT/ubuntu_weigra@autozsys_bqb173': dataset does not exist
Warning: didn't find any valid initrd or kernel.
cannot open 'bpool/BOOT/ubuntu_weigra@autozsys_4xq7jp': dataset does not exist
Warning: didn't find any valid initrd or kernel.
...
cannot open 'bpool/BOOT/ubuntu_weigra@zfs-auto-snap_daily-2021-05-10-1325': dataset does not exist
Warning: didn't find any valid initrd or kernel.
Adding boot menu entry for UEFI Firmware Settings
done
# These `ubuntu_weigra` entries are from `machine2` datasets located in `rpool/backup/machine2/bpool/BOOT/ubuntu_weigra`.
# Also non `autozsys` snapshots are considered?I made some tests on another backup server. ZSys machine is also looking into datasets of older machines (16.04 upgraded to 18.04) not running ZSys (but are ZFS On Root with a dataset ROOT/ubuntu) # zsysctl list
ID ZSys Last Used
-- ---- ---------
rpool/ROOT/ubuntu_mhz675 true current
# machine1 is Ubuntu 18.04, not running ZSys and has no zsys properties at all
rpool/backup/machine1/rpool/ROOT/ubuntu false 0001-01-01 00:00:00
# machine 4 is a ZSys enabled Ubuntu 20.04
rpool/backup/machine4/rpool/ROOT/ubuntu_1ml921 true 2021-03-22 10:46:04From the details gathered so far
From some extra trials and errors, it looks like forcing ZFS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let's consider a machine that is storing backups from other machines within a dataset
rpool/backups. When a new package is installed, for example, a newautozsys_xxxsnapshot is created but it is also created in some unmanaged datasets likerpool/backups/machineX/rpool/USERDATA/username_uuid.We should have no snapshot created in any unmanaged datasets because they are by definition not managed by ZSys. It is especially important since interfering with snapshots present in a structure maintained via "zfs send/receive" can cause some difficulties to receive incremental backups afterwards. Edit: I also had user account completely removed from rpool/backups/machineX/rpool/USERDATA. I guess this may be linked to #103 somehow.
All datasets outside the usual
/BOOT/,/ROOT/,/USERDATA/hierarchy managed closely by ZSys for the local server should not be tempered with it. This report is about a caveat that occurs when there is a ZSys-like structure present on the server at another location (typical for a backup server)Installed versions:
The text was updated successfully, but these errors were encountered: