How to Backup KDE Settings?

[oshunluvr]

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.

[GreyGeek]

...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:

:~$ [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.

[oshunluvr]

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.

[GreyGeek]

...

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.

[GreyGeek]

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!

[oshunluvr]

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...

[gnomek]

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?

[oshunluvr]

@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.

[gnomek]

@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.

[oshunluvr]

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.

[GreyGeek]

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.

[gnomek]

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

[GreyGeek]

I resigned from teaching to start my own computer consulting / criminal forensics business. I always used a version control system that allowed me to backup my code and label the backup, or, Branch the code to add or experiment with features, and merge the branch with the head or roll back to a labeled point. To me, Btrfs gives me that kind of flexibility with my filesystem.

For example, I have several Gb devoted to SageMath and its files and my projects. In a snapshot I have 6Gb of Orbit2010. I can add it to my working system by copying it in or mounting the snapshot.

Inadvertently delete a file or directory (or change you mind if it was deleted deliberately)? No problem. Mount your last snapshot and drag & drop them back to where they were. Umount the snapshots. Done.

[PhysicistSarah]

Ok sounds great. I'll get a snapshot from gnome disks and post it.

[oshunluvr]

Sooner or later something is going to go wrong.

Yes, that's for sure.

How you "switch over" will depend on your current configuration. When you're ready - start a new thread and post your drive(s) partitions to get started. By far, the easiest way is to do a new install, but you may not be in the mood to go through that. I have migrated installs to btrfs before, but it's not super-simple.

There is a btrfs conversion tool (EXT3/4 to BTRFS) but I believe it's no longer maintained and therefore of questionable value. Even with it, you still have to migrate the actual files to a subvolume before you reap the benefits of btrfs.