V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
拼车信息请发到 /go/cosub 节点。

如果没有发送到 /go/cosub,那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动,会导致账号被禁用。
mangoDB
V2EX  ›  iCloud

不靠谱的 iCloud 云盘

  •  
  •   mangoDB · 2021-11-23 12:08:35 +08:00 · 4508 次点击
    这是一个创建于 1120 天前的主题,其中的信息可能已经有所发展或是发生改变。
    这已经是我第二次遇到 iCloud 云盘丢数据的问题了。

    幸运的是被我提前发现,并通过网页版进行数据恢复。

    一言难尽……

    20 条回复    2021-11-24 19:43:27 +08:00
    edinina
        1
    edinina  
       2021-11-23 12:09:30 +08:00
    是 mac 和 win 混用吗
    mangoDB
        2
    mangoDB  
    OP
       2021-11-23 12:10:51 +08:00
    @edinina 我只在 iPhone 上使用 iCloud 云盘,备份一些 PDF 文档。
    fx777
        3
    fx777  
       2021-11-23 12:11:12 +08:00
    它比较玄学。。
    edinina
        4
    edinina  
       2021-11-23 12:12:23 +08:00
    @mangoDB #2 那不知道了,全家桶一直没出过问题
    ogxgo
        5
    ogxgo  
       2021-11-23 13:16:30 +08:00
    我目前还没有发现过。
    clrss
        6
    clrss  
       2021-11-23 13:42:36 +08:00
    刚刚又测了一下: 两端同时离线修改同一个文本文件到不同内容. 恢复后只有一个版本, 另一个修改丢失.

    这种情况 Google Drive 、Dropbox 、OneDrive 等正经网盘都会保留两个版本并提醒 conflict. 唯独 iCloud Drive 自说自话选一个版本覆盖.
    aireason
        7
    aireason  
       2021-11-23 13:57:07 +08:00
    我也觉得不靠谱,主要用 DropBox 或坚果云
    Dachunlv
        8
    Dachunlv  
       2021-11-23 14:51:16 +08:00
    iCloud 玄学问题是会经常遇到,用了这么多年文件丢失还真没有遇到过;期待 iCloud 收编 Dropbox 。。。
    SenLief
        9
    SenLief  
       2021-11-23 15:39:57 +08:00
    icloud 只适合同步一下不重要的东西,说实话 apple 的软件逻辑也笔记迷。
    bclerdx
        10
    bclerdx  
       2021-11-23 15:52:17 +08:00
    @SenLief 所以 NAS 的重要性就体现出来了?
    caowei922
        11
    caowei922  
       2021-11-23 15:52:35 +08:00
    我 iCloud 曾经出问题,文件想删除都删不了,还占着空间,联系客服,耗时快一个月才搞定
    ixuefeng
        12
    ixuefeng  
       2021-11-23 15:56:48 +08:00
    只要是同步机制的,都没办法 100%靠谱,出问题概率还是挺高的。
    我个人比较推荐 PC 端加载 NAS 分区远程直接读写。
    zhaidoudou123
        13
    zhaidoudou123  
       2021-11-23 16:09:37 +08:00 via iPhone
    🤣换了新电脑,导数据的时候发现一些存在 iCloud 云端文稿的远古文件都成几 k 的空文件了,赶紧找一年前 tm 备份,发现早就是这样了
    H0H
        14
    H0H  
       2021-11-23 16:17:47 +08:00
    你这算小问题了,我以前下载了几十 G 的中小学教材,然后放到了 iCloud 中,结果 iCloud 只给我保留了各级文件夹名,把所有文件全删了。还好我那次不知道咋想的,居然用的不是 option+command+V (平时一直是剪贴模式)。

    现在发现各类同步性质的云盘,必须配合增量备份使用。我在性能比较高的 Mac 上,都是每分钟就增量备份 iCloud 一次。这样就算丢,我也能将绝大部分文件抢救回来。现在是明确区分数据的硬件层冗余、软件层同步、备份概念。

    回想以前 Windows XP 时代操作系统的稳定性,那时候下意识认为操作系统不可能有 bug (设计缺陷不算,这是另一码事),现在的操作系统完全是闹着玩的,感觉都是把测试团队干掉了,代码写完开发人员自测一下就发布了。
    crystone
        15
    crystone  
       2021-11-23 16:30:18 +08:00
    我之前丢过文件,所以打死我不会用 iCloud 保存重要资料的
    peterzhang0602
        16
    peterzhang0602  
       2021-11-23 16:32:43 +08:00
    云上贵州?
    mogging
        17
    mogging  
       2021-11-23 22:05:40 +08:00 via Android
    Google One 稳么?
    zhuangku556
        18
    zhuangku556  
       2021-11-23 22:51:54 +08:00 via iPhone
    @H0H winxp 时代稳定?重装系统和做 ghost 不是日常?
    H0H
        19
    H0H  
       2021-11-24 09:48:11 +08:00
    @zhuangku556 稳定是说别人代码写得好,各种功能说是什么就是什么,用户功能层面上很难遇到 bug 。从写代码层面上调各种 win32 API ,也没遇到 MSDN 说明文档与 API 接口对不上的情况。代码遇到问题了,肯定是自己的问题,找就是了,不会怀疑是系统 API 有 bug 。

    你那重装系统、ghost 和这个有什么关系?实际上对搞懂了 windows 开发的程序员来说,谁整天重装?谁会用 ghost ?我在公司都是几年才可能遇到重装一次。这么低的概率谁玩 ghost 这种备份老系统和数据,到时和最新软件、
    数据的同步都够麻烦。

    玩重装的我觉得是还没有理解 windows 的普通用户。当然,我说的是 xp SP2 这个稳定版了,如果是 xp 刚上市那种,那的确是病毒天天见,的确会中毒后搞不定只能重装。理解了 windows 开发的话,知道系统启动后会在那几个注册表 /文件夹依序查找启动程序、自启服务,知道右键菜单在注册表哪里注册,知道怎样反注册各种 COM dll ,知道看 exe 签名,那么中毒就很不容易了。然后只要不乱安装各种软件,病毒就很难感染到系统,根本涉及不到重装和 ghost 。

    多说一句,我直到今天都不会用 ghost ,只听别人用过。在 win10 时代我用的是 vhdx 这种虚拟磁盘方案,整个操作系统及软件都是一个单个的以.vhdx 为后缀名的文件,几十个 G 的大小。想备份了就备份这个。玩游戏就可以再搞个 vhdx 文件,从网上下载的各种游戏真带了病毒把操作系统高挂了我再复制一份 vhdx 文件就是了,SSD 磁盘下一秒钟就复制几百 M 到几个 G ,很短时间就恢复了。
    zhuangku556
        20
    zhuangku556  
       2021-11-24 19:43:27 +08:00 via iPhone
    @H0H 我和你相反,反倒是进入 win8 以后系统重装的次数大大减少了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5920 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 02:26 · PVG 10:26 · LAX 18:26 · JFK 21:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.