4 ms·

I wouldn't trust any MS cloud product to not lose my data. A year or two ago I lost data backing up my OneDrive files to my local HDD. I was told my backup had

by prmph 3y ago

I wouldn't trust any MS cloud product to not lose my data. A year or two ago I lost data backing up my OneDrive files to my local HDD. I was told my backup had succeeded, and so I deleted the files on OneDrive. Later, when I tried to extract some large files from the backup, I saw that they had been replaced with some text files, containing a message that the download of those files failed. What the heck... Was I expected to extract the archive and go through all the files one-by-one (there are thousands of them) to check if every file was properly backed up?

bombcar 3y ago
This is exactly what I've encountered with all the cloud-based file storage apps now that they've gone to "dynamic download". You will get failed downloads quietly.
dosshell 3y ago
Does someone know if rclone also can fail silently when syncing onedrive? [0] From my experience it doesn't but onedrive provides, sometimes, filesizes that are wrong, so checking file integrity is a tiny bit more of a pain. [0] https://rclone.org/docs/ https://rclone.org/docs/
grepfru_it 3y ago
>I wouldn't trust any MS cloud product to not lose my data. I raised issues of data loss and management prioritized shipping to customers instead. I can't say I blame them, they can take those risks knowing customers will accept them because their big name is behind the product. That said, I heard the issues were resolved so proceed with caution Note: this was not onedrive
ansible 3y ago
> later, when I tried to extract some large files from the backup, I saw that they had been replaced with some text files, containing a message that the download of those files failed. That's a really asinine failure mechanism. At the very least, it should create "filename-FAILED_TO_RESTORE" or something like that. Something that I was instructed to do nearly 30 years ago when at Motorola was: never overwrite the original files. Standard procedure was to make a directory called "BACKUP" (or "RESTORE"?) and put the files in there instead. The requesting person was then responsible for moving the files back to their original location, so any screwups were on them, not us (IT).
- justsomehnguy 3y ago
  The dogfooding was a thing 30 years afo.
  - ThePowerOfFuet 3y ago
    Sun did it much more recently than that.
- bobbylarrybobby 3y ago
  I think the only correct way to handle failures is to have a single file called ONE_DRIVE_RESTORE_FAILURES.txt at the restore destination root, and in it list the path to every file that failed to download, one path per line. Much harder to miss than individual files with conspicuous names.
ryan87 3y ago
> What the heck... Was I expected to extract the archive and go through all the files one by one (there are thousands of them) to check if every file was properly backed up? There are a lot of silent pitfalls like that in my experience. For example, if you use folder level encryption with Synology Active Backup for MS365 it can silently mangle the file names due to path length restrictions. You'll end up with files that have "file name too long" as part of the file name. That's why I'm trying to reconcile every file in this data set. I don't trust anything without being able to personally verify it at this point.
- bob1029 3y ago
  > For example, if you use folder level encryption with Synology Active Backup for MS365 it can silently mangle the file names due to path length restrictions. Is this Microsoft's fault or Synology's fault? Much of this discussion sounds like an inability to distinguish between first and third party products.
  - ryan87 3y ago
    > Is this Microsoft's fault or Synology's fault? It's 100% on Synology. > Much of this discussion sounds like an inability to distinguish between first and third party products. Yeah. Did I explain it badly or something? I thought I made it clear that I'm having an issue with 3rd party backup solutions and that it's possible they're using some shared API from Microsoft, but most people seem to be focused on OneDrive specific issues.
  - hulitu 3y ago
    > Is this Microsoft's fault or Synology's fault? It it were Microsoft's fault the filenames would have bin filena~1, filena~2 etc. /s

by prmph 3y ago

bombcar 3y ago

This is exactly what I've encountered with all the cloud-based file storage apps now that they've gone to "dynamic download". You will get failed downloads quietly.

dosshell 3y ago

Does someone know if rclone also can fail silently when syncing onedrive? [0] From my experience it doesn't but onedrive provides, sometimes, filesizes that are wrong, so checking file integrity is a tiny bit more of a pain. [0] https://rclone.org/docs/ https://rclone.org/docs/

grepfru_it 3y ago

>I wouldn't trust any MS cloud product to not lose my data. I raised issues of data loss and management prioritized shipping to customers instead. I can't say I blame them, they can take those risks knowing customers will accept them because their big name is behind the product. That said, I heard the issues were resolved so proceed with caution Note: this was not onedrive

ansible 3y ago

> later, when I tried to extract some large files from the backup, I saw that they had been replaced with some text files, containing a message that the download of those files failed. That's a really asinine failure mechanism. At the very least, it should create "filename-FAILED_TO_RESTORE" or something like that. Something that I was instructed to do nearly 30 years ago when at Motorola was: never overwrite the original files. Standard procedure was to make a directory called "BACKUP" (or "RESTORE"?) and put the files in there instead. The requesting person was then responsible for moving the files back to their original location, so any screwups were on them, not us (IT).

justsomehnguy 3y ago
The dogfooding was a thing 30 years afo.
- ThePowerOfFuet 3y ago
  Sun did it much more recently than that.
bobbylarrybobby 3y ago
I think the only correct way to handle failures is to have a single file called ONE_DRIVE_RESTORE_FAILURES.txt at the restore destination root, and in it list the path to every file that failed to download, one path per line. Much harder to miss than individual files with conspicuous names.

ryan87 3y ago

> What the heck... Was I expected to extract the archive and go through all the files one by one (there are thousands of them) to check if every file was properly backed up? There are a lot of silent pitfalls like that in my experience. For example, if you use folder level encryption with Synology Active Backup for MS365 it can silently mangle the file names due to path length restrictions. You'll end up with files that have "file name too long" as part of the file name. That's why I'm trying to reconcile every file in this data set. I don't trust anything without being able to personally verify it at this point.

bob1029 3y ago
> For example, if you use folder level encryption with Synology Active Backup for MS365 it can silently mangle the file names due to path length restrictions. Is this Microsoft's fault or Synology's fault? Much of this discussion sounds like an inability to distinguish between first and third party products.
- ryan87 3y ago
  > Is this Microsoft's fault or Synology's fault? It's 100% on Synology. > Much of this discussion sounds like an inability to distinguish between first and third party products. Yeah. Did I explain it badly or something? I thought I made it clear that I'm having an issue with 3rd party backup solutions and that it's possible they're using some shared API from Microsoft, but most people seem to be focused on OneDrive specific issues.
- hulitu 3y ago
  > Is this Microsoft's fault or Synology's fault? It it were Microsoft's fault the filenames would have bin filena~1, filena~2 etc. /s