Announcement

Collapse
No announcement yet.

Btrfs, Snapper and apt-btrfs-snapshot

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

    #16
    Originally posted by oshunluvr View Post
    The only point GG made above I would differ slightly with is the utility of btrfs on a single disk.
    Thus my "escape clause":
    ... unless that HD or partition is TWICE OR 3X as big as the maximum size of your anticipated storage needs


    Originally posted by oshunluvr View Post
    IMO, btrfs has many benefits for smaller single-drive users but snapshots is not one of them. For example, if you have a small drive but want to multi-boot, you are stuck splitting your drive up into multiple partitions and thus waste a tremendous amount of space. With btrfs in the same scenario, you would need only a single file system and all your free space would be available to all your installs and your home all the time without managing partition sizes.
    I have a thick skull. You'll need to explain a little more how you can get btrfs to give you multiple boots and homes on a single drive (or partition?).

    Originally posted by oshunluvr View Post
    Regardless of filesystem size, snapshots require paying close attention to their maintenance. Snapshots are not a set-it-and-forget-it function as GG learned with his experiments. Under certain conditions; one-off upgrades like me or risky things like compiling from an little-known source, the ability is awesome. But you must return to the snapshot and remove it as soon as it is no longer needed. In theory, over time a snapshot could grow to the same size as the subvolume it was made from. Take 4 snapshots and you have the potential to use a lot of filesystem space! With a larger amount of free space and a heavier work load, a scheduled series of snapshots - with included removal of same as they age - is a very large benefit.
    Indeed. From what I've observed just creating two subvolumes (.snapshots) and then creating one snapshot each for @ and @home could, eventually, eat your entire partition or drive whereas in an EXT4 system your files and data build up may eat only half your storage.

    Originally posted by oshunluvr View Post
    A snapshot is not a backup and should not be used to replace one. Rather, it's a "photograph" of your system that can be used to "remember" it previous state. Once that remembrance is no longer needed, chuck that snapshot like you would pictures of your ex-girlfriend.
    That's one of the three most useful reasons to use btrfs. The second is the ability to add or remove storage space easily. The third is the use of btrfs's "send" and "receive" to move one or more subvolues to a remote btrfs system, as described here:
    Let's say you've got another computer with a btrfs filesystem and you want to back up your home directory from this computer to the other one. We'll use btrfs' built-in asynchronous replication for this. First, let's create a new subvolume underneath /home to contain the snapshots:
    me@virtual-machine:~$ sudo btrfs sub create /home/.snapshots
    Create subvolume '/home/.snapshots' Now, let's take our first snapshot:
    me@virtual-machine:~$ sudo btrfs sub snapshot -r /home /home/.snapshots/myfirstsnapshot
    Create a readonly snapshot of '/home' in '/home/.snapshots/myfirstsnapshot' We can see the new structure with another btrfs subvolume list:
    me@virtual-machine:~$ sudo btrfs sub list /
    ID 256 gen 199294 top level 5 path @
    ID 257 gen 199294 top level 5 path @home
    ID 849 gen 199310 top level 5 path @home/.snapshots
    ID 850 gen 199311 top level 5 path @home/.snapshots/myfirstsnapshot
    Now, let's replicate the snapshot to our second machine, which has convenient subvolumes named /backup and /backup/home and /backup/home/.snapshots.
    me@virtual-machine:~$ sudo btrfs send /home/.snapshots/myfirstsnapshot | ssh second-machine sudo btrfs receive /backup/home/.snapshots
    In its simplest possible form, this demonstrates sending the snapshot—which contains the entire /home subvolume at the time it was taken, remember—and tunneling it through ssh to the btrfs filesystem on the other end. There's nothing too special about this yet. Sure, you're replicating the entire subvolume all at once, which is kind of neat, but you could accomplish this in all kinds of ways. Where this gets cool is when we take and send a second snapshot:
    me@virtual-machine: sudo btrfs sub snapshot -r /home /home/.snapshots/mysecondsnapshot
    me@virtual-machine: sudo btrfs send -p /home/.snapshots/myfirstsnapshot /home/.snapshots/mysecondsnapshot | ssh second-machine btrfs receive /backup/home/.snapshots
    What we did here was send only the data that has changed on-disk between "myfirstsnapshot" and "mysecondsnapshot." What's especially awesome about this is that the system doesn't have to laboriously scan the disks to find things that have changed. It already knows what has or hasn't changed, so it can just immediately start spitting data out to the receive process on the other end. If you have a few text files to replicate, this might not matter. But if you have a terabyte or five of database binaries or virtual machine storage, this is a huge deal. Backups that would have taken hours or days and generated a tremendous amount of system load with older technologies can now complete in minutes with little or no extra load.

    I have systems that routinely replicate a terabyte or more of data across cheap 3Mbps and slower Internet connections using this technology... sometimes, replicating several times per day. There is literally no other technology that can accomplish this. If you have a six-figure SAN that replicates off-site several times a day, incremental snapshot replication is how it does it.
    That is neat!
    Last edited by GreyGeek; Feb 01, 2014, 07:42 PM.
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #17
      I haven't yet ventured into "send" and "receive" territory, but they're definitely on my short list.
      Code:
      [COLOR=#333333]I have a thick skull. You'll need to explain a little more how you can get btrfs to give you multiple boots and homes on a single drive (or partition?). [/COLOR]
      While I totally disagree with the former portion of that statement, to the latter I have a post here outling how I did that. But here's an abridged version:

      Create a btrfs filesystem.
      Install Kubuntu to it.
      Rename the @ (root) and @home (/home) subvolumes to unique names; i.e. @Kubuntu_12.04 and @Kubuntu_12.04_home.
      Edit fstab entries to match the new subvolumes and run update-grub.

      You now have a single Kubuntu installed to a single filesystem. Now install 13.04 to the same file system (obviously without formatting!).

      Rename the @ (root) and @home (/home) subvolumes to unique names; i.e. @Kubuntu_13.04 and @Kubuntu_13.04_home.
      Edit fstab entries to match the new subvolumes and run update-grub.

      You now have two version of Kubuntu on the same filesystem!

      repeat ad nauseum.

      Here's my subvolume list:
      Code:
      stuart@office:~$ sudo btrfs su li /
      ID 258 gen 683679 top level 5 path @grub
      ID 261 gen 690090 top level 5 path @Kubuntu_12_10_home
      ID 262 gen 683625 top level 5 path @Kubuntu_12_10
      ID 306 gen 691245 top level 5 path @Kubuntu_14_04
      ID 307 gen 691245 top level 5 path @Kubuntu_14_04_home
      ID 400 gen 683562 top level 5 path @Neptune_31_home
      ID 401 gen 683589 top level 5 path @Neptune_31
      ID 484 gen 685217 top level 5 path @Kubuntu_13_04_home_140120105600
      ID 485 gen 683625 top level 5 path @Kubuntu_13_04_140120105600
      stuart@office:~/Downloads$
      All of this fit on a single 256GB drive.

      Please Read Me

      Comment


        #18
        I thought I needed to add one more detail to this rambling prose: How to roll back, after some bad event, to a specific snapshot.

        This is taken from a document in one of Ubuntu's "AksUbuntu" pages, but I don't remember which. Also note that it is a btrfs system that also contains its own /boot subdirectory, so btrfs contains all the stuff under /boot. And, I am merely acting as an aggregator of info. I have not yet done a roll back.
        How to work with snaphots in Ubuntu's layout

        In order to work with snapshots of / or /home in the Ubuntu layout mount the btrfs filesystem at a separate location, and work from the top of the btrfs tree, rather than from the mounted subvolumes you are running on.

        First, mount the btrfs system you are currently on to the /mnt device
        sudo mount /dev/sdX# /mnt

        It seemed strange to me to mount the filesystem I was currently on and running AGAIN, to the very partition I was on, in my case sda4, which contained my entire kubuntu 14.04 system under btrfs.

        To create a snapshot use this syntax:
        sudo btrfs subvolume snapshot /mnt/@ /mnt/@_snapshot

        Notice that when refering to @ or @home while running in the systm you use "/" and "/home", but when mounted separately you use "@" and "@home".


        This will create a snapshot, created this way, of the @ subvolume named @_snapshot located also in the top of the btrfs tree. Since it is in the top of the tree, it will not show up when listing subvolumes in the subvolume you are currently running in.

        To roll back to a snapshot, you simply need to change its name to the name that ubuntu mounts and reboot.
        Code:
          [FONT=courier new]sudo mv /mnt/@   /mnt/@_badroot[/FONT]
        Code:
        [FONT=courier new]
        [B]sudo mv /mnt/@_snapshot   /mnt/@[/B][/FONT]
        then reboot!

        To delete a snapshot while /mnt is mounted use:
        Code:
          [FONT=courier new][B]sudo btrfs subvolume delete /mnt/@_badroot[/B][/FONT]
        btrfs snapshots are subvolumes in themselves, and self-contained, deleting the old @ subvolume like this is fine, provided we have a replacement.

        NOTE: The btrfs-tools command ''set-default'' will break Ubuntu's layout. Don't use it!
        It is entirely possible to create a snapshot of "/" or "/home" without mounting your btrfs filesystem on /mnt and working there.
        One could create a hidden subvolume called ".snapshots" in both the "/" and the "/home" subvolumes:
        sudo btrfs subvolume create /.snapshots
        sudo btrfs subvolume create /home/.snapshots
        and then create snapshots and save them under those subvolumes:
        sudo btrfs subvolume snapshot / /.snapshots/snapYYYYMMDDHHMM
        sudo btrfs subvolume snapshot / /home/.snapshots/snapYYYYMMDDHHMM


        Since these snapshots are created from within the working system they can be listed. Those snapshots created on a mounted /mnt cannot be seen from within the system, exceept for @ and @home, which are bound to "/" and "/home" in /etc/fstab:
        Code:
        # <file system> <mount point>   <type>  <options>       <dump>  <pass>
        # / was on /dev/sda4 during installation
        UUID=ddf94bee-0a35-4c66-87b7-857db8d21a0c [B]/  [/B]             btrfs   defaults,[B]subvol=@[/B] 0       1
        # /home was on /dev/sda4 during installation
        UUID=ddf94bee-0a35-4c66-87b7-857db8d21a0c[B] /home[/B]           btrfs   defaults,[B]subvol=@home[/B] 0       2
        In order to roll back "/" or "/home" one must mount the device to /mnt (or some other mounting point) and use mv command and then reboot.
        "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
        – John F. Kennedy, February 26, 1962.

        Comment


          #19
          Originally posted by oshunluvr View Post
          .....

          You now have two version of Kubuntu on the same filesystem!

          repeat ad nauseum.

          Here's my subvolume list:
          Code:
          stuart@office:~$ sudo btrfs su li /
          ID 258 gen 683679 top level 5 path @grub
          ID 261 gen 690090 top level 5 path @Kubuntu_12_10_home
          ID 262 gen 683625 top level 5 path @Kubuntu_12_10
          ID 306 gen 691245 top level 5 path @Kubuntu_14_04
          ID 307 gen 691245 top level 5 path @Kubuntu_14_04_home
          ID 400 gen 683562 top level 5 path @Neptune_31_home
          ID 401 gen 683589 top level 5 path @Neptune_31
          ID 484 gen 685217 top level 5 path @Kubuntu_13_04_home_140120105600
          ID 485 gen 683625 top level 5 path @Kubuntu_13_04_140120105600
          stuart@office:~/Downloads$
          All of this fit on a single 256GB drive.
          So, IF I follow you correctly, you choose the version of Kubuntu you will boot into on the grub menu during bootup, BUT, you have access to all of the volumes regardless of which version you boot into?
          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
          – John F. Kennedy, February 26, 1962.

          Comment


            #20
            If I understand your question correctly, the answer is no. When I boot to @Kubuntu_12_10, that subvolume is mounted in fstab as root. Thus all other subvolumes are not accessible. I can (and often do) mount the root device somewhere and then access all the above.

            I manage my grub menus a little differently than standard also. On startup, I boot the the @grub install. The grub menu there has os_prober turned off (as do all my grubs) and I have a 40_custom that points to the grub menus for each install, like this:

            Code:
            menuentry 'Kubuntu 13.04' {
            insmod gzio
            insmod btrfs
            search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
            configfile /@Kubuntu_13_04_140120105600/boot/grub/grub.cfg
            }
            
            
            menuentry 'Kubuntu 14.04' {
            insmod gzio
            insmod btrfs
            search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
            configfile /@Kubuntu_14_04/boot/grub/grub.cfg
            }
            That's just part of it, but you get the idea. Then each install manages it's own grub menu and none of them effect the "master" grub menu. This way I can add and delete installs without risking removing the grub host install - the main boot menu always survives. All I have to do is edit the 40_custom once in awhile. If I was smart, I would just use generic names like; Linux1, Linux2, Linux3, etc. Then I wouldn't even have to edit 40_custom. Another neat feature of doing it this way is the grub menus are automatically nested. If I select a submenu and change my mind, a simple ESC puts me right back to the main grub menu. I set the timeouts at 3 secs and have my current "daily" install set as the default so I can boot up unattended.

            Please Read Me

            Comment


              #21
              So, when you install a new version you select the btrfs partition and install without formatting. The install then installs @ and @home, which you rename after the install to @KubuntuXX_YY and @KubuntuXX_YY_home, or something like that, and then edit the grub.conf and fstab so they point to the right subvolume?
              "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
              – John F. Kennedy, February 26, 1962.

              Comment


                #22
                Exactly!

                Each install has grub pointing to a disk other than my actual boot disk. That way each install has grub and all it's files, but they don't take over my main MBR.

                Please Read Me

                Comment


                  #23
                  Originally posted by oshunluvr View Post
                  Exactly!

                  Each install has grub pointing to a disk other than my actual boot disk. That way each install has grub and all it's files, but they don't take over my main MBR.
                  Then I am in luck. Here are my partitions. As you can see, my boot disk is the 100MB Windows partition:
                  Code:
                     Device Boot      Start         End      Blocks   Id  System
                  /dev/sda1            2048    33556479    16777216   27  Hidden NTFS WinRE
                  /dev/sda2   *    33556480    33761279      102400    7  HPFS/NTFS/exFAT
                  /dev/sda3        33761280   759126015   362682368    7  HPFS/NTFS/exFAT
                  /dev/sda4       759126016  1465147391   353010688   83  Linux
                  I have 336GB on my sda4 partition so I can employ the same scheme you are using!
                  "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                  – John F. Kennedy, February 26, 1962.

                  Comment


                    #24
                    The saga continues: The &quot;btrfs device add&quot; command.

                    My main partition, on which I have installed Kubuntu 14.04 with the btrfs FS, is on /dev/sda

                    I inserted an 8GB flash drive and attempted to format it with kparted. However, kparted did NOT have the btrfs as an option. XFS was there, but not btrfs.
                    So, I resorted to the CLI and mkfs.btrfs to format the 8GB stick. The "-f" switch was needed to forced the overwrite of the 500MB Verbatin_Store'n_GO partition, the first time I did it. After that, I did not have to.
                    Code:
                    :~$ sudo mkfs.btrfs /dev/sdb
                    WARNING! - Btrfs v3.12 IS EXPERIMENTAL
                    WARNING! - see http://btrfs.wiki.kernel.org before using
                    
                    Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
                    fs created label (null) on /dev/sdb
                            nodesize 16384 leafsize 16384 sectorsize 4096 size 7.46GiB
                    I mounted it using
                    Code:
                    sudo mount /dev/sdb /mnt
                    and was able to copy files to it using Dolphin, but they were stored with root ownership.
                    I umounted and mounted and umounted several times to see that the files I copied on it remained.
                    Code:
                    [FONT=courier new]:~$ sudo mount /dev/sdb /mnt[/FONT]
                    :~$ [FONT=courier new]vdir /mnt[/FONT]
                    total 0
                    and copies some files to it using Dolphin. The results are:
                    Code:
                    :~$ [FONT=courier new]vdir /mnt[/FONT]
                    total 64
                    -rw-rw-r-- 1 root root  1312 Jan 24 12:08 brtfs-find-root.txt
                    -rw-rw-r-- 1 root root  2268 Jan 24 12:11 brtfs-image.txt
                    -rw-rw-r-- 1 root root  1339 Jan 24 12:12 brtfs-map-logical.txt
                    -rw-rw-r-- 1 root root  1358 Jan 24 12:16 btrfsck-dont-use.txt
                    -rw-rw-r-- 1 root root  1431 Jan 24 12:07 btrfs-convert.txt
                    -rw-rw-r-- 1 root root  1104 Jan 24 14:10 btrfs-create.txt
                    -rw-rw-r-- 1 root root  1414 Jan 24 12:13 btrfs-show-super.txt
                    -rw-rw-r-- 1 root root  1217 Jan 24 12:16 btrfstune.txt
                    -rw-rw-r-- 1 root root 24800 Jan 24 12:04 btrfs.txt
                    -rw-rw-r-- 1 root root  1119 Jan 24 12:14 btrfs-zero-log.txt
                    
                    :~$[FONT=courier new] sudo umount /mnt[/FONT]
                    :~$ [FONT=courier new]sudo mount /dev/sdb /mnt[/FONT]
                    :~$[FONT=courier new] vdir /mnt[/FONT]
                    total 64
                    -rw-rw-r-- 1 root root  1312 Jan 24 12:08 brtfs-find-root.txt
                    -rw-rw-r-- 1 root root  2268 Jan 24 12:11 brtfs-image.txt
                    -rw-rw-r-- 1 root root  1339 Jan 24 12:12 brtfs-map-logical.txt
                    -rw-rw-r-- 1 root root  1358 Jan 24 12:16 btrfsck-dont-use.txt
                    -rw-rw-r-- 1 root root  1431 Jan 24 12:07 btrfs-convert.txt
                    -rw-rw-r-- 1 root root  1104 Jan 24 14:10 btrfs-create.txt
                    -rw-rw-r-- 1 root root  1414 Jan 24 12:13 btrfs-show-super.txt
                    -rw-rw-r-- 1 root root  1217 Jan 24 12:16 btrfstune.txt
                    -rw-rw-r-- 1 root root 24800 Jan 24 12:04 btrfs.txt
                    -rw-rw-r-- 1 root root  1119 Jan 24 12:14 btrfs-zero-log.txt
                    :~$ sudo umount /mnt
                    However, I believe that the files were being saved in that 500MB XFAT Verbatin_Store'N Go partiton, as you'll see later.
                    So, don't expect to use btrfs on a flash drive the way you would EXT4.


                    Then I started exploring the "btrfs device add" command, which complained of an existing filesystem. Adding the "-f" switch forced the process.
                    Code:
                    :~$ sudo  btrfs device add /dev/sdb /home -f
                    Two devices were now shown:
                    Code:
                    :~$ sudo btrfs fi show /
                    Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
                            Total devices 2 FS bytes used 90.90GiB
                            devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
                            devid    2 size 7.46GiB used 0.00 path /dev/sdb
                    The show command does not total the size of the devid's.

                    I didn't want to run a balance operation because I didn't want to take the time.
                    When I mounted /dev/sdb I saw the two standard subvolumes, @ and @home:
                    Code:
                    :~$ [FONT=courier new]sudo mount  /dev/sdb /mnt[/FONT]
                    jerry@jerry-Aspire-V3-771:~$ vdir /mnt
                    total 0
                    drwxr-xr-x 1 root root 262 Feb  1 08:49 @
                    drwxr-xr-x 1 root root  66 Feb  4 14:43 @home
                    When I look into /mnt/@ and /mnt/@home I saw my entire filesystem!

                    The btrfs space and usage command showed:
                    Code:
                    :~$[FONT=courier new] sudo btrfs fi df /[/FONT]
                    Data, single: total=121.00GiB, used=90.50GiB
                    System, DUP: total=32.00MiB, used=16.00KiB
                    Metadata, DUP: total=4.00GiB, used=411.53MiB
                    and the subvolume list command showed:
                    Code:
                    :~$[FONT=courier new] sudo btrfs subvolume list /[/FONT]
                    ID 257 gen 25251 top level 5 path @
                    ID 258 gen 25251 top level 5 path @home
                    ID 1021 gen 21638 top level 257 path .snapshots
                    ID 1022 gen 25177 top level 5 path @home/.snapshots
                    
                    :~$ sudo btrfs subvolume list /home
                    ID 257 gen 25251 top level 5 path @
                    ID 258 gen 25251 top level 5 path @home
                    ID 1021 gen 21638 top level 5 path @/.snapshots
                    ID 1022 gen 25177 top level 258 path .snapshots
                    My assumption is that the addtional 8GB of flash drive was added to the /home space.

                    The fi show command still showed the same devid's.
                    Code:
                    :~$ [FONT=courier new]sudo btrfs fi show /[/FONT]
                    Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
                            Total devices 2 FS bytes used 90.90GiB
                            devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
                            devid    2 size 7.46GiB used 0.00 path /dev/sdb
                    
                    Btrfs v3.12
                    
                    :~$ [FONT=courier new]sudo btrfs fi show /home[/FONT]
                    Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
                            Total devices 2 FS bytes used 90.90GiB
                            devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
                            devid    2 size 7.46GiB used 0.00 path /dev/sdb
                    
                    Btrfs v3.12
                    I used the device delete command and the second device is gone:
                    Code:
                    :~$ [FONT=courier new]sudo  btrfs device delete /dev/sdb /home[/FONT]
                    :~$ [FONT=courier new]sudo btrfs fi show /home[/FONT]
                    Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
                            Total devices 1 FS bytes used 90.90GiB
                            devid    1 size 336.66GiB used 129.06GiB path /dev/sda4

                    The device add command destroys the existing device formatting and replaces it. The device delete command removes the formatting:
                    Code:
                    :~$[FONT=courier new] sudo mount /dev/sdb /mnt[/FONT]
                    NTFS signature is missing.
                    Failed to mount '/dev/sdb': Invalid argument
                    The device '/dev/sdb' doesn't seem to have a valid NTFS.
                    Maybe the wrong device is used? Or the whole disk instead of a
                    partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
                    The files I had saved in that 500MB partiton are gone.

                    I have a 7 port active USB device that could hold SEVEN 128GB flash drives!
                    Or, I have a 350GB USB HD that hasn't been used in a while.... mmmm ....
                    Last edited by GreyGeek; Feb 04, 2014, 04:27 PM.
                    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                    – John F. Kennedy, February 26, 1962.

                    Comment


                      #25
                      Have you ever noticed the time delay between when you flip a switch and when the flouresencent bulb actually lights up? My brain works that way. I hear an explanation but it may take awhile for the eaning to soke in. Snapshots and backups on a btrfs system is my latest delayed reaction.

                      One can mount an external EXT4 formatted HD and copy files from one's computer onto the external drive, then umount it. IF the computer HD goes down the it can be replaced and files restored from the external backup HD.

                      Btrfs snapshots on non-raid systems do not allow that. If one makes a snapshot of /, for example, that snapshot is still on the primary btrfs system. If the HD goes down so does the backup. Disaster.

                      Attaching a second btrfs device, say /dev/sdb,
                      mkfs.btrfs -f /dev/sdb1
                      btrfs device add [-Kf] /dev/sdb1 /somepath
                      and creating a snapshot of / on it
                      sudo mkdir /somepath/.snapshots
                      btrfs subvolume snapshot / /somepath/.snapshots/snapshotname
                      only creates links to the files on the primary HD.

                      No actual data is written to snapshotname, only links to the original data. Copy on Write dictates that when a file changes on the primary system the original file, before the change was made, is copied to the snapshot. If all the files on the primary device, say /dev/sda, changes then eventually the snapshot will contain a complete copy of the original files on the primary system before any changes were made. This is why a btrfs system can eat twice the HD space of an EXT4 system. More snapshots eats up more space. IF, after creating a snapshot on /dev/sdb, that device is umounted, the links to the files on the primary system areno longer active. Any original copies of any changed files on the primary system are not copied to the snapshot. No ability to rollback exists.

                      This still leaves the old fashon method of just copying the original files to an EXT4 external HD, or even a btrfs external HD, and then copying them back if necessity requires it. But, this method isn't really entirely sastisfactory because one usually does not copy all the files, just the data files and important config files.

                      Enter the RAID system. We can use RAID0 (striping mode), RAID1 (mirror mode) or RAID10 (stripping and mirroring mode). I want RAID1.
                      I have not done any of the followiing. I'm sort of "thinking out loud".

                      I have a 350GB external USB HD and I have a seven port USB2.0 active hub, into which I can plug several flash drives, either 64GB or 128GB.
                      But, can I convert my brtfs single drive to a RAID1 in conjuction with an external drive?

                      First, mount my active btrfs system:
                      sudo mount /dev/sda4 /mnt
                      Convert it to a RAID1 system
                      btrfs fi balance start -dconvert=raid1 -mconvert=raid1 /mnt
                      but this won't work because there isn't a second device that has already been spanned, which would have happened if we did this:
                      mkfs.btrfs /dev/sda4 /dev/sdb1
                      in other words, if multiple devices are specified, btrfs is created spanning across the specified devices. The balance command above merely converts both the data (-d) and the metadata (-m) to RAID1, which would mirror /dev/sda4 on /dev/sdb1, assuming /dev/sdb1 is as big or bigger than /dev/sda4.

                      If I use
                      sudo btrfs device add /dev/sdb1 /somepath
                      I haven't done anything except to add space to my existing btrfs filesystem.

                      So, at this point, I am assuming there are no btrfs tricks to convert my single btrfs system into a RAID1 by adding a second device.

                      I think I could reinstall Trusty Tahr, and from a LiveCD format both my /dev/sda4 and an external HD (/dev/sdb1) together and convert them to RAID1, and then install Trusty on /dev/sda4, which would mirror it to /dev/sdb1. Yes? No?
                      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                      – John F. Kennedy, February 26, 1962.

                      Comment


                        #26
                        Snapshots aren't really backups. You can do a btrfs --send to copy a filesystem to another drive, but it's a new feature and I've not messed with it. I usually do full backups the old-fashioned way. Alternately, RAID1 or RAID10 are also available if you have enough devices.

                        Only downside to the RAID1 with an external drive; if you remove the external (or it doesn't attach at boot time) you have to mount in degraded mode and "fix" the issue.

                        Yes, you can migrate your current install to another drive. You add the new device (not as RAID, just as additional space, aka "single"), delete the old device, and the files move to the new drive automatically. When the move ("balance" in btrfs lingo) is done, the old drive is removed from the file system. I know this works because I've done it. btrfs fi sh will show the progress - as the files move, the available space will change and eventually the "deleted" device will disappear from the device list. I did have to re-mkfs.btrfs the old device to generate a new UUID. The software expects you will pull the old device, and so it might re-appear in the device list eventually if you don't.

                        Converting a single device to RAID1 is simple. Add the second device first, then run the balance command using -dconvert. Meta will default to raid1.

                        Please Read Me

                        Comment


                          #27
                          Ah, I forgot about the "-send" feature. So, would something like this work if I use a pipe and mount the external drive, previously formatted with btrfs and mounted as /mnt?
                          sudo btrfs send / | btrfs recieve /mnt
                          sudo btrfs send /home | btrfs receive /mnt/home
                          Then umount /mnt.
                          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                          – John F. Kennedy, February 26, 1962.

                          Comment


                            #28
                            I believe that is how it's supposed to work. I don't know if you have to send /home separately since your source is the mounted /. I think it's possible that since /home is mounted under / that it might send it all with the first command. It would be an interesting experiment.

                            http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html

                            Please Read Me

                            Comment


                              #29
                              Originally posted by GreyGeek View Post
                              Enter the RAID system. We can use RAID0 (striping mode), RAID1 (mirror mode) or RAID10 (stripping and mirroring mode). I want RAID1.I have not done any of the followiing. I'm sort of "thinking out loud".
                              I would invite you to reconsider -- this is not an "either / or" decision. The default BTRFS configuration for multi-device filesystem provides BOTH RAID 1 striping (of the data) and Raid 2 mirroring (of the metadata). That's what I have on my system, for my user data.

                              https://btrfs.wiki.kernel.org/index....ltiple_Devices
                              Last edited by dibl; Feb 13, 2014, 04:48 PM.

                              Comment


                                #30
                                Originally posted by oshunluvr View Post
                                I believe that is how it's supposed to work. I don't know if you have to send /home separately since your source is the mounted /. I think it's possible that since /home is mounted under / that it might send it all with the first command. It would be an interesting experiment.

                                http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html
                                Aren't "/" and "/home" (@ & @HOME) separate subvolumes? Otherwise, wouldn't a snapshot of / also include /home? When I made a snapshot of "/" I checked specfiically to see if it included /home. It did not.

                                I was thinking about this "send" situation while my wife and I were taking our walk ... mounting /dev/sda4 to /mnt and then doing a send of / and /home to /mnt, which is under /. It seems to me that this would create an infinite loop. However, "send" doesn't have any parameters to exclude /mnt, or any other part of /, and the examples you gave don't indicate any looping occurs. Looks like I'll be doing some experimenting.
                                "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                                – John F. Kennedy, February 26, 1962.

                                Comment

                                Working...
                                X