NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Apologies in advance for driving this threat off-topic and bike shedding... On Wed, Jul 16, 2014 at 12:51 AM, Rodger R. Getz <rgetz@xxxxxxxx> wrote: > Obviously, you need to implement a cron job that tars or bzips up critical > system files like that and maintain a rotating archive That sounds suboptimal. Regular backups are important (though I would opt for a dedicated tool instead of writing a custom script), but this particular case calls out for at least the use of version control, and preferably a configuration management tool (e.g. Puppet, Chef, CFengine, etc). This makes much scaling the number of admins and/or server incredibly less painful. In addition to recording *what* changed, you also get a record of *why* changes were made. Also, it becomes trivial to have identically configured servers for redundancy or load purposes. I could go on at length, but I'll spare the list. (Full disclosure: I'm guilty of not taking my own advice on my home machines. They're backed up, but I abandoned my effort to use Ansible after a few hours of getting it set up because I got distracted by some other shiny object.) -- Ben Cotton
ldm-users archives: