How to Backup KDE Settings?

[PhysicistSarah]

Hello,

I'm curious if there is a way to back up and restore KDE's settings, such as system settings for keyboard, and mouse, and things like taskbar and widget placement as I often find myself having to do hours of configuration after each integer release of Kubuntu. I use Deja-Dup and Aptik to back up some things, such as files and program settings, but KDE's widget/input device settings aren't included.

[vinnywright]

I think "most" of the configs for the things you have mentioned are contained in the hidden "." files in your /home/you/ directory and mostly in .config , .local , and .kde + /user/share that contains a lot of installed things .

VINNY

[PhysicistSarah]

So I should keep all the hidden files/folders in ~ and /usr/share?

Just curious, if I kept all the files using an Aptik backup from my home folder (And all subfolders) and root, would that be enough to keep all the toolbars and settings?

[chimak111]

Let's look at ~/.config/khotkeysrc as a example.

Here's a bit from that file:

[Data_13]
Comment=Launch virt-manager
Enabled=true
Name=VM
Type=SIMPLE_ACTION_DATA

[Data_13Actions]
ActionsCount=1

[Data_13Actions0]
CommandURL=virt-manager
Type=COMMAND_URL

[Data_13Conditions]
Comment=
ConditionsCount=0

[Data_13Triggers]
Comment=Simple_action
TriggersCount=1

[Data_13Triggers0]
Key=Meta+J
Type=SHORTCUT
Uuid={4543a6e4-1a27-408a-a109-d6732a3a4071}

I would imagine that because of lines such as
[Data_13Triggers0]
and
Uuid={4543a6e4-1a27-408a-a109-d6732a3a4071}

just transposing that file from elsewhere (your backup source) to a new system may not work as intended.

My take on backups ...

• there are actual data (documents, images, music, etc) which you will obviously back-up and can successfully transfer to a new system (provided that the relevant program in the new system is backwardly compatible with your data files)
• for config files, as the example above may illustrate, a simple copy/paste may not do the job
• I keep notes (which I backup) on how I achieve a particular configuration and then repeat the steps on a new system so that the system can generate "current" Uuid's or whatever

[GreyGeek]

How I backup and restore:

https://www.kubuntuforums.net/showth...l=1#post403412

[oshunluvr]

AFAIK and IMO, in a general sense, no user settings or configs should be made in /usr or anywhere other than /etc or in your home. If for no other reason - because they won't survive a package upgrade. There also are no hidden files in /usr so you'd be saving nothing.

Assuming you know what you're doing when you muck about with your system, you will still need to document what you did so you can repeat it if a package update wipes your edits. Always better to have your stuff in your home. Then it's safe. For example, I edit the "Application Dashboard" to my liking. I don't edit the files in /usr/share/plasma/plasmoids/org.kde.plasma.kicker/, instead I copied them to ~/.local/share/plasma/plasmoids/org.kde.plasma.kicker/ and edited them there.

I'm not sure exactly what the intended result of what you're asking for is. A minimal backup or the ability to duplicate an install or what?

If you just want to backup your KDE user settings, they are all in your home. Just make a backup of everything except your data folders. If you want to retain system settings you've changed, backup all the files in /etc that have a "modified" time of 1 day after installation. For example;

sudo find /etc -type f -mtime -10

will list all files modified newer than 10 days in /etc. I used "sudo" because some files in /etc aren't user readable (not many), the option "-type f" means only files not empty folders, and the "-mtime" option means the files was modified 24hrs times the number you put in (10 in this case) ago from right now.

You could dump them right into a file with something like:

sudo find /etc -type f -mtime -10 | xargs -0 tar -rcf my_saved_files.tar.bz2

or even just use tar to find the files:

tar --newer-mtime='2018-01-01 12:00:00' -jcvf my_saved_files.tar.bz2 /etc/*

This instructs tar to compress files newer than noon, January 1st 2018.

EDIT: Changed "-N " to "--newer-mtime=" in the above command for correct functionality.

[oshunluvr]

Also; your widget settings may not transfer correctly anyway. IME, the whole way widget settings are handled are wonky from a raw-user view opposed to how the developers and Plasma see them. The way these are stored has changed several times and will likely again. Assuming you were doing a re-install and not transferring to a different distro or a newer release, it would probably work.

[PhysicistSarah]

Hmm, I'm getting the feeling that power users use BTRFS. Too bad they didn't have a sign not to use EXT4, I wouldn't have chosen that filesystem type. Although, I did read that BTRFS was a bit slower than EXT4, but I'm not equipped to judge. I wonder why BTRFS isn't considered "stable" or why EXT4, which seems more mature, didn't include such nice features.

[oshunluvr]

Hmm, I'm getting the feeling that power users use BTRFS. Too bad they didn't have a sign not to use EXT4, I wouldn't have chosen that filesystem type. Although, I did read that BTRFS was a bit slower than EXT4, but I'm not equipped to judge. I wonder why BTRFS isn't considered "stable" or why EXT4, which seems more mature, didn't include such nice features.

Yes, EXT4 is faster. It's also a stop-gap measure (the EXT4 developers words, not mine) to bring a few needed changes to EXT, but it is not being developed any longer and will die eventually.

The word "Stable" has several meanings in English and is usually mis-used regarding Linux development. "Stable" when referring to a Linux package or function means "no longer having features being added". Debian Stable is a release that receives only bug fixes but no new features or packages, where Debian Unstable continues to be developed. BTRFS is not stable because it is still receiving new features and functionality. EXT4 is stable because it will not be upgraded or have functionality added to it, likely ever.

The fact the EXT4 is somewhat faster than BTRFS in some cases isn't surprising. Nor is it that F2FS is in some and XFS in some others - over both BTRFS and EXT4. If there was one file system faster, safer, better than all the others - we'd have only one. The question to ponder is "Does the added speed of EXT4 over-ride the benefits of BTRFS?" In my, and some others views here, the benefits of btrfs FAR out-way a few percentage points in transfer rate. Some examples of those benefits:

• Subvolumes: logical containers that segregate files from others without requiring separate partitions. Free space is shared among all subvolumes.
• Snapshots: Subvolumes can be snapshot-ed at will and used as backups (via send|receive functionality) or for system roll-backs.
• Multiple device support: Devices (drives, partitions, etc.) can be added or subtracted from a btrfs file system at will to increase or decrease storage capacity.
• Native RAID support: Multiple devices can be configured at many different levels of RAID - or de-configured from RAID at will.
• Continuous on-line data: During all file system adjustments except error-checking and repair, the file system remains on-line - i.e. you can expand or contract storage without unmounting a file system and may continue to use it.

Myself, I have a single BTRFS file system on my desktop that contains 8 boot-able distro installs, two homes, and a stand-alone grub install - all in subvolumes but on the same partition. Last week, a very old (10 years) hard drive on my server began to show errors. I "removed" it (move all files off the drive), pulled it from the server, inserted the replacement drive, "added" it to the file system and "balanced" it (spread files over the newly available space). Then, since the new drive was quite a bit larger than the one it replaced, I decided to move all my media onto it, reconfigure two older drives from RAID1 to stand-alone, and use them as backup devices instead of primary storage. I did ALL of this without taking my file storage off-line or rebooting my server. NONE of this is possible with EXT4 or any other file system without backing up, rebooting, reformatting, and restoring. You can decide for yourself which file system serves your needs but BTRFS is untouchable IMO.

[GreyGeek]

Hmm, I'm getting the feeling that power users use BTRFS. Too bad they didn't have a sign not to use EXT4, I wouldn't have chosen that filesystem type. Although, I did read that BTRFS was a bit slower than EXT4, but I'm not equipped to judge. I wonder why BTRFS isn't considered "stable" or why EXT4, which seems more mature, didn't include such nice features.

Btrfs has been marked "stable" for over a year. EXT4 is a journaling system but is too old to include Btrfs features. Tso, who supports EXT4 and Btrfs, says that Btrfs will eventually replace EXT4 as the default. In my own experience on my Acer V3-771G with an i7 CPU and 6GB of RAM working against three 750Gb WD HDDs I find that Btrfs is no slower than EXT4 on this machine, for what I do. Note, however, that I do not use compression or quotas. And, IF you are going to use SSD's then Btrfs is the way to go. You can create snapshots and "send | receive" them to another drive, internal or external or remote. When the SSD does its instant failure to boot trick, without warning, you are prepared because you can replace it with an equal or larger SSD, reinstall the distro, choosing Brtfs, and after it comes up do a "send | receive" back to the fresh install, replacing the new @ and @home with your last snapshot. Probably 60 minutes or less additional time after the install, depending on how big your @home is.

I started with a single drive Btrfs install, added a second drive and converted the pair to a RAID1 without loosing a byte of data, added a 3rd HD for an additional pool storage, then reverted the RAID1 to a SINGLE again, making the second drive an additional storage pool. I also have a external 320GB USB HD for another additional storage pool. In all these manipulations I've never lost a byte of data, and all of the work was done on my live system while I was using it. I won't run a distro that doesn't give me Btrfs as a root file system option.
At any time I could create another subvolume, say @data, and bind it to "/home/data" in /etc/fstab and make its owner me:me and use it as my data storage, creating snapshots and offloading the snapshots to storage pools or remote pools. Ditto for restoring from a snapshot. Even though I bind it to /home/data and fill that subvolume with files, if I browsed through @home I'd see that data is empty because it is its own subvolume. If I browse through @ I'd note that home is empty as well. It's data would be in @home just like /home/data's data would be in @data.

[oshunluvr]

Yes, to be technically correct, the btrfs file structure is "stable" - meaning future upgrades to btrfs-tools (the added features) will not require re-formatting of btrfs file systems. However, btrfs-tools is still under constant development and new features are being added and existing ones improved.

[PhysicistSarah]

@GreyGeek Yeah, I just need to look around for a few tutorials so I can find the magic words, then I'll probably switch my system over. The safety of snapshots is really appealing. Sooner or later something is going to go wrong.

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

[PhysicistSarah]

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

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