Announcement

Collapse
No announcement yet.

How to Backup KDE Settings?

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

    #16
    Originally posted by PhysicistSarah View Post
    I'm curious if there is a way to back up and restore KDE's settings, ...
    KBackup
    https://www.linux-apps.com/content/s...?content=44998

    Comment


      #17
      KBackup is the classic front end to tar. It creates compressed zip files for local or remote storage. My home account has 90 Gb of data. How long will it take tar to compress 90 Gb of files and directories? 30, 60, 90 minutes? More? How long to copy the file to a remote HD?

      A btrfs snapshot for my ENTIRE home account takes a second to create. Doing a send | receive to a remote HD takes 15 minutes, and it takes place in the background while I continue to use my laptop with no apparent degradation of performance. That’s the power of COW.
      "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


        #18
        Compressed archives are great if you never have to actually use them. Accessing a single file in a 50GB tar archive would take knowing the filename or searching for probably hours through the archive. And the transfer time? Yikes. When I used that sort of backup, I took to doing folders rather than a single archive just so I had a chance to get into them without crashing my machine.

        BTRFS makes backups and restoring a trivial task.

        GG, you'll like this; I put that new 10TB drive into my server and moved (using btrfs send|receive of course) all the media to it - 5.2T of data. Today, I reformatted the 2x6T drives and now I'm making backups from the command line. 15 subvolumes of media, but only three commands!

        To make all the read-only snapshots:

        root@server:/mnt/pool# for i in `ls` ; do btrfs su sn -r $i $i-ro ; done

        To send all the snapshots:

        root@server:/mnt/pool# for s in `ls | grep ro` ; do btrfs send $s | btrfs receive /mnt/backup1 ; done

        To remove all the snapshots:

        root@server:/mnt/pool# for s in `ls | grep ro` ; do btrfs su de -c $s ; done

        Cake.


        Now I'll write a script to to incremental backups automatically.
        Last edited by oshunluvr; May 22, 2018, 09:25 AM. Reason: more info

        Please Read Me

        Comment


          #19
          @GreyGeek Your method is great and useful but for different purpose - like backup entire partition.

          The original question to which I refereed was about Plasma settings. There is no need to backup the whole /home to restore some configuration files that often have a few KiB. All settings from /home of Plasma and applications can take some MiB. Not all need to be always restored. With KBackup single configuration files can be restored in seconds, for example a user mess somethings in settings and don't remember what he did.

          @PhysicistSarah
          application's and KDE's settings are stored in:
          /home/user/.kde/share/config/
          /home/user/.kde/share/apps/
          /home/user/.local
          /home/user/.config

          I don't remember now were exactly are located settings for widget for input devices but I recommend to spend some time and have a look at .kde/share/config/ files or google it.

          Each hidden folder in /home/user/ has some settings that are worth to backup.

          In my opinion the best method is to know different backups methods and use different methods of restoring according to specific needs.
          Last edited by gnomek; May 22, 2018, 09:39 AM.

          Comment


            #20
            Originally posted by gnomek View Post
            @GreyGeek Your method is great and useful but for different purpose - like backup entire partition.

            The original question to which I refereed was about Plasma settings. There is no need to backup the whole /home to restore some configuration files that often have a few KiB. All settings from /home of Plasma and applications can take some MiB. Not all need to be always restored. With KBackup single configuration files can be restored in seconds, for example a user mess somethings in settings and don't remember what he did.

            @PhysicistSarah
            application's and KDE's settings are stored in:
            /home/user/.kde/share/config/
            /home/user/.kde/share/apps/
            /home/user/.local
            /home/user/.config

            I don't remember now were exactly are located settings for widget for input devices but I recommend to spend some time and have a look at .kde/share/config/ files or google it.

            Each hidden folder in /home/user/ has some settings that are worth to backup.

            In my opinion the best method is to know different backups methods and use different methods of restoring according to specific needs.
            I agree that tar would be fine for something small like Plasma setting files and that different methods are useful for different tasks.

            However, I do not agree that using tar to backup an entire file system would work (or at least work well) or even be the best choice.

            Nor do I agree with the choice of the word "partition" as neither btrfs snapshots nor tar makes a partition backup. dd is the only tool I'm aware of that does this.

            When making backups, there is the question of compression - how much space is taken by the backup. For some this is a critical factor. As the btrfs file system itself is capable of compressing files on-the-fly and storing them that way, the one-for-one result of sending a snapshot would not necessarily mean there was no compression - just that compression is transparent to the user. The resulting snapshot backup is also much more readily accessible for the user than any archive will ever be.

            It would be interesting to create a realistic assortment of files and a list of tasks and time them out - tar vs. btrfs.

            Please Read Me

            Comment


              #21
              Originally posted by oshunluvr View Post
              However, I do not agree that using tar to backup an entire file system would work (or at least work well) or even be the best choice.
              Of course if entire file system is considered it would not be the best choice. I wrote about Kbackup so that other users would know about different choices.

              For partition backup I mean for system backup I use Clonezilla. Creating backup from 11GiB partition from /root (without /home) takes me about 15 -20 minutes with checking and backups have about 4GiB on a very slow PC with core2duo CPU.

              To use brtfs method I would have to reinstall my system first. But next time I will do it I will certainly chose brtfs to be able to use that great functionality. To use brtfs method both source file system and the destination disk (that we will keep backup on) must be brtfs. Is that correct?
              Last edited by gnomek; May 22, 2018, 11:33 AM.

              Comment


                #22
                Originally posted by gnomek View Post
                To use brtfs method both source file system and the destination disk (that we will keep backup on) must be brtfs. Is that correct?
                To access the backup files, yes. You can actually "send" a subvolume to a file, but AFAIK you have to "receive" it before accessing the contents. Basically, you do "sudo btrfs send -f some_file @some_subvolume" which creates a file from the subvolume. Then to reverse the process, "sudo btrfs receive -f some_file /some_btrfs_filesystem" and the subvolume is restored. This can be useful if you want to use a USB drive but don't want to format it btrfs. I've even sent btrfs subvolumes over an ssh connection to transfer data from one computer to another.

                I don't know if there are plans to have functionality where you could mount a btrfs backup without receiving it first, but that would be really useful.

                Clonezilla has to be in the top 5 of best free software in the world. I actually carry a bootable clonezilla USB with me when I'm working. You never know...
                Last edited by oshunluvr; May 22, 2018, 01:06 PM.

                Please Read Me

                Comment


                  #23
                  Personally, when making a bkup Of part of / or /home feels necessary taking a snapshot of both is justified. The sum of two fractions of a second still equals a fraction of a second.

                  One thing being overlooked is the difficulty tar has with devices, sockets, hard and soft links, immutable folders and files, etc. That’s why I like snapshots — EVERYTHING is included to the bit level. And, I see no reason to complain about the speed!
                  "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
                    Originally posted by gnomek View Post
                    ...

                    To use brtfs method I would have to reinstall my system first. But next time I will do it I will certainly chose brtfs to be able to use that great functionality. To use brtfs method both source file system and the destination disk (that we will keep backup on) must be brtfs. Is that correct?
                    Not exactly. To store a snapshot on a pool not part of your ruining system you use the “send & receive”. Command. To store it on a device that is formatted with a different filesystem you must add the “-f” switch, which converts the stream into ASCII. Ditto for restoring it. The time taken is the same for either method.
                    "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
                      Originally posted by GreyGeek View Post
                      Personally, when making a bkup Of part of / or /home feels necessary taking a snapshot of both is justified. The sum of two fractions of a second still equals a fraction of a second.

                      One thing being overlooked is the difficulty tar has with devices, sockets, hard and soft links, immutable folders and files, etc. That’s why I like snapshots — EVERYTHING is included to the bit level. And, I see no reason to complain about the speed!
                      Snapshots are so easy and rarely take up any space (unless sent) that I just do them anytime I'm doing anything remotely questionable.

                      Think about this: Ever install something, remove it, then months later find it has left behind cruft? Never happen if you snapshot and restore instead of uninstalling. Even if the installation did damage, you're right back where you started.

                      Now when considering the OP goal of backing up settings, with a little preparation or clean-up you could still accomplish this with snapshots. You could write a script that made and sent a snapshot to a backup device, then deleted the media folders (Documents, Downloads, etc.) in the snapshot leaving you with just the settings and configs. I could write that in five minutes or less. Alternately, separate subvolumes for your media folders would mean you could snapshot/backup individual pieces of your home.

                      Please Read Me

                      Comment


                        #26
                        Originally posted by oshunluvr View Post
                        ...Alternately, separate subvolumes for your media folders would mean you could snapshot/backup individual pieces of your home.
                        Yup!
                        Say you wanted to create a subvolume that contained your data and have it reside at /home/youracct/data

                        Open a Konsole
                        sudo -i
                        mount -t btrfs /dev/sdaX /mnt
                        (where sdaX is where btrfs was installed)


                        The directory /mnt is now the "roof_fs" of your active pool, that contains your running system. Under it are two subvolumes created when you installed Kubuntu or Neon:
                        vdir /mnt
                        @
                        @home

                        I create a subvolume called @data
                        btrfs subvol create /mnt/@data

                        vdir /mnt
                        @
                        @home
                        @data

                        Edit your /etc/fstab file to add the binding of @data to /home/youracct/data
                        Before:
                        Code:
                        :~$ [FONT=courier new][B]cat /etc/fstab[/B][/FONT]
                        # /etc/fstab: static file system information.
                        #
                        # Use 'blkid' to print the universally unique identifier for a
                        # device; this may be used with UUID= as a more robust way to name devices
                        # that works even if disks are added and removed. See fstab(5).
                        #
                        # <file system> <mount point>   <type>  <options>       <dump>  <pass>
                        # / was on /dev/sda1 during installation
                        UUID=47a4794f-b168-4c61-9d0c-cc22f4880116 /               btrfs   defaults,subvol=@ 0       1
                        # /home was on /dev/sda1 during installation
                        UUID=47a4794f-b168-4c61-9d0c-cc22f4880116 /home           btrfs   defaults,subvol=@home 0       2
                        After
                        [code]
                        :~$ cat /etc/fstab
                        # /etc/fstab: static file system information.
                        #
                        # Use 'blkid' to print the universally unique identifier for a
                        # device; this may be used with UUID= as a more robust way to name devices
                        # that works even if disks are added and removed. See fstab(5).
                        #
                        # <file system> <mount point> <type> <options> <dump> <pass>
                        # / was on /dev/sda1 during installation
                        UUID=47a4794f-b168-4c61-9d0c-cc22f4880116 / btrfs defaults,subvol=@ 0 1
                        # /home was on /dev/sda1 during installation
                        UUID=47a4794f-b168-4c61-9d0c-cc22f4880116 /home btrfs defaults,subvol=@home 0 2
                        UUID=47a4794f-b168-4c61-9d0c-cc22f4880116 /home/data btrfs defaults,subvol=@data 0 2
                        [code]
                        That's not a typo. All three subvolumes are on the same device, so the UUID is the same. Use lsblkid
                        $ vdir /dev/disk/by-uuid
                        total 0
                        lrwxrwxrwx 1 root root 10 May 22 11:08 17f4fe91-5cbc-46f6-9577-10aa173ac5f6 -> ../../sdb1
                        lrwxrwxrwx 1 root root 10 May 22 11:08 47a4794f-b168-4c61-9d0c-cc22f4880116 -> ../../sda1
                        lrwxrwxrwx 1 root root 10 May 22 11:08 b3131abd-c58d-4f32-9270-41815b72b203 -> ../../sdc1
                        After changing /etc/fstab and saving the changes,
                        umount /mnt
                        exit
                        exit
                        systemctl reboot


                        Your @data subvolume is ready to receive data. At any time you can make a snapshot of it, and it alone, if you need or want to. It's done the same way for @data as it is done for @ and @home. If you upgrade to a higher release via a fresh install you can bring the @data snapshot from archival backup to /mnt/@data and redo the fstab addition, then reboot.

                        NOTE: Do NOT use /dev/sdaX in fstab because those labels can switch if HD's are added or removed. The UUID's are fixed to a device.
                        Last edited by GreyGeek; May 22, 2018, 06:56 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


                          #27
                          The other really great thing about subvolumes as media storage - if you regularly boot to different distros, you can mount your media subvolumes in each of them. This allows universal access to your personal files without having to search through other home folders in other distros.

                          I'm actually transitioning from separate home partitions to stand-alone media (Documents, etc.) subvolumes instead. Then "home" and it's settings can stay cleanly within each distro. I can also export these subvolumes using NFS, so I can mount them elsewhere on my network for easy access across any device, including my NextCloud install.

                          I will have to host my media on my server, but then I can get my files from any of the 6 computers regularly on my network! Cool.

                          Please Read Me

                          Comment

                          Working...
                          X