Re: [PATCH v2] packfile: freshen the mtime of packfile by configuration

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jul 14 2021, Martin Fick wrote:

> On Wednesday, July 14, 2021 8:19:15 PM MDT Ævar Arnfjörð Bjarmason wrote:
>> The best way to get backups of git repositories you know are correct are
>> is to use git's own transport mechanisms, i.e. fetch/pull the data, or
>> create bundles from it. 
>
> I don't think this is a fair recommendation since unfortunately, this cannot 
> be used to create a full backup. This can be used to back up the version 
> controlled data, but not the repositories meta-data, i.e. configs, reflogs, 
> alternate setups...

*nod*

FWIW at an ex-job I helped systems administrators who'd produced such a
broken backup-via-rsync create a hybrid version as an interim
solution. I.e. it would sync the objects via git transport, and do an
rsync on a whitelist (or blacklist), so pickup config, but exclude
objects.

"Hybrid" because it was in a state of needing to deal with manual
tweaking of config.

But usually someone who's needing to thoroughly solve this backup
problem will inevitably end up with wanting to drive everything that's
not in the object or refstore from some external system, i.e. have
config be generated from puppet, a database etc., ditto for alternates
etc.

But even if you can't get to that point (or don't want to) I'd say aim
for the hybrid system.

This isn't some purely theoretical concern b.t.w., the system using
rsync like this was producing repos that wouldn't fsck all the time, and
it wasn't such a busy site.

I suspect (but haven't tried) that for someone who can't easily change
their backup solution they'd get most of the benefits of git-native
transport by having their "rsync" sync refs, then objects, not the other
way around. Glob order dictates that most backup systems will do
objects, then refs (which will of course, at that point, refer to
nonexisting objects).

It's still not safe, you'll still be subject to races, but probably a
lot better in practice.