这是一个创建于 2313 天前的主题，其中的信息可能已经有所发展或是发生改变。
近千万个几百 K~几兆的小文件，目录存放是以 MD5 分割出来的四级目录，形如：/static/ac/bd/ef/blahblah.zip ，并且每天文件数量以几百个的增加，目前想要实时备份此服务器的数据：
- 看中了一台 4x12T 的服务器，想把生产环境和数据全部转移到这上面去，做 RAID10，我都不用考虑两台服务器同步备份的软件了，有硬盘坏了直接替换上去是不是就 OK 了，美滋滋
- rsync+inotify 对这种海量数据备份效果如何，新增一个文件，可不可以做到不扫描全部的“ static ”文件夹？立马将主服务器的该文件传输至备份服务器。有没有更好的专门针对这种海量数据备份软件？
先谢为敬
 | 1 a852695 2019-06-13 08:51:04 +08:00 rsync 本身就是增量的吧 |
 | 2 JingKeWu 2019-06-13 09:00:46 +08:00 内网环境 先用 nc+tar 全部打包传输过去 增量用 lsyncd |
 | 3 dianso 2019-06-13 09:06:33 +08:00 via Android nc 开端口同步啊 |
 | 4 zycpp 2019-06-13 09:10:06 +08:00 via iPhone 就算每天增加 1000 个，这 1 千万的量都要累积二十多年……好奇这是啥数据？ 天文？地理信息？ |
 | 6 liangkang1436 2019-06-13 09:16:25 +08:00 @mattx 老哥稳！开车吗？ |
 | 7 luozic 2019-06-13 09:16:57 +08:00 麽多 不上文件存？ |
 | 8 ldrljq 2019-06-13 09:23:05 +08:00 支持 Mirror 模式的磁盘阵列加光纤，复制是基于块模式的，还可以组建双活和高可用。 |
 | 9 silencefent 2019-06-13 09:24:21 +08:00 rsync 转移到 nas 盘里,比维持服务器磁盘要便宜得多 |
 | 10 mattx 2019-06-13 09:38:37 +08:00 @liangkang1436 种子 可以通过 种子爬虫来获得, 我只是猜测下, 不一定是真实情况. |
| 11 luozic 2019-06-13 09:40:19 +08:00 同步的候直接用日志份 or 增量份就行。 |
 | 12 DestinyHunter 2019-06-13 09:46:37 +08:00 我仿佛看到了你在开车 |
 | 13 kisshere OP |
 | 14 wweir 2019-06-13 09:58:54 +08:00 磁盘块拷贝？ |
 | 15 lvzhiqiang 2019-06-13 10:14:20 +08:00 目前我们生产环境的静态文件同步就是通过 rsync+inotify 方式同步备份的。 |
 | 16 pxw2002 2019-06-13 10:19:09 +08:00 via Android rsync+inotify 就是增量的呀 |
 | 17 Tink PRO rsync |
 | 18 oott123 2019-06-13 10:35:00 +08:00 via Android 值得提醒的是 raid 不是备份 |
 | 19 jamblues 2019-06-13 10:36:09 +08:00 via iPhone 相信我，inotify 文件多了，每次机器重启或者服务重启 I/O 会卡到你怀疑人生。 目前比较实用的方案就是用 K/V 方案存 leveldb 类似的产品（如 ssdb 或 pika ）做集群。 |
 | 20 HarrisonZ 2019-06-13 10:37:45 +08:00 不如直接 s3 或者 oss |
 | 21 EPr2hh6LADQWqRVH 2019-06-13 10:38:53 +08:00 via Android 无脑 ceph |
 | 22 vincel 2019-06-13 10:39:42 +08:00 TFS 集群 |
 | 23 AlohaV2 2019-06-13 10:42:33 +08:00 rsync |
 | 25 pyder 2019-06-13 11:31:07 +08:00 via iPhone 貌似是做 CV 的呀，应该全是图片，用来训练的。 |
 | 26 zelin44913 2019-06-13 12:11:46 +08:00 rsync+inotify 只适合少量文件(十万以内) |
| 27 zelin44913 2019-06-13 12:22:04 +08:00 既然有考虑采购服务器,不如采购一台群晖 nas, 然后配置 Cloud Sync 套件做实时同步增量备份至阿里云 OSS |
 | 28 okjb 2019-06-13 12:24:48 +08:00 via Android 今年 18 岁，申请上车 |
 | 29 mdjxyz 2019-06-13 12:30:32 +08:00 上 minio 吧 |
 | 30 loading 2019-06-13 12:31:41 +08:00 via Android minio |
 | 31 cy97cool 2019-06-13 13:42:58 +08:00 via Android seaweedfs |
| 32 jamblues 2019-06-13 13:46:28 +08:00 via iPhone @kisshere 文件多了都会在 I/O 上有瓶颈 无论是 rsync 还是 lsync 底层是绕不过的 |
 | 33 iwannarun2 2019-06-13 13:48:35 +08:00 疑车无据 |
 | 34 qile1 2019-06-13 13:52:59 +08:00 via Android 文件如果放那里只读取，为啥不按年月日存放，这样同步起来只同步每天的数据不是简单了？ |
 | 35 Livid MOD PRO |
| 37 jamblues 2019-06-13 14:19:19 +08:00 via iPhone @cdlixucd 解决方案就是多个小文件合成大文件 降维 减少 I/O 开销，推荐可以试试 pika 或者 ssdb，优势是支撑几 kw 问题不大 内置分布式 也不用自己维护同步 弱点是性能只有在 ssd 下才能体现 如果要求不高 普通硬盘也可以试试 |
 | 38 cdlixucd 2019-06-13 14:29:42 +08:00 @jamblues 我们现在就遇到这个问题 都是在云平台上面 之前放在 google 对象存储里，也是有很多小的文件，然后要传到 AWS 对象存储 直接用的 rsync 来做的，先做一部分 后面切换平台再做增量的 你说的这种其实也还好 ，合成大文件后到目的端还是得拆开，一样的效果 真正的提升还是要对比吧 |
 | 39 xiaogui 2019-06-13 14:45:48 +08:00 tar 分包 |
 | 40 ps1aniuge 2019-06-13 14:53:20 +08:00  1 8 楼=唯一正解。 本地 mirror，远程 mirror。 任何方案都打不过 8 楼方案。 |
 | 41 hugee 2019-06-13 16:38:28 +08:00 按天存储多好啊 |
 | 42 jaskle 2019-06-13 20:49:54 +08:00 via Android git，很好用 |
 | 43 glfpes 2019-06-13 22:06:13 +08:00 via Android lsyncd，更简单的 rsync+inotify |
 | 45 AlloVince 2019-06-13 23:19:27 +08:00 @zelin44913 Cloud Sync 在文件数百万级别就已经不好使了 |
| 46 mattx 2019-06-19 18:17:40 +08:00 @ldrljq 有没有对应的资料可以查看的? |
Select Language