787
Windows users keep losing files to OneDrive, and many don't know why (www.techspot.com)
submitted 9 months ago by to c/technology@lemmy.world
239 comments fedilink hide all child comments
 

When Windows users suddenly discover that their files have vanished from their desktops after interacting with OneDrive, the issue often stems from how Microsoft's cloud service integrates with the operating system. The automatic, near-invisible shift to cloud-based storage has triggered strong reactions from users who find the feature unintuitive and, in some cases, destructive to their local files.

you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 9 months ago* (2 children)

...and don't forget re-testing your backups regularily. I had a really good backup strategy on my Loonix machine. Automatic (or it won't be done), tested, fool proof. When I somehow crashed a somewhat complex encrypted LVM array while swapping HDDs against SSDs, I had to recover from backup. Unfortunately I had become a better fool than I was when I set up backup4l. I had changed the compression algo, made a tiny mistate in the config and failed to realize that for six months I had been storing empty backups every day. Outch.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 9 months ago (1 child)

    Notifications will go a long way toward helping with that. Check all assumptions, check all exit codes, notify and stop if anything is amiss. I also have my backup script notify on success, with the time it took to back up and the size and delta size (versus the previous backup) of the resulting backup. 99% of errors get caught by the checks and I get a failure notification. But just in case something silently goes wrong, the size of the backup (too big or too small) is another obvious indicator that something went wrong.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 9 months ago

    I know. I just had become lazy enough to take the daily notification's subject line ("backup4l has run successfully") as evidence that everything was OK. If I had looked inside the bloody mail I'd have notices that the backup's size was 0B all the time because my self-rolled XZ-compression script failed to add data to the archives it "successfully" created. That's what I meant with "re-testing" - I should better have written "re-validate". My unforgiveable fault was not to look directly at the generated archives after changing the compression from bz2 to xz. Which was pretty pointless anyway as it turned out.

  • permalink
  • fedilink
  • source
  • parent