In my effort to be more diligent I’m planning on keeping some files under RCS. The only reason this means anything is for scripts and automation. Having a few extra lines to do a ci -u... & co -l... is not that big of a deal but the concept is worth a pause to ask for others’ opinions.
I’m thinking of /etc/rc.conf and of that ilk.
Extra [unnecessary] overhead?
Silly question - why RCS (old school)? why not git or svn?
Generally speaking. Git is for multiple files and decentralized situations; RCS is good for single files like /etc/rc.conf (system/app configs) where you just need to keep a backup for quick roll back if things go wobbly. Very simple situation; me making a change to a config file (no central repo, no other users, nothing …“Opps! I guess that was a bad idea; undo that!”).
I use git for writing programs and stuff.
Now I wonder if you can run zfs snapshot against /etc/rc.conf or anything on boot drive? (a bit lazy personally to run a script to do rcs/cvs/svn/git hehe) - if I was going to do revision control on system files.
Thinking about the situation more, version control may be extra overhead for system config files. I can see this being a timesaver for specific config files like: nginx.conf or obhttpd.conf files where you change a setting/location and need to roll back but system config values are more vetted and single entries. sshd_enable=yes → #sshd_enable=yes. Done. -i.e. The concept of rolling back a system config type file seems kind of dumb.
Snapshots would be overkill too. Especially given the lifespan of them (2 weeks, 30 days, etc). Config errors may take a while to glean and fall outside that window.
On my Linux systems, (desktop, media server, 2 x laptops), I used to use RCS but with disk space cheap today, I do full file copy. (Of course I use OpenZFS on those Linux systems, WITH compression :-).
I have a script that I call “agef”, which copies the file like;
cp -p FILE.EXT FILE.EXT.YYYYMMDD
And if such a destination already exists, add;
cp -p FILE.EXT FILE.EXT.YYYYMMDD_HHMM
Plus, if “.BK” directory exists, use that for the destination files. This is to avoid cluttering up places like “/etc” or my “~/bin/” used for scripts.
On the rare occasion I have to restore, it’s trivial to either “diff” the 2 files and figure out what changed. Or just copy the backup file into place.
On the subject of snapshots. I run 2 sets of snapshots;
The second set was designed to accommodate laptops, which might be shutdown at any time. But, I still wanted to have once a day snapshots. For example, I take the Monday one at 12am, then at 1am I remove the 12am snapshot so I can take another Monday one. Repeat until 11pm. Then start the Tuesday weekday snapshot… Confusing but works for me.
And yes, I have used the snapshots for restoring files. Perhaps a few times a year. So far for nothing serious, just a time saver to re-create what was lost.
if your going to do edit in cli - just make an alias to do a backup (with datetime??? in a different directory of course, don’t want to delete actual file in question by accident heheh) before loading it into an editor.
Think one step further and do it the other way round:
Kind regards,
Patrick
@Arwen , @somethingweird: dated files is a bit too low tech for me.
Snapshots is a bit like using a sledgehammer when all you need is a scissors to me. I mean, rsync would be easier right?
@pmh:
I just found one config management system called Rocinante, last night, which seemed to work. But I will read up on those two. Thank you.
My only gripe about that one system in particular (granted I just started looking at it) is “alterations” (not the best word). -i.e. If I were to switch to using an alternate–from “OpenXYZ” to “LibreXYZ”–can I specify that config mgmt. system to “remove items” as well as “add” them?
No, snapshots are not like a sledgehammer. If you are already using OpenZFS, then snapshots are for practical purposes free and easy to use.
OpenZFS snapshots, (not Oracle Solaris ZFS snapshots), can be mounted automatically as R/O. So a restore is as simple as changing directory into the proper snapshot and finding the file. Then copy it back to the original place, (if restoring it).
Now snapshots have to be managed. Some people end up with thousands and too much space taken up. Then have trouble removing the old ones. That’s the users fault, not the snapshot’s fault.
In my case, they are self managing. The single day, hourly ones are exactly 24 and the day of week ones are exactly 7. Here is the rough hourly, on the hour, cronjob;
/sbin/zfs destroy ${MY_HOME_DATASET}@${MY_DAY_OF_WEEK} >/dev/null 2>&1
/sbin/zfs snap ${MY_HOME_DATASET}@${MY_DAY_OF_WEEK} >/dev/null 2>&1
/sbin/zfs destroy ${MY_HOME_DATASET}@${MY_HOUR_OF_DAY} >/dev/null 2>&1
/sbin/zfs snap ${MY_HOME_DATASET}@${MY_HOUR_OF_DAY} >/dev/null 2>&1
The only trouble that can happen, (and it has not happened to me in the 7 years I have been using them), is that if ransomware encrypted all my files, or something else re-wrote all the files. Then the snapshot would take more than a trivial amount of space.
To be clear, OpenZFS snapshots are DIFFERENT from VMWare and Linux LVM type snapshots. Both of those are meant to be temporary, as in a few days at most. And not meant to have many of them. Both, if I understand them correctly, REQUIRE flushing the snapshot storage back into the real storage upon removal of the snapshot. That flush can take hours, even days if the snapshot was kept too long. (If the snapshot storage even had the space to maintain the snapshot beyond a day or so!)
That last is because those snapshots, (VMWare & Linux LVM), act more like transaction logs, than what OpenZFS does, (use pool free space…). While it may take OpenZFS time to take a deleted snapshot’s space and move it back to the free space list, this happens in the background. Far different than VMWare & Linux LVM.
Ok, let’s step back a second. I have no doubt you have a good snapshot system (not debating that). But I will explain my sledgehammer stance for system configs.
We can say—for the sake of argument—that a snapshot, dated backup, or rsync, is essentially the same in that, we only have a date to go back on for restorations. In the case of “a hack” a date would work just great. But to my point, a date is not a “why” or “what”; to decide to restore something back or not, you want those pieces of information because you are typically reacting to a situation or a result. With a version control, even a simple one like RCS you’d have the ability to have $Id$ and $log$ in the file to refer to or to use ident to find out ‘what’ and ‘why’ changes were made and react accordingly -e.g. “Oh, I understand the idea, I just forgot to enable THIS or THAT and my problem would be fixed”.
Now with RCS we don’t have concepts in newer version control like cherry picking but, I was aiming at/for built in tools with no overhead for this concept. Tools like RCS, in this example, are old but it works pretty good for a simple case like this. For example, RCS locks the file (so you don’t get accidental edits). But the question of something like version control being useful for system configs is something I am debating (is it a good idea to keep records of ‘why’ I changed something or not). Obviously knowing ‘why’ is good but can this be achieved with a VCS, comments in files, etc…
Now, of course I’d have snapshots for my datasets and things I care to save. But that’s not my question about should I use something like RCS. In the case of a hack, I have my data snapshot-ed; the system is garbage at this point. Reinstall the OS, and put the data back.
Understood about revision controlled files, verses snapshots.
In my case, I keep revision comments, (which include date changed), inside the files. Having an extra comment on what / why the change was made in the RCS / Git log is not needed. So a simple dated backup file is fine for me. The locking of the file is nice, though, (again for me), is not needed as I am the sole changer.
Of course, snapshots are less useful if higher granularity is needed. For example, my hourly snapshots prevent me from seeing what the file looked like 5 minutes ago after another change. (Except if the hourly snapshot occurred by pure chance.) But revision control software takes care of those cases.
I’d have to setup another set of snapshots, every minute, for the last hour, (60 total). And that seems a bit excessive, even for someone as paranoid as me.
To each their own.
I setup snapshots every 10m kept for
2 hours. Works well. I found issues with 1m snapshots.
Adds a max of 12 snapshots per dataset, as I’m not taking empty snaps for this one.