今天我有一个非常巧妙的备份数据库的想法：将转储文件放在 git 存储库中，然后在每个转储上提交，以便我拥有最新的副本，但可以轻松回滚到任何以前的备份。我还可以轻松地定期提取存储库的副本，以将副本保存在我自己的计算机上作为备份的备份。这绝对听起来很聪明。
但是，我知道聪明的解决方案有时会存在根本缺陷。在 git 中存储 mysqldump 差异可能会遇到哪些问题？这值得么？为了在服务器上拥有多个数据库备份并在其他地方保留冗余副本，大多数人会怎么做？
问问题
6025 次
4 回答
12
通常，您不会永远保留每个备份（或快照）。一个 git 存储库确实保留了您所做的每一次签入。如果您决定修剪旧的修订版（比如一个月前的修订版减少到每周一次，一年级到每月一次等），您将不得不这样做，git filter-branch这将重写整个历史。然后git gc删除不需要的修订。
鉴于 git 的优势在于分布式版本控制和复杂的补丁/分支工作流程（两者都不适用于快照或备份），我会考虑使用具有更可塑性历史的不同 VCS。
于 2010-11-23T22:18:40.820 回答
5
这种方法对我来说听起来不错。我使用 Git 来备份我自己的重要数据。
请注意，您没有存储差异——Git 有效地存储了每次提交时目录状态的快照。可以生成两次提交的 diff，但实际存储机制与 diff 无关。
于 2010-11-23T22:12:00.513 回答
3
理论上这会起作用，但是当数据库转储变大时，您将开始遇到问题。
Git 没有任何硬文件大小限制，但它会将您最新转储的内容与之前存储在存储库中的内容进行区分，这将需要至少与这两个文件加在一起的大小一样多的内存 - 所以我想它会开始变得非常缓慢，非常快，文件超过 100MB（甚至 10MB）。
Git 不是为处理这种类型的文件（即大数据文件而不是源代码）而设计的，所以我认为这基本上是一个坏主意。但是，您可以使用 Dropbox 之类的东西来存储转储 - 它仍会为您保存版本历史记录，但更适合无法有效区分的文件。
于 2010-11-23T22:22:51.647 回答
1
如果您使用 MySQL（可能还有其他）并启用了二进制日志记录，您可能会考虑为您的 bin 日志目录设置一个 git repo 并制定一个策略来定期提交对 binlog 的更新。
在 MySQL 中，binlog 将更改数据的查询存储到数据库上的任何表中。如果您将提交与数据库的常规转储同步，您应该有一个版本化的方法来恢复数据。
老实说，我认为仅使用 MySQL 的本机工具可能是一个更好的解决方案，但是我在这里概述的内容可以让您对 MySQL 数据进行版本控制，这正是我认为您首先需要的。
于 2010-11-24T15:48:50.340 回答