使用远程存储库恢复原始存储库

发布于 2025-01-08 18:54:34 字数 775 浏览 1 评论 0原文

除了标准备份之外,我正在尝试在 git 部署中构建一些冗余。从纸面上看,似乎可以很容易地恢复多个用户使用我创建的存储库克隆的存储库,并使用 git Remote 链接/同步到该存储库。

过去,我遇到过备份磁带的问题,要么备份错误,要么必须从异地检索磁带。我正在考虑一种远程可能性,即托管丢失存储库的本地分支的服务器遭受灾难性故障,我需要在短时间内备份​​并运行大型源库,并将中断降至最低。

这里的想法是维护一个异地服务器,该服务器只是在从生产设备接收更新时闲置。当生产盒内爆时,我会将服务器别名为备份服务器,并制作“丢失”远程分支的本地副本

到目前为止,这就是我对每个存储库的恢复路径的想法:

- grep for the dead servers alias
- Parse for the remote branch names
- checkout the remote branches to the recovery repository
- Remove the dead servers alias

EG使用tcsh:

foreach q (git Branch -a | grep kaboom-1 | cut -f 2 -d '/')

git checkout -bbranch kaboom-1/branch

end

git Remote rm kaboom

在测试中效果很好,但实验室测试并不总是直接转化为现实世界的可行性。过去是否有人执行过此类恢复,或者您是否发现此方法存在问题?

I'm trying to build some redundancy into our git deployment beyond the standard backup. On paper, it seemed like it would be easy to restore a repository that multiple users have cloned using a repository that I created and linked / synced to using git remote.

In the past I have encountered problems with backup tapes either getting a bad backup or having to retrieve the tapes from off site. I'm looking at the remote possibility that the server that hosted the local branches for the lost repo suffered a catastrophic failure and I need to get a large source base back up and running in short order with minimal disruption.

The idea here would be to maintain an offsite server that simply idled along receiving updates from the production box. When the production box imploded, I would then alias the server to a the backup server and make local copies of the "lost" remote branches

So far this is what I'm thinking for a restore path per repository:

- grep for the dead servers alias
- Parse for the remote branch names
- checkout the remote branches to the recovery repository
- Remove the dead servers alias

E.G. using tcsh:

foreach q (git branch -a | grep kaboom-1 | cut -f 2 -d '/')

git checkout -b branch kaboom-1/branch

end

git remote rm kaboom

In testing this worked wonderfully but testing in a lab does not always directly translate into real world viability. Has anyone performed this type of restore in the past or can you see a problem with this method?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

南七夏 2025-01-15 18:54:34

这听起来有点尴尬,因为 git 有一个很好的备份功能,带有克隆和 --mirror 参数。我会在主存储库上使用 git clone --mirror ,并在每次将某些内容推送到主存储库时不断更新我的镜像(完全相同)。如果某件事进展顺利,那么很容易从镜像克隆之一克隆一个新的存储库并继续。

所以就这样做:

git clone --mirror main_repo.git

只要你想要主存储库的克隆镜像即可。请记住 --mirror 意味着 --bare,因此它们没有像主存储库一样的任何工作目录。

当主存储库中发生某些情况并且您想要同步镜像时,请在每个镜像中执行以下操作:

git remote update

当此命令完成时,此裸镜像克隆将再次与主存储库相同。

This sounds a bit awkward because git has a nice backup feature with clone and the --mirror argument. I'd use git clone --mirror on the main repo and just keep updating my mirrors (which are completely identical) everytime something is pushed to the main repo. If something goes boom it's very easy to just clone a new repo from one of the mirror clones and carry on.

So just do:

git clone --mirror main_repo.git

as many times you want for cloned mirror of the main repo. Remember that --mirror implies --bare, so they dont have any working directories just like the main repo.

When something happens in the main repo and you want to sync your mirrors, in each mirror do:

git remote update

When this command finishes, this bare mirror clone is again identical to the main repo.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文