Announcement

Collapse
No announcement yet.

should snapshot subvolume be a level 5?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    should snapshot subvolume be a level 5?

    When I use btrfs and snapshots manually, after installation I usually
    Code:
    mount /dev/sda2  /mnt
    and
    Code:
    ls /mnt
    shows me the @ and @home subvolumes. I then use
    Code:
    btrfs su cr /mnt/@snapshots
    mkdir /mnt/@snapshots/{root,home}
    to hold hold my snapshots. This produces a level 5 subvolume for the snapshots. Then the process for taking a set of snapshots becomes:
    Code:
    sudo su
    mount /dev/sda2 /mnt
    btrfs su sn /mnt/@ /mnt/@snapshots/root/"today's date"
    btrfs su sn /mnt/@home /mnt/@snapshots/home/"today's date"
    I have watch youtubers do it as below, but that creates the snapshots as a level 256, i.e. a subvolume under @.
    Code:
    ​sudo su
    mkdir -p /.snaphots/{root,home}
    btrfs su sn / /.snapshots/root/"today's date"
    btrfs su sn /home /.snapshots/home/"today's date"
    If you list the subolumes you see that is has created level 256 subvolumes
    Code:
    .snapshots/@/"today's date"
    .snapshots/@home/"today's date"
    ​Other than worrying about the syntax of the commands you use, is there any advantages or disadvantages?

    #2
    Other than mounting the snapshots by subvol ID I don't think it matters.

    My method is like yours. I don't like subvols inside subvols. You have to delete the nested subvol before the "host" subvol and any subsequent snaps double up the meta (I think).

    Please Read Me

    Comment


      #3
      Originally posted by oshunluvr View Post
      .I don't like subvols inside subvols.
      As well, the nested subvol doesn't travel. For example, if one copies a snapshot back from a backup, it doesn't have the subvol.
      Originally posted by jfabernathy
      I have watch youtubers do it as below,
      Code:
      mkdir -p /.snaphots/{root,home}
      btrfs su sn / /.snapshots/root/"today's date"
      btrfs su sn /home /.snapshots/home/"today's date"​
      I would expect that to give, as seen from the btrfs root,
      Code:
      @/.snapshots/root/"today's date"
      @/.snapshots/home/"today's date"
      with both snapshots​ nested in @; confusing, IMO.

      It is not necessary to have all those dated snapshots making a mess of the btrfs root directory. One can make ordinary directories to organize them, but they still show as "top level 5". For example, here's an excerpt from this laptop's btrfs su li .:
      Code:
      ID 1686 gen 50415 top level 5 path bup/@r-23-05-30
      ID 1687 gen 50416 top level 5 path bup/@h-23-05-30
      ID 1688 gen 50417 top level 5 path bup/@zohowd-23-05-30​
      ".snapshots" is a name snapper uses, so I would avoid it outside snapper use. I guess they've tried snapper and stuck with the name.

      Snapper using a nested subvol has caused problems for me, and trips snapper silently on any cloning or reverting of installs. So I use the method I found in the arch wiki, where a "top level 5" subvol is mounted on /.snapshots in /etc/fstab. This method has it's own problems. In particular. it's easy to get more than one install sharing a snapshot subvol; but in cases like that, I'm normally editing the fstab anyway and I notice the mount. Outside of snapper there's no need for this; I mention it because it's my experience that nested subvols are not good.
      Regards, John Little

      Comment

      Working...
      X