Some changes in backup mechanism

Archives Ansible Project
1

File modules of ansible (“copy”, module and some others) can do backup of changed data. The standard naiming schema (timestamping and adding ‘~’ in original directory) can have bad effects in “conf.d”-like distros.

Main idea: all backups placed into separate directory tree, based on /var/lib/ansible.backups. 1st backup is suffixed by ‘.orig’, 2nd and more later are suffixed by timestamp. This schema is more reliable, and I made patch for it.

New schema example:

/var/lib/ansible.backups/etc/zabbix
/var/lib/ansible.backups/etc/zabbix/zabbix_agentd.conf.20130622-172930
/var/lib/ansible.backups/etc/zabbix/zabbix_proxy.conf.20130622-172959
/var/lib/ansible.backups/etc/zabbix/zabbix_proxy.conf.orig
/var/lib/ansible.backups/etc/zabbix/zabbix_agentd.conf.20130614-033941

/var/lib/ansible.backups/etc/zabbix/zabbix_agentd.conf.orig

Do you interested it? If so, how can I commit this changes into main tree?

2

Since tasks are run as potentially different users (none of which may have root access), creating a common directory for backups may not work. Most likely, if this were implemented, the backup directory would have to be under the user’s home directory by default.

3

I think, that mostly all ansible users work as root - native or over sudo. OK, path for backups can be changed.

This is not “if this were implemented”. This is implemented by me :).

Old (native) backup’s mechanism is unusable:

  1. It has potential conflict with “conf.d”-like distros
  2. There is data overriding when file is modified twice in one playbook, for example, many “lineinfile” step-by-step. The first modification will make backup with pattern %Y-%m-%d@%H:%M~, and the second one will override this backup. Original file will lost, it is a BIG problem for production systems!
    I changed the pattern to %Y%m%d-%H%M%S, and added version number suffix to it, if this file still exists (if step-by-step modifications will be in same second).

I can push this modification into new git branch, and you can check and modify it (add homedir in backup path, etc.), and merge into devel branch.

4

I would be interested in seeing and commenting on the pull request.

We can see what it looks like and go from there.

Thanks!

5

I made the pull request (username: vshkolin)

6

What is the status of this? My team would find a feature like this immensely helpful.

It would be additionally useful if you could force it to only maintain X backups in said backup directory.

I see nothing in the changelogs about this.

7

Remote backups?

Honestly haven’t had time to attack. I’ll bump the priority though so it doesn’t get lost in the shuffle – it’s a good idea – and an OLD idea :slight_smile:

8

Yes I did see that it was several months ago… hooray for necro-posting.

But no, I was not suggesting remote backups. Simply put, it would be nice if I could:

  1. tell ansible what directory to backup files to ( our playbooks run as root so permissions aren’t a concern for me )
  2. tell ansible how many backup files to maintain ( at least in 1.6.2, if I say “backup=yes” and then run a playbook 5 times, there will be 5 backups (assuming the file is changed) )

I’m new so it’d take me awhile, but if there are problems with vshkolin pull request, let me know and perhaps I can re-implement it.

9

Yeah I’ve had this idea for a year and a half it seems.

I’m proposing we do keep the backups on the ansible control machine in a configurable location with a number-to-keep.

When I mean remote, I pretty much mean the control machine vs a delegated host, but that could obviously be a NFS mount.