
1 saturn 2012 年 8 月 30 日 试过 rsync 没? |
3 aoyoo 2012 年 8 月 30 日 我只知道,有大量磁盘IO时,系统的确会卡的动不了。。。 |
4 halfbloodrock 2012 年 8 月 30 日 你是每次都做全备的?这种情况增量备份不应该啊。 |
6 nonozone OP @halfbloodrock 确实要全备份...并且cp之后,还要tar... 这个问题好头痛啊... 如果增量备份的到也没关系,因为只要定期打包应该就没多大问题吧... |
8 eric_q 2012 年 8 月 30 日 rsync, 或者 lftp mirror |
9 kgen 2012 年 8 月 30 日 用crontab放到凌晨执行,你观察一下哪个时间段服务器的访问量最低。 |
10 feiandxs 2012 年 8 月 30 日 普通磁盘遇到cp自然这样。 rsync是王道 rsync一是实现增量备份,减少传输文件的磁盘IO 然后找个不那么卡的时段自动tar就可以。效果和全备又没差。。 |
11 dhysum 2012 年 8 月 30 日 为什么没人想到用GIT呢? 在源那里做一个repository, 定期的commit; 在目的位置定期的pull, 简单好用。GIT用的资源不多。 |
12 0racleTink 2012 年 8 月 30 日 ls这个好啊。。 |
13 kernel1983 2012 年 8 月 30 日 AWS S3 s3cmd sync . s3://your_bucket/path/ |
14 dianso 2012 年 8 月 30 日 如果有2台服务器了,NC开TCP端口同步吧 |
15 404 2012 年 8 月 31 日 @kernel1983 qrsync,比 aws/s3 好用多了,谁用谁知道!https://github.com/qiniu/devtools/tree/master/qrsync |
18 HowardMei 2012 年 8 月 31 日 @dhysum 根据经验,GIT文件夹体积膨胀很快,打包速度很慢,并不适用于备份。 增量备份,基于git packfile的 https://github.com/apenwarr/bup 更适合,python写的. 采用 rolling checksum algorithm (similar to rsync) 分割大文件. 直接写packfile,避免git的repacking过程,速度更快. 支持ssh远程拷贝,增量备份,par2冗余备份,fuse访问等. 就是命令行很丑,文档太少。。。 Bup里面也提到: Unfortunately, git itself doesn't actually behave very well for bup's use case (huge numbers of files, files with huge sizes, retaining file permissions/ownership are important), so we mostly don't use git's code except for a few helper programs. For example, bup has its own git packfile writer written in python. |
19 dhysum 2012 年 8 月 31 日 @HowardMei 这个体积不应该会很大。 我们有个项目有十年的历史, .git目录也不过200M+, 这里的commit一两天就会有, 频繁的每天都几个。 这个应该赶不上文件增加的速度。 关于大文件, 不太清楚网站服务器, 会有很多大文件吗? 只是觉得GIT可以用于备份, 而且简单方便, 学习成本应该也不高吧,如果LZ会的话? 刚看了下, rsync是个不错的选择。 @nonozone dropbox在这里可以只是个目录,如果目的位置是dropbox这个目录自然就可以了。 不过dropbox自身的文件差异检查是会重命名保存冲突文件,这个会很麻烦。可能dropbox本身已经有解决办法,但我不知道, 我对它不熟。 |
20 avenger 2012 年 8 月 31 日 rsync +1 一定要用 3.0 以后的版本,尤其好用… 增量备份,速度那是嗖嗖的… |
22 dworld 2012 年 8 月 31 日 自己添加任务吧,rsync不能设置定时运行的 |
23 hzlzh PRO |
25 fanweixiao 2012 年 9 月 5 日 rsync + cron |