S*A
发帖数: 7142 | 1 想了半天，我觉得最靠谱的似乎是用 git 来备份。
文件是压缩的，在 server 上就是存一份压缩过的。
无非就是多用几个 git modules 不要全部放到一个
大的 git repo 里面。
git 也比较容易作 server 端的 mirror，也容易
处理多个 client 的文件冲突和合并。如果仅仅是添加
文件， merge 是及其简单的，不会有冲突。
唯一的缺点是不容易作 server 端真正删除旧内容。
电影这种大概随便 rsync 一下就好了，不是很真正
值得备份。
我觉得 raid 这种都不是真正的备份。 |
J*******i
发帖数: 2162 | 2 git搞大文件的效率一般吧
【在 S*A 的大作中提到】
: 想了半天，我觉得最靠谱的似乎是用 git 来备份。
: 文件是压缩的，在 server 上就是存一份压缩过的。
: 无非就是多用几个 git modules 不要全部放到一个
: 大的 git repo 里面。
: git 也比较容易作 server 端的 mirror，也容易
: 处理多个 client 的文件冲突和合并。如果仅仅是添加
: 文件， merge 是及其简单的，不会有冲突。
: 唯一的缺点是不容易作 server 端真正删除旧内容。
: 电影这种大概随便 rsync 一下就好了，不是很真正
: 值得备份。
|
S*A
发帖数: 7142 | 3 的确，但是问题不大。backup 主要是多处复制。
大文件是少数，而且你比较小心放到单独的 git submodule
下面是不会影响其他 git 的目录的。关键是不要都装在一个
git 目录下面。
电影这种就不值得 backup 了。
【在 J*******i 的大作中提到】
: git搞大文件的效率一般吧
|
S*A
发帖数: 7142 | 4 自己碰到问题了，现在用单纯的git 还不能 push 比较大的文件，
会有内存问题。要研究一下 alternative 的 方案例如 git lfs
之类的看看靠谱不。 |
j********2
发帖数: 4438 | |
S*A
发帖数: 7142 | 6 bittorrent sync 有些不错的特点。
我觉得对我来说比较缺乏 file version 和 conflict resolve.
这个 git 处理比较好。git 会记住那些版本是旧的，已经处理过 conflict 了。
这个对有多个源头的修改来说比较重要。
【在 j********2 的大作中提到】
: 这种场景应该用bittorrent sync
|
m*******i
发帖数: 362 | 7 传不了大文件是协议的问题吧，用的是https？
试试用ssh
【在 S*A 的大作中提到】
: 自己碰到问题了，现在用单纯的git 还不能 push 比较大的文件，
: 会有内存问题。要研究一下 alternative 的 方案例如 git lfs
: 之类的看看靠谱不。
|
S*A
发帖数: 7142 | 8 不是，我用的是 ssh。传不了大文件是转的时候似乎
作 delta 然后要分配一个文件大小的 malloc。
直接挂掉。
我现在看那个 git annex 还不错。就是把文件换成
一个 symlink 指向一个 SHR256 的实体文件。
annex 管理的文件用 git annex copy 来sync。
就是git repo mirror 那头自动 copy annex 管理
的大文件还没有解决。
最坏情况自己写个 cron。
【在 m*******i 的大作中提到】
: 传不了大文件是协议的问题吧，用的是https？
: 试试用ssh
|
t**d
发帖数: 6474 | 9 rsync就挺好，我一直在用，没出过问题。
【在 S*A 的大作中提到】
: 想了半天，我觉得最靠谱的似乎是用 git 来备份。
: 文件是压缩的，在 server 上就是存一份压缩过的。
: 无非就是多用几个 git modules 不要全部放到一个
: 大的 git repo 里面。
: git 也比较容易作 server 端的 mirror，也容易
: 处理多个 client 的文件冲突和合并。如果仅仅是添加
: 文件， merge 是及其简单的，不会有冲突。
: 唯一的缺点是不容易作 server 端真正删除旧内容。
: 电影这种大概随便 rsync 一下就好了，不是很真正
: 值得备份。
|
S*A
发帖数: 7142 | 10 rsync 我经常用，作为 backup 引起比较多问题是，
有太多 copy 的时候不好认识清楚那个机器
上的版本是最新的，如何 merge 等等。
git 有完整的历史管理还是更好。就是这个大
文件和大 repo 要处理好。
【在 t**d 的大作中提到】
: rsync就挺好，我一直在用，没出过问题。
|
|
|
t**d
发帖数: 6474 | 11 如果你想要保存历史版本，可以写一个script自动完成这项工作。比如在运行rsync之
前先运行script查找上次备份后新改动过的文件，如果备份上有老版本，把老版本文件
改一下名字即可，工作量也不大，很容易实现。
【在 S*A 的大作中提到】
: rsync 我经常用，作为 backup 引起比较多问题是，
: 有太多 copy 的时候不好认识清楚那个机器
: 上的版本是最新的，如何 merge 等等。
: git 有完整的历史管理还是更好。就是这个大
: 文件和大 repo 要处理好。
|
S*A
发帖数: 7142 | 12 script 没法自动完成这件事，如果有修改冲突的话。
rsync 备份的时间效率比较低，需要反复扫描大的文件时间和性能
会比较糟糕的。自己写脚本需要有 config file， repo 位置等等。
而且这个脚本要多个机器同步。
自己写脚本还不如用 git annex 托管文件，然后 git annex 有专门的
服务程序来 sync repo 的。
我现在只是想把这个 sync 和 push hook 挂钩起来。
【在 t**d 的大作中提到】
: 如果你想要保存历史版本，可以写一个script自动完成这项工作。比如在运行rsync之
: 前先运行script查找上次备份后新改动过的文件，如果备份上有老版本，把老版本文件
: 改一下名字即可，工作量也不大，很容易实现。
|
m*******i
发帖数: 362 | 13 你这个需求还是直觉上btsync吧，自带版本控制。多机器只要不是同时修改，不太会出
冲突。我在用，但是是单向备份，还不错
【在 S*A 的大作中提到】
: script 没法自动完成这件事，如果有修改冲突的话。
: rsync 备份的时间效率比较低，需要反复扫描大的文件时间和性能
: 会比较糟糕的。自己写脚本需要有 config file， repo 位置等等。
: 而且这个脚本要多个机器同步。
: 自己写脚本还不如用 git annex 托管文件，然后 git annex 有专门的
: 服务程序来 sync repo 的。
: 我现在只是想把这个 sync 和 push hook 挂钩起来。
|
a9
发帖数: 21638 | 14 我感觉备份就应该是单向的
【在 m*******i 的大作中提到】
: 你这个需求还是直觉上btsync吧，自带版本控制。多机器只要不是同时修改，不太会出
: 冲突。我在用，但是是单向备份，还不错
|
a******s
发帖数: 267 | 15 安装黑群晖吧，自带修改历史纪录的，秒杀所有其它方法。
【在 S*A 的大作中提到】
: script 没法自动完成这件事，如果有修改冲突的话。
: rsync 备份的时间效率比较低，需要反复扫描大的文件时间和性能
: 会比较糟糕的。自己写脚本需要有 config file， repo 位置等等。
: 而且这个脚本要多个机器同步。
: 自己写脚本还不如用 git annex 托管文件，然后 git annex 有专门的
: 服务程序来 sync repo 的。
: 我现在只是想把这个 sync 和 push hook 挂钩起来。
|
S*A
发帖数: 7142 | 16 一个 repo 的备份通常是单向的，git mirror 如果 push 到
slave 上面会 redirect 到 server。
备份我觉得最好有 3 个不同的服务器或者硬盘。
【在 a9 的大作中提到】
: 我感觉备份就应该是单向的
|
S*A
发帖数: 7142 | 17 修改历史记录是全部记录吗？
那如何把修改内容推送到其他计算机呢？
只有一个备份不安全。
【在 a******s 的大作中提到】
: 安装黑群晖吧，自带修改历史纪录的，秒杀所有其它方法。
|
