作者danny0838 (道可道非常道)
看板Soft_Job
标题[请益] 大型Git版本库的备份或替代方案
时间Tue Feb 1 23:17:53 2022
我有一些大型的Git版本库，存放特定专案要用到的文献资料。
目前档案大约2000余个，大多是pdf、doc(x)档案及一些文字档，
单档大小可达数百MB，版本库总大小约数十GB。
由於总版本库过大，无法同步到 GitHub、GitLab 备份。
使用Git管理的原因是这些档案修改内容时希望有版本回溯机制，
有时也会有资料夹层级的重整（移动至其他资料夹、更改档名等），
一样希望有资料夹层级的版本回溯机制。
此外希望版本记录是可自订的（类似 Google 云端硬碟的永久保存版本），
并且以开放格式储存（而不是只存在 NAS 内部）。
目前是 Git 用得比较顺手，但如果有更好的备份及版控方案会考虑。
不晓得各位先进有这麽大的Git版本库时，会用什麽方式做备份？
除了备份到外接硬碟可以直接在本机操作 push, pull 以外，
如果想备份到其他电脑，远端桌面连线无法做Git同步...
Syncthing 之类的档案同步方式也不适合用於Git...
有在想架设 NAS，
但不晓得 NAS 是否允许 Git 同步以及内部操作 repack 等维护？
（repack 大型 repo 怕因为记忆体或 CPU 限制而无法完成，
或过程中整个 NAS 挂掉）
或者有其他比Git更好的替代方案？
（目前没看到更适合讨论Git问题的版，如有更适合的版欢迎告知）
--
《终结内容农场》浏览器套件
Chrome:
http://bit.ly/CFTGC (桌机 & Kiwi Browser on Android)
Firefox:
http://bit.ly/CFTFx (桌机 & Firefox for Android)
真相：
http://bit.ly/CFTss1、
http://bit.ly/CFTss2
详细介绍：
http://bit.ly/CFTinfo
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.137.15.240 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1643728676.A.1B4.html
※ 编辑: danny0838 (220.137.15.240 台湾), 02/01/2022 23:21:44
1F：→ forever215: 自己架Git Server 在弄一套Mirror 就备份完了 02/01 23:21
想问有什麽具体的架设方案吗？
假如两台都是 Windows 电脑，有什麽简单的架设方案吗？
考虑过 NAS，担心的问题如上所述。
我知道还有一招是租 VPS 架 Git server，
不过 VPS 普遍是用於架网站，单位容量价格偏高，
如果是纯做资料备份似乎不太划算，因此打算作为最後线备案。
※ 编辑: danny0838 (220.137.15.240 台湾), 02/01/2022 23:29:07
2F：推 neo5277: 自己组电脑，装一个gitserver这样，然後多备份一个? 02/01 23:28
4F：→ MoonCode: ur-own-git-server/ 02/01 23:53
6F：→ MoonCode: h-files/managing-large-files/about-git-large-file-s 02/01 23:54
7F：→ MoonCode: torage 02/01 23:54
目前的问题应该是 Windows。
对於另一台 Linux 电脑，只要架起 SSH 就可以 git remote 了。
但是 Windows 的 OpenSSH 似乎不能这样做。
专门组一台 Linux 电脑理论上是做得到，
但只为了几十 GB 的版本库组一台电脑不太划算，
希望能可以的话能和其他资料备份用同一台 NAS 解决。
（NAS 还在评估可行性未入手。如果无解可能只好架一台 Linux server 当 NAS？）
※ 编辑: danny0838 (220.137.15.240 台湾), 02/02/2022 00:10:15
8F：推 joshua5201: 你的东西都是binary 不适合git吧 那个也很难看diff 02/02 00:13
9F：→ joshua5201: s3/gcs那种的容量便宜每个档案加个timestamp上去 02/02 00:13
doc 档案的话其实 TortoiseGit 就有支援 diff，其实不差。
pdf 目前还没找到 diff 方案，不过有版控总是聊胜於无。
你所谓加个 timestamp 是指手动档案命名像 myfile.20220202.docx 这样吗？
这样不是比 git 更传统原始？XD
10F：推 longlyeagle: binary用git版控很怪吧... 不如自己出个hash管理 02/02 00:35
11F：→ longlyeagle: 不然你乾脆用 amazon s3 直接用 versioning 功能最快 02/02 00:37
不太懂「自己出个hash管理」具体是指什麽？XD
目前主要仍是以本地作业为主，只是要找备份方案。
Amazon S3 似乎是纯云端服务？不晓得如何能满足目前的需求？
12F：推 musie: 1. Perforce 2. Mecurial 02/02 00:37
Mercurial 我以前用过，基本上没 Git 好用，看不出来哪里能解决问题？
Perforce 似乎是付费VCS，能否说说有什麽feature能帮我解决问题？
※ 编辑: danny0838 (220.137.15.240 台湾), 02/02/2022 00:51:15
13F：→ forewero: 直接上aws codecommit 他也是git 你的量应该是免费 02/02 00:49
AWS 应该没有免费支援数十GB的私人repo...
14F：推 roccqqck: pdf或图片这种东西本来就不适合用git 02/02 00:59
15F：→ roccqqck: 这种东西还不如用单纯用档名+日期 02/02 01:00
16F：推 roccqqck: 你单档能百mb一定是大量图片的doc或pdf 02/02 01:03
17F：推 yfr: 我有一招很闹，但我现在的确正在使用，Mac的时光机 02/02 01:05
18F：推 roccqqck: 除非你用latex或markdown或html 02/02 01:06
19F：→ roccqqck: 不然一堆图片的档案 你就算版控每次都超占容量 02/02 01:06
20F：推 yoche2000: 搞个VM呢 逻辑上的 stand alone server 02/02 01:26
本机使用时用 VM 效能会变差...
不过如果真的没有 Windows to Windows 的同步方案，
可能最後会选择用 VM 架一个 Linux git server 吧...
21F：→ pttworld: windows你用gitblit这套免费的，硬碟容量你装几T应该够 02/02 01:47
22F：→ pttworld: 基本上自己组一台桌上型最省钱，容量要多大有多大 02/02 01:49
23F：→ DiLegend: 听起来直接用nas档案管理就好吧？ 02/02 02:00
24F：→ DiLegend: 一堆pdf你git也看不出改什麽吧 02/02 02:00
25F：推 now99: 档案用git ? 02/02 02:04
26F：推 now99: 乾脆ftp nas 快照备份 02/02 02:05
27F：→ Apache: git lfs 02/02 03:06
28F：→ ken8203: AWS S3 啊，开启 versioning，同档名的可以有版本区别， 02/02 03:37
29F：→ ken8203: 所以你只要无脑盖过去就好了 02/02 03:37
30F：推 jimmy789lee: git lfs 正解 02/02 03:56
不晓得 LFS 如何解决 Git 跨机器同步的问题？
31F：→ MonyemLi: s3加版控功能 02/02 07:25
32F：→ MonyemLi: 就上面ken提的 02/02 07:26
33F：推 wahaha279: 本来就是code的部分用git，不适合 git 的部分用dvc(da 02/02 08:14
34F：→ wahaha279: ta version control)。 02/02 08:14
35F：推 gn00742754: git-annex 02/02 09:00
36F：推 Bencrie: 版控不是给你备份档案用的 02/02 11:12
37F：推 jake080449: 档案应该用云端比较好吧？git的专长不是处理档案吧... 02/02 13:05
Git 不是用在备份，是用在版本控制。
正文就有写了，
我需要
档案层级和
资料夹层级的版本回溯机制（diff 倒不是那麽重要），
目前是 Git 用得比较顺手，版本记录也是以开放格式储存。
如果有其他方案能满足这些需求，我同意 Git 并非不可放弃。
不过前面看到的方案，比如 AWS 等，似乎并没有资料夹层级的版本回溯。
（如果不需要资料夹层级的回溯，付费 Dropbox 或 Google Drive 应该也可以解决XD）
38F：推 Belieeve: 照上面大大说的找DVC好像满多心得的 （英文 02/02 14:05
39F：嘘 musie: mercurial LargefilesExtension 这麽旧了 不看一下.. 02/02 14:20
这个和 Git LFS 有什麽不同吗？
40F：推 will3509111: timemachine 02/02 15:28
41F：推 alpe: Dropbox history version 02/02 15:39
42F：→ abc0922001: github 不是有大档案 binary 的解决方案吗 02/02 17:20
GitHub 有限制单档 100MB 及版本库 5GB（根据目前文件），
我的版本库已经数十 GB 了，塞不进去。
※ 编辑: danny0838 (220.137.15.240 台湾), 02/02/2022 17:39:17
※ 编辑: danny0838 (220.137.15.240 台湾), 02/02/2022 17:47:58
43F：推 damody: 你的问题可能在硬体不是软体 升级硬碟用三星7000MB/s ssd 02/02 17:54
44F：→ damody: 组raid0 如果不在本机要再加上10gb网路线10gb路由器就可以 02/02 17:54
45F：→ damody: 了 02/02 17:54
46F：→ samchung: 免VM，本机建个目录bind进docker跑Gitea解决 02/02 20:18
47F：推 xluds24805: Dropbox 02/02 20:28
Dropbox 有资料夹层级的版本回溯功能吗？
（让某资料夹及以下内容回溯到之前某个时间点的状态）
48F：推 longlyeagle: 自己管hash的意思是你定期抓checksum看更新做备份 02/02 20:33
49F：→ longlyeagle: 这样Git只要存hash跟备份位置就好 02/02 20:36
50F：→ longlyeagle: 可以直接排进CICD里面 02/02 20:37
这个看起来和 Git LFS 好像差不多？
51F：推 timfan3939: 自己使用云端专案架Gitlab伺服器，要多大有多大 02/02 20:58
52F：推 tomap41017: 你是不是没看懂GIT LFS的意义？拜托别呛人 02/02 21:39
53F：→ tomap41017: LFS是帮你把二进位档案传到别的地方去，GIT只存指标 02/02 21:40
54F：→ tomap41017: 的概念。你依然是使用GIT版控 02/02 21:40
不太确定你的意思？
意思是把要版控的档案塞进 LFS，
让 Git 版本库变小丢到 GitHub（但不传 LFS 档案），
而 LFS 档案另外用一般档案同步的方式处理？
55F：→ htury: 看起来跟git无关，只是要符合需求的档案管理跟备份，买云端 02/02 21:41
56F：→ htury: 空间存进去不就好了，有板控跟备份 02/02 21:41
57F：→ htury: 在依据需求写个归档系统 02/02 21:48
平常被 Git 强大的版控和还原功能宠坏了，
目前找不到哪家云端硬碟能达到类似需求@@
※ 编辑: danny0838 (220.137.15.240 台湾), 02/02/2022 22:18:00
59F：→ MonyemLi: 人少gitea就够了，设定档改一下档案大小限制 02/02 22:08
60F：→ MonyemLi: 剩下就硬体跟作业系统的限制了 02/02 22:09
61F：推 guanting886: NAS + 自己手动在档名数字编一编 or 自己设计归档软 02/02 22:26
62F：→ guanting886: 体比较快 02/02 22:26
63F：→ guanting886: PDF应该很难让你做DIFF，因为档案不一定可以透过程 02/02 22:28
64F：→ guanting886: 式抽出字，会因为被受保护 或 字被转成纯向量就无法 02/02 22:28
65F：→ guanting886: 直接比对了 02/02 22:28
66F：→ guanting886: Dropbox 不错 只是版本付费到最顶 应该也只能看到半 02/02 22:30
67F：→ guanting886: 年前的 02/02 22:30
68F：→ guanting886: Git 的设计一开始就为 Linux Kernel 开发/维护而生 02/02 22:33
69F：→ guanting886: 的，而这个东东经历过了百万以上的 commit 你去上面 02/02 22:33
70F：→ guanting886: 拉下来大概 1G 多而已 02/02 22:33
71F：→ guanting886: 应该不适合用在原PO的需求上，因为人家是在维护软体 02/02 22:35
72F：→ guanting886: 工程的啊XD. 02/02 22:35
73F：推 timTan: 试试git Dropbox 混搭如何。最适合你的工作流程 02/02 22:38
74F：→ qmailtw: 你有试过 OpenSSH 的 server 设定吗? 02/03 00:01
75F：→ acgotaku: 几百G算满小了拉,gcp/aws起个容器 定时镜像就解决了 02/03 00:48
76F：→ acgotaku: 也没多少钱,绝对比你架nas还要安全 02/03 00:49
77F：推 IcecreamHsu: GoodSync? 02/03 01:24
78F：→ cha122977: 不会改内容的东西用普通的云端硬碟就好了吧 02/03 01:47
79F：推 wulouise: 生鱼片刀切牛好不好用？ 02/03 10:25
80F：推 xxxxae86: 一般都指定档案吧？有指定资料夹层级的？ 02/03 11:08
81F：推 joehwang: 往备份套件的方向找呢? 这类软体可以满足资料夹回复，使 02/03 11:18
82F：→ joehwang: 用增量备份占的空间也不大 e.g. Duplicati, Acronis 02/03 11:18
83F：→ kyrc: gitea + dropbox 02/03 12:40
84F：推 roccqqck: 问一下gitea有比gitlab好用吗 02/03 17:21
85F：推 Bencrie: 那是不同量级的东西 02/03 18:51
86F：推 gmoz: 感觉 one drive就够了 还刚好买office 365 02/03 19:10
87F：→ Vitaceae: 哪那麽麻烦 资料夹归档用 script 批次指定 symlink 就 02/04 19:50
88F：→ Vitaceae: 好，symlink 用 git 建立历史资讯 02/04 19:50
89F：推 pttuser2266: 继续用 GitHub, 档案先分类，每个分类开一个 sub mod 02/04 23:09
90F：→ pttuser2266: ule , 如果未来单一 sub module 超过上限，可以考虑a 02/04 23:09
91F：→ pttuser2266: rchive 一份进云端，然後移除久远的记录 02/04 23:09
92F：推 shter: 这种需求反而比较适合装 CVS 或 SVN 来用 02/05 00:14
93F：推 yoyo890121: 两台Windows可以用shared folder 建立bare repo 02/05 02:50
94F：→ yoyo890121: 设定好remote 路径 push上去即可 02/05 02:50
95F：→ MonyemLi: gitlib功能多很多，较耗资源。少人的gitea会较省资源。 02/05 09:30
96F：→ cathychg: 喔喔喔喔喔喔～找厂商。 02/05 20:11
97F：推 abola921: binary 不能diff 的，想跟 code 一样的管理思维 02/06 01:50
98F：→ abola921: 要看你打算付出多少成本才好给建议吧 02/06 01:52
99F：→ abola921: 每一个版本，等同是一份拷贝，加上备份，这用git跑越久 02/06 01:54
100F：→ abola921: 储存成本越是巨大。真的有需要搞成这样吗？ 02/06 01:57
101F：推 Bencrie: 也不是不能 diff，看档案性质 02/06 12:01
102F：推 ssd860505da: rsync incremental backup 02/08 09:52
103F：推 dogz: AWS S3 02/09 14:10
104F：推 Killercat: 你这种就别git了，AWS S3开versioning照三餐丢档案就好 02/11 04:55
105F：推 jtrtsay: 对啊 pdf是在git什麽？ 02/12 01:04
106F：推 cathychg: sa sd 要先出来啊…ER 图 PM要切需求啊 02/15 17:40
107F：→ cathychg: 切完需求 才能模组做版控啊… 这？ 02/15 17:41
108F：推 cathychg: github 是一个大的repository...那做程式码的库存的 。 02/21 21:16
109F：→ cathychg: 。。。。搞甚麽烂东西啊！ 02/21 21:16