avatar
备份的软件方案# Hardware - 计算机硬件
h*3
1
材料:
香米适量 清水适量(水与米的比例为1:1) 鸡腿3只 胡萝卜半根 西兰花适量 口
蘑适量 盐四分之一勺 料酒两勺 黑胡椒粉适量 照烧汁4勺
做法:
1.去适量大米洗净按1:1比例放入清水,放入电饭煲蒸米饭。(忘记拍生米,拍了张米
饭)
2.蒸米饭的时候将鸡腿去骨,用刀背敲松,用牙签在鸡皮上扎一些孔。
3.加入盐、料酒和胡椒粉腌制鸡腿20分钟以上。
4.口蘑洗净切花刀(花刀可省略)。
5.西兰花用盐水浸泡后撕成小朵。
6.胡萝卜洗净切花刀后切片。
7.锅内烧开水,加入少许盐,放蔬菜焯水后过凉开水,控干水分备用。
8.平底锅加适量油,将腌制好的鸡腿表皮向下煎制。
9.待鸡皮呈金黄色时翻面。
10.鸡肉9分熟的时候加入照烧汁,将鸡肉裹上汤汁后中火收汁。(汤汁不要全部收干,
留一勺浇在米饭上)
11.用刀将鸡腿切条。
12.将米饭盛入碗中,摆好鸡腿和蔬菜。
avatar
S*A
2
想了半天,我觉得最靠谱的似乎是用 git 来备份。
文件是压缩的,在 server 上就是存一份压缩过的。
无非就是多用几个 git modules 不要全部放到一个
大的 git repo 里面。
git 也比较容易作 server 端的 mirror,也容易
处理多个 client 的文件冲突和合并。如果仅仅是添加
文件, merge 是及其简单的,不会有冲突。
唯一的缺点是不容易作 server 端真正删除旧内容。
电影这种大概随便 rsync 一下就好了,不是很真正
值得备份。
我觉得 raid 这种都不是真正的备份。
avatar
J*i
3
git搞大文件的效率一般吧

【在 S*A 的大作中提到】
: 想了半天,我觉得最靠谱的似乎是用 git 来备份。
: 文件是压缩的,在 server 上就是存一份压缩过的。
: 无非就是多用几个 git modules 不要全部放到一个
: 大的 git repo 里面。
: git 也比较容易作 server 端的 mirror,也容易
: 处理多个 client 的文件冲突和合并。如果仅仅是添加
: 文件, merge 是及其简单的,不会有冲突。
: 唯一的缺点是不容易作 server 端真正删除旧内容。
: 电影这种大概随便 rsync 一下就好了,不是很真正
: 值得备份。

avatar
S*A
4
的确,但是问题不大。backup 主要是多处复制。
大文件是少数,而且你比较小心放到单独的 git submodule
下面是不会影响其他 git 的目录的。关键是不要都装在一个
git 目录下面。
电影这种就不值得 backup 了。

【在 J*******i 的大作中提到】
: git搞大文件的效率一般吧
avatar
S*A
5
自己碰到问题了,现在用单纯的git 还不能 push 比较大的文件,
会有内存问题。要研究一下 alternative 的 方案例如 git lfs
之类的看看靠谱不。
avatar
j*2
6
这种场景应该用bittorrent sync
avatar
S*A
7
bittorrent sync 有些不错的特点。
我觉得对我来说比较缺乏 file version 和 conflict resolve.
这个 git 处理比较好。git 会记住那些版本是旧的,已经处理过 conflict 了。
这个对有多个源头的修改来说比较重要。

【在 j********2 的大作中提到】
: 这种场景应该用bittorrent sync
avatar
m*i
8
传不了大文件是协议的问题吧,用的是https?
试试用ssh

【在 S*A 的大作中提到】
: 自己碰到问题了,现在用单纯的git 还不能 push 比较大的文件,
: 会有内存问题。要研究一下 alternative 的 方案例如 git lfs
: 之类的看看靠谱不。

avatar
S*A
9
不是,我用的是 ssh。传不了大文件是转的时候似乎
作 delta 然后要分配一个文件大小的 malloc。
直接挂掉。
我现在看那个 git annex 还不错。就是把文件换成
一个 symlink 指向一个 SHR256 的实体文件。
annex 管理的文件用 git annex copy 来sync。
就是git repo mirror 那头自动 copy annex 管理
的大文件还没有解决。
最坏情况自己写个 cron。

【在 m*******i 的大作中提到】
: 传不了大文件是协议的问题吧,用的是https?
: 试试用ssh

avatar
t*d
10
rsync就挺好,我一直在用,没出过问题。

【在 S*A 的大作中提到】
: 想了半天,我觉得最靠谱的似乎是用 git 来备份。
: 文件是压缩的,在 server 上就是存一份压缩过的。
: 无非就是多用几个 git modules 不要全部放到一个
: 大的 git repo 里面。
: git 也比较容易作 server 端的 mirror,也容易
: 处理多个 client 的文件冲突和合并。如果仅仅是添加
: 文件, merge 是及其简单的,不会有冲突。
: 唯一的缺点是不容易作 server 端真正删除旧内容。
: 电影这种大概随便 rsync 一下就好了,不是很真正
: 值得备份。

avatar
S*A
11
rsync 我经常用,作为 backup 引起比较多问题是,
有太多 copy 的时候不好认识清楚那个机器
上的版本是最新的,如何 merge 等等。
git 有完整的历史管理还是更好。就是这个大
文件和大 repo 要处理好。

【在 t**d 的大作中提到】
: rsync就挺好,我一直在用,没出过问题。
avatar
t*d
12
如果你想要保存历史版本,可以写一个script自动完成这项工作。比如在运行rsync之
前先运行script查找上次备份后新改动过的文件,如果备份上有老版本,把老版本文件
改一下名字即可,工作量也不大,很容易实现。

【在 S*A 的大作中提到】
: rsync 我经常用,作为 backup 引起比较多问题是,
: 有太多 copy 的时候不好认识清楚那个机器
: 上的版本是最新的,如何 merge 等等。
: git 有完整的历史管理还是更好。就是这个大
: 文件和大 repo 要处理好。

avatar
S*A
13
script 没法自动完成这件事,如果有修改冲突的话。
rsync 备份的时间效率比较低,需要反复扫描大的文件时间和性能
会比较糟糕的。自己写脚本需要有 config file, repo 位置等等。
而且这个脚本要多个机器同步。
自己写脚本还不如用 git annex 托管文件,然后 git annex 有专门的
服务程序来 sync repo 的。
我现在只是想把这个 sync 和 push hook 挂钩起来。

【在 t**d 的大作中提到】
: 如果你想要保存历史版本,可以写一个script自动完成这项工作。比如在运行rsync之
: 前先运行script查找上次备份后新改动过的文件,如果备份上有老版本,把老版本文件
: 改一下名字即可,工作量也不大,很容易实现。

avatar
m*i
14
你这个需求还是直觉上btsync吧,自带版本控制。多机器只要不是同时修改,不太会出
冲突。我在用,但是是单向备份,还不错

【在 S*A 的大作中提到】
: script 没法自动完成这件事,如果有修改冲突的话。
: rsync 备份的时间效率比较低,需要反复扫描大的文件时间和性能
: 会比较糟糕的。自己写脚本需要有 config file, repo 位置等等。
: 而且这个脚本要多个机器同步。
: 自己写脚本还不如用 git annex 托管文件,然后 git annex 有专门的
: 服务程序来 sync repo 的。
: 我现在只是想把这个 sync 和 push hook 挂钩起来。

avatar
a9
15
我感觉备份就应该是单向的

【在 m*******i 的大作中提到】
: 你这个需求还是直觉上btsync吧,自带版本控制。多机器只要不是同时修改,不太会出
: 冲突。我在用,但是是单向备份,还不错

avatar
a*s
16
安装黑群晖吧,自带修改历史纪录的,秒杀所有其它方法。

【在 S*A 的大作中提到】
: script 没法自动完成这件事,如果有修改冲突的话。
: rsync 备份的时间效率比较低,需要反复扫描大的文件时间和性能
: 会比较糟糕的。自己写脚本需要有 config file, repo 位置等等。
: 而且这个脚本要多个机器同步。
: 自己写脚本还不如用 git annex 托管文件,然后 git annex 有专门的
: 服务程序来 sync repo 的。
: 我现在只是想把这个 sync 和 push hook 挂钩起来。

avatar
S*A
17
一个 repo 的备份通常是单向的,git mirror 如果 push 到
slave 上面会 redirect 到 server。
备份我觉得最好有 3 个不同的服务器或者硬盘。

【在 a9 的大作中提到】
: 我感觉备份就应该是单向的
avatar
S*A
18
修改历史记录是全部记录吗?
那如何把修改内容推送到其他计算机呢?
只有一个备份不安全。

【在 a******s 的大作中提到】
: 安装黑群晖吧,自带修改历史纪录的,秒杀所有其它方法。
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。