This message was deleted.

im asking the folks about the triage specifics, as i dont know for this project, however having just made a different but similar PR to the backup stuff for something else, i know how to fix this one, so ill put a PR in for the specific issue

awesome ❤️

ok PR in, opted to remove the cache from any scope, but ill see what the dev team do with it

It’ll be in the next release 🙂

@NickB my feeling is remove it entirely. backups are performed far more often than restores, you aren't losing any data by eliminating the cache, and I'm not convinced that rebuilding the cache from the source would be materially slower than restoring it (especially if you take into account pulling / copying in the extra-large backup file in the calculation)

if someone cares: doing the

all

backup job here takes 11 hours, mostly due to the environment sizes and because

tar

is single threaded

I hadn't looked into it yet myself, but I do find the backup time somewhat absurdly long

and deploying all those envs takes around 1-2 hours

ours is not 11 hours long tho 😁

😄

in fact, when I did my 2021.7.0 upgrade I think waiting for the pre-upgrade backup I did took 2-3 times longer than the upgrade itself. lol

and if people are interested in more contributions to puppet-backup, to make it even faster/more efficient: someone just needs to flip the repo public 🤫

it certainly discouraged me from taking a quick backup prior to the 2021.7.1 update

yeah I had that planned as a step in our upgrade plan, but got rid of it again

I do VM snapshots anyway, but... also would do more `puppet-backup`s if they didn't take so darn long

backing up config + certs now takes 90 seconds. that's fine and we will run it now via systemd timer on a regular basis

I guess it’s still going to get excluded in the

all

case. It just won’t be excluded in

--scope code

nm, it’s not in the included path for code

ah perfect