Announcement

Collapse
No announcement yet.

BlkSnap Kernel Patches Posted For Creating Snapshots Of Linux Block Devices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BlkSnap Kernel Patches Posted For Creating Snapshots Of Linux Block Devices

    Phoronix: BlkSnap Kernel Patches Posted For Creating Snapshots Of Linux Block Devices

    A set of patches were posted on Wednesdasy for "blksnap", a proposed kernel driver to allow creating non-persistent snapshots of arbitrary kernel block devices. Among the possible uses with blksnap would be for creating backups at the block storage device level...

    https://www.phoronix.com/news/blksnap-Linux-Patches

  • #2
    I've some experience with Veeam, it's great to see this upstreamed! Well, tried at least.

    Comment


    • #3
      Well that's quite an interesting idea that could certainly have it's uses. But doing regular backups at the block level would be quite inefficient. Better to use a filesystem that supports snapshots and send/receive like Btrfs or ZFS.

      But, I could picture a scenario where I want to get an exact copy of a drive without unmounting it.

      Comment


      • #4
        Is this like LVM2 snapshots for people who didn't plan ahead and created raw partitions instead of using LVM2?

        I don't see the point of it from reading this article. These days using something like btrfs/zfs snapshots seems better anyway to get at least metadata consistency.

        I have not read linked material though, maybe that explains why this is useful.

        Comment


        • #5
          I wonder how is deals with very large amounts of data. For example, while gathering an image of a 10TB device, I write 100GB to the device which overwrites an existing 100GB. How does it remember that overwritten 100GB since it wouldn't know how to temporarily store it on the device itself?

          Comment


          • #6
            Very interesting...
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Originally posted by Chugworth View Post
              Well that's quite an interesting idea that could certainly have it's uses. But doing regular backups at the block level would be quite inefficient. Better to use a filesystem that supports snapshots and send/receive like Btrfs or ZFS.

              But, I could picture a scenario where I want to get an exact copy of a drive without unmounting it.
              ZFS zvols are block devices that support persistent snapshots. They would work for this too.

              Comment


              • #8
                Originally posted by Vorpal View Post
                Is this like LVM2 snapshots for people who didn't plan ahead and created raw partitions instead of using LVM2? [...]
                Here[1] an explanation of some blksnap advantages. To me the main ones are:
                - you can add blksnap even after the filesystem creation (i.e. you don't need to use LVM from the begin) and it is filesystem agnostic (with its cons and pros)
                - the storage for the snapshot data is dynamic and can be expanded /shrunk as needing


                [1] https://github.com/veeam/blksnap/blo...doc/blksnap.md

                Comment


                • #9
                  At first glance this seems like a duplicate of existing LVM functionality, but the non-persistent nature makes me hopeful that it'll handle duplicate UUIDs more intelligently than the current system.

                  Comment


                  • #10
                    Originally posted by Chugworth View Post
                    But doing regular backups at the block level would be quite inefficient.
                    It depends how it's done imo. Doing this right now with LVM is a bad idea for several reasons, but most of them are shortcomings with LVM rather than with the concept of block-level snapshots.
                    Last edited by ATLief; 03 November 2022, 04:43 PM.

                    Comment

                    Working...
                    X