So, I moved my nextcloud directory from a local SATA drive to a NFS mount from a nvme array on a 10G network

“I just need to change /docker/nextcloud to /mnt/nfs/nextcloud in the docker-compose.yml, what’s the issue, i do it live” - i tell myself

So i stop the container, copy /docker/nextcloud to /mnt/nfs/nextcloud, then edit the docker-compose.yml… and… because I’m doing it during a phone call without paying too much attention i change the main directory to /docker

I rebuild the container and I immediately hear a flood of telegram notifications from my uptime-kuma bot… oh oh…

Looks like the nextcloud docker image has an initialization script that if it doesn’t find the files in the directory, it will delete everything and install a fresh copy of nextcloud… so it deleted everything on my server

Luckily i had a very recent full borg backup and i’m restoring it (i kinda love-hate borg, i always forget the restore commands when in panic and the docs are a bit cryptic for me)

Lessons learned:

  1. always double check everything

  2. offsite backups are a must (if i accidentally wrote / as path, i would have lost also the borg backups!)

  3. offsite backups should not be permanently mounted, otherwise they would have been wiped as well

  4. learn how to use and schedule filesystem snapshots, so the recovery wouldn’t take ages like it’s taking right now (2+ hours and i’m not even half way…)

  • plague-sapiens@lemmy.world
    link
    fedilink
    English
    arrow-up
    31
    arrow-down
    1
    ·
    edit-2
    8 months ago

    Some years ago, being a linux noob, I have created a VM to setup aBitcoin Lightning node. The blockchain is huge and my idea was to passthrough a 2 TB (/dev/sdc). Had to restart my homeserver because of some hoste settings I’ve changed. Didn’t see that sdc changed to sda and sdb (8TB fully encrpyted drive with my smb shares on it(seperate VM) to sdc. So far no problem. Because I didnt’t knew that the device names changed, I started the initilization process which formats the passthrouged HDD. Oh boy, when I heared the 8TB HDD spin up and doing it’s thing, the 2 TB HDD was still in spin-down, I panicked and shut down the server. End of story, 8 TB data was unrecoverable (lost all of my photos since I was a kid (~100k), lots of redownloadable stuff, gladly everything sensitive was backuped, like private seeds, work stuff, docuements, …) Never use /dev/sdX device paths, use UUIDs. They exist for a reason.

    • Bakkoda@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      41
      ·
      edit-2
      8 months ago

      Never use /dev/sdX device paths, use UUIDs. They exist for a reason.

      This is absolutely fantastic advice.

      • yiliu@informis.land
        link
        fedilink
        English
        arrow-up
        15
        ·
        8 months ago

        You can label your devices. When formatting, do mkfs.ext4 -l my-descriptive-name /dev/whatever. Now, refer to it exclusively by /dev/disk/by-label/my-descriptive-name. Much harder to mix up home and swap than sdc2 and sdc3 (or, for that matter, two UUIDs).

    • AnUnusualRelic@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      8 months ago

      We all went through some educational episodes like yours.

      Wisdom has to be earned the hard way. If we’re lucky, we’re just given a good scare.