LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 01-16-2016, 08:28 AM   #1
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
Backup tool (or strategy) for system config files


I am currently looking for a more powerful solution to backup system configuration files. Currently I am rsyncing the most relevant directories such as /etc and others through a cronjob on a regular basis. This is fine for mere backup requirements and covers the recovery scenario well.

However, it is not so convenient if you do frequent reinstalls or play around with different distros. Certainly you can use these backups as a source for inspiration and copy-paste most of the configuration files, but it stays a somewhat manual process to apply the backup to a new install.

So what I am looking for is a somewhat more declarative state of the current configuration, which at the same time is restricted to the files I actually modified myself with respect to their default state. By declarative I mean that it should not be a patch type of solution that replays diffs on a given initial state. It should be something that I can use to reach the desired target state irrespective of what the original state was.

At the same time it should not create too much additional overhead while actually modifying the current config.

The first idea was to create a git repo of the rootfs and track everything relevant
Problems:
- Lots of noise due to irrelevant files, or need to gitignore a lot of stuff
- Need to actively commit changes and sometimes add previously untracked files
- Need to maintain a git server => additional overhead

My current train of thought is a self-built solution (probably a script) that is a wrapper to vim along the following lines:
Whenever I use it to modify a file it would first call vim and let me do the modifications. When I am done it will place a copy of the new file at a dedicated isolated location in my system (which in turn gets backed up through the standard way).
I could probably build in some conflict resolution checks, like when the config file I am about to edit has diverged from the copy since the last time because some package maintainer rolled out a new config or similar.

The advantage would be a clean backup directory with only the files I am actually interested in. I'd probably also want to save their respective original state so that when applying the config to a new system, the following logic could apply:
- System default file looks like .orig file in my backup? => roll out my version of the config. Otherwise enforce conflict resolution through user interaction.

Now before I start putting something together I'd be interested to hear your thoughts on the above, especially with respect to the following questions:
1) Are you aware of better approaches to address the issue?
2) Does anything like the proposed solution exist already?
3) Any opinions on the proposed approach?
 
Old 01-20-2016, 12:52 PM   #2
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 23,268

Rep: Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522
Quote:
Originally Posted by joe_2000 View Post
I am currently looking for a more powerful solution to backup system configuration files. Currently I am rsyncing the most relevant directories such as /etc and others through a cronjob on a regular basis. This is fine for mere backup requirements and covers the recovery scenario well.

However, it is not so convenient if you do frequent reinstalls or play around with different distros. Certainly you can use these backups as a source for inspiration and copy-paste most of the configuration files, but it stays a somewhat manual process to apply the backup to a new install.

So what I am looking for is a somewhat more declarative state of the current configuration, which at the same time is restricted to the files I actually modified myself with respect to their default state. By declarative I mean that it should not be a patch type of solution that replays diffs on a given initial state. It should be something that I can use to reach the desired target state irrespective of what the original state was.

At the same time it should not create too much additional overhead while actually modifying the current config.

The first idea was to create a git repo of the rootfs and track everything relevant
Problems:
- Lots of noise due to irrelevant files, or need to gitignore a lot of stuff
- Need to actively commit changes and sometimes add previously untracked files
- Need to maintain a git server => additional overhead

My current train of thought is a self-built solution (probably a script) that is a wrapper to vim along the following lines:
Whenever I use it to modify a file it would first call vim and let me do the modifications. When I am done it will place a copy of the new file at a dedicated isolated location in my system (which in turn gets backed up through the standard way).
I could probably build in some conflict resolution checks, like when the config file I am about to edit has diverged from the copy since the last time because some package maintainer rolled out a new config or similar.

The advantage would be a clean backup directory with only the files I am actually interested in. I'd probably also want to save their respective original state so that when applying the config to a new system, the following logic could apply:
- System default file looks like .orig file in my backup? => roll out my version of the config. Otherwise enforce conflict resolution through user interaction.

Now before I start putting something together I'd be interested to hear your thoughts on the above, especially with respect to the following questions:
1) Are you aware of better approaches to address the issue?
2) Does anything like the proposed solution exist already?
3) Any opinions on the proposed approach?
I can tell you what I do, which is both a kludge, but effective.

Take a file like /etc/samba/smb.conf for example. I created a directory in /usr/local, called (amazingly enough), /usr/local/config. I will move the file to that directory, and create a symlink to the 'real' location. So banging in "vi /etc/samba/smb.conf" will pull up that file, and let me edit it. Same with any OTHER configs/system files I change...symlinks all around. I also have a shell script in that directory, which I modify as I go, which re-does the configs after a reload...nothing but removing the existing file, and creating the symlink.

That way, as long as I have the /usr/local/configs directory backed up, I can re-do my service configurations in seconds. Yes, it's clunky, but effective. Also, if you're working with other admins, they don't have to know/do anything special to edit a config. The symlink does the heavy lifting. I experimented with creating an RPM of my configs, but that was a HUGE pain, for very little return.
 
1 members found this post helpful.
Old 01-21-2016, 04:00 AM   #3
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
Hi TBOne, thanks a lot for your reply. In fact in the meanwhile I have put something together which pretty much already does what I want, but your way sounds like a very smart solution that could be a useful source for inspiration. Can you expand a bit on
Quote:
Originally Posted by TB0ne View Post
I also have a shell script in that directory, which I modify as I go, which re-does the configs after a reload...nothing but removing the existing file, and creating the symlink.
Would you mind posting the script? I am assuming that over time you have accumulated a couple of tweaks that handle problematic situations, and it would be interesting to see those.

Do you actually recreate the whole directory structure in /usr/local/config? I.e. would your samba config sit in /usr/local/config/etc/samba/smb.conf or /usr/local/config/smb.conf?

How much trouble do you have with system updates removing your symlinks and replacing them with the config file version the package/distro maintainers thought where right for you?
 
Old 01-21-2016, 08:39 AM   #4
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 23,268

Rep: Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522Reputation: 6522
Quote:
Originally Posted by joe_2000 View Post
Hi TBOne, thanks a lot for your reply. In fact in the meanwhile I have put something together which pretty much already does what I want, but your way sounds like a very smart solution that could be a useful source for inspiration. Can you expand a bit on

Would you mind posting the script? I am assuming that over time you have accumulated a couple of tweaks that handle problematic situations, and it would be interesting to see those.
The 'script' is actually trivial. All it consists of is something along the lines of:
Code:
rm /etc/samba/smb.conf
ln -s /usr/local/configs/samba/smb.conf /etc/samba/smb.conf
Repeat for each file you put in there. The hard part is being diligent about putting things in there after you make changes. I've not had anything be problematic thus far, and the things I have had issue with were simple permissions issues/ownership issues. The restores will sometimes write those files back as root, and some services squawk about it. Nothing that's not fixed with a chown and restart.
Quote:
Do you actually recreate the whole directory structure in /usr/local/config? I.e. would your samba config sit in /usr/local/config/etc/samba/smb.conf or /usr/local/config/smb.conf?
I will typically build out the /usr/local/configs/samba directory, and put the files/directories FROM /etc/samba in it, but that's just preferences. This way, each service I have modified a config for, is in something intuitive, at least for me. Your mileage may vary.
Quote:
How much trouble do you have with system updates removing your symlinks and replacing them with the config file version the package/distro maintainers thought where right for you?
None, really, because all it does is over-write the symlink with a 'real' file, or move it to a .bak/rpmnew filename. My original is safe in /usr/local/configs. So, a quick re-link puts it back like it was. If it DOES overwrite my file by following the symlink, it's nothing to restore that directory from backup...small text files, come back in seconds.
 
1 members found this post helpful.
Old 01-21-2016, 11:15 AM   #5
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Original Poster
Rep: Reputation: 307Reputation: 307Reputation: 307Reputation: 307
Thanks a lot for these clarifications.
Quote:
Originally Posted by TB0ne View Post
The 'script' is actually trivial. All it consists of is something along the lines of:
Ok I see, I thought you had built more automation into that whole process but I guess it's good to be forced to do some manual review, too.

Will have to think this through a bit, but as I said before, now that I have already written something which seems to work I guess I'll stick with that for the time being. But if it turns out to be unsatisfying I'll give your idea a try, too, so thanks again!
 
  


Reply

Tags
backup, config


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
kconfig-diff - tool to compare kernel .config files atelszewski Slackware 2 10-31-2015 01:43 PM
yast system backup tool - badly configured...!? ungua SUSE / openSUSE 0 01-11-2007 01:00 PM
Display problems running the system-config-printer tool donraja Linux - General 1 09-17-2006 10:01 PM
system-config-network tool unusable + very slow boot anax93 Linux - Wireless Networking 3 07-26-2006 01:46 PM
Config files to backup mouldy_punk Linux - General 3 02-19-2006 06:27 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 04:30 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration