To understand why it's so important to backup your dotfiles, we have to define what a dotfile is. A dotfile is a file which's name begins by a dot (.) and are generally located in your home directory (/home/yourusername on Linux).
Some common dotfiles are : .gitconfig, .bashrc or .viminfo. You can have a look at all the dotfiles that you have by opening a terminal in your home directory and typing the command ls -ld .* | grep -v '^d' which will list all the files beginning with a dot.
From there, you can have a look at some of those files by opening them in a text editor or just by cat-ing them. You can find even more of those files in the .config directory, here they may not begin with a dot but they can still count as dotfiles.
You will notice that these files are generally related to some package that you have installed on your computer. These files contain configurations for the software to which they relate, but for some of you, this is not a discovery.
You may have already edited some of these dotfiles, for example .bashrc in order to add some useful aliases or if you have set some global parameters for Git like your username and email with the Git CLI, they are probably stored into the .gitconfig file.
As you can imagine, the longer you are using the OS that your computer runs, the more likely you are to have made configuration changes to the software you use every day. Hence, this configuration is likely stored in these stealthy files which are most of the time hidden in plain sight.
Now that we have identified what these dotfiles are and how useful they can be, we might want to know how to back them up!
To build an efficient backup workflow for your dotfiles, I recommend two tools: Git and RCM. I will not go on to explain what Git is because if you are reading this article, you probably have a rough idea about how Git works. It's part of the most used tools of a DevOps engineer.
Git will be useful in our case because it does two things incredibly well: versioning and sharing files. Versioning can be useful in the case of dotfiles because if you version them and make a change that breaks your configuration, you can easily revert to a previous working state.
The sharing part is also important to a certain extent, because generally when you want to share a Git repository with a team, you use web services such as GitHub or GitLab. Therefore we can imagine that versioning our dotfiles using a Git repository with a remote origin into GitHub or GitLab. Makes sense!
However, as we have seen in the previous section, dotfiles can be scattered around our home directory and hidden into subdirectories. Creating a Git repository into your home directory is not an option, as you don't want to version everything in there. Even with a big .gitignore file, it will be a pain to manage. What could ease up this task is a way to assemble all of those dotfiles into the same directory which will be your Git repository: enter RCM.
RCM is a set of CLI utilities that will help us in doing what we've just said. You can find installation instructions for plenty of OSes on their git repository. Let's unpack what you get with RCM :
mkrc : bless a file into a dotfile managed by RCMlsrc : list the dotfiles managed by RCMrcup : update and install dotfiles managed by RCMrcdn : remove dotfiles as managed by RCMPro tip: you can easily remind yourselves what the RCM commands are with the manual pages that you can display with the command man rcm. There is also a manual page for every CLI utility.
What you can ask yourselves after reading this list is: what does "managed by RCM" mean? It's pretty simple: when blessing a file with mkrc , RCM replaces it with a symbolic link pointing to the original file that RCM stores into a directory named .dotfiles . As a reminder, a symbolic link is a special kind of file that points to another file.
A side effect you should expect is that when moving the original dotfile into the .dotfiles directory, RCM strips the dot in the file name in order to make them more visible than generic dotfiles. Here are two examples :
.bashrc dotfile. To do so, I can use the mkrc .bashrc command, which will move the file here : /home/yourname/.dotfiles/bashrc and create a symbolic link with the same name and path as the original file.config file which is in the .aws directory. Same as above, using the mkrc .aws/config command will move the file to /home/yourname/.dotfiles/aws/config and create the symbolic link.As we can see, RCM is great because it keeps the same arborescence between the home directory and the .dotfiles directory. With mkrc , the utilities lsrc and rcdn will help you manage which dotfiles you want to synchronize into the .dotfiles directory.
Now, what we have is a selection of dotfiles that are saved into the .dotfiles directory and have links that point to them in place of their former location in the home directory. What about how we can back them up and restore them?
To begin, create an empty private repository named ".dotfiles" into your GitHub or GitLab account (we'll assume you are using a GitHub account with a linked SSH key for the next examples) without a readme file.
Initialize a git repository into your .dotfiles directory with the git init command and link it with the remote origin you created in GitHub by following the instructions on your GitHub repository.
When into the .dotfiles directory, running the git status command will show you which files can be added and committed to the git repository. From now on, when you add, update or delete files from the .dotfiles directory with the RCM commands, you can add them to the repository, create a commit and push it to your GitHub repository.
Congratulations, your dotfiles are now safely backed up 🙂. Git will also help you keep your configuration versioned so that if you apply a change you might want to revert, there will be no obstacle to doing that.
Creating a private repository is important in my opinion because you may want to save some dotfiles that contain sensitive information like credentials. However, keep in mind that if you choose to do so, you should definitely secure your account with at least a strong password and 2FA.
You might also consider using a tool like git-crypt to encrypt sensitive dotfiles so that they are safe to store on GitHub.
Imagine you just decided to make a fresh install of a new Linux distro that you wanted to test. To gather back all your configuration settings stored into your dotfiles, here are the simple steps you need to follow :
rcup -v (the v options shows which files are synchronized)And voilà! Your programs are configured like before.
With those two procedures, you can now have an easily portable and replicable OS configuration that you may use on one or multiple machines, as you wish!
As a last tip, you might want to be able to manage your .dotfiles repository from anywhere in your filesystem instead of having to cd into it. To do so, define an alias like so : alias dot='git -C $HOME/.dotfiles' .
Now, with the dot command, you will be able to simply run dot add . to schedule every modification into a commit, then dot commit and dot push to update all of your dotfiles in the remote repository.
We covered how to backup and restore dotfiles using a simple workflow with Git and RCM. I have personally been using it for some time now, and it has saved me countless hours when distro-hopping to discover new OSes.
However, you may know another way of achieving just this with other tools like dotbot. If so, let us know! Feel free to browse around Padok's blog to learn more about DevOps tools and practices.