• SapphironZA@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    109
    arrow-down
    1
    ·
    edit-2
    7 hours ago

    We used to say Raid is not a backup. Its a redundancy

    Snapshots are not a backup. Its a system restore point.

    Only something offsite, off system and only accessible with seperate authentication details, is a backup.

    • tetris11@feddit.uk
      link
      fedilink
      English
      arrow-up
      22
      ·
      5 hours ago

      3-2-1 Backup Rule: Three copies of data at two different types of storage media, with 1 copy offsite

      • mic_check_one_two@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        16
        ·
        edit-2
        6 hours ago

        AKA Schrödinger’s Backup. Until you have successfully restored from a backup, it is just an amorphous blob of data that may or may not be valid.

        I say this as someone who has had backups silently fail. For instance, just yesterday, I had a managed network switch generate an invalid config file for itself. I was making a change on the switch, and saved a backup of the existing settings before changing anything. That way I could easily reset the switch to default and push the old settings to it, if the changes I made broke things. And like an idiot, I didn’t think to validate the file (which is as simple as pushing the file back to the switch to see if it works) before I made any changes.

        Sure enough, the change I made broke something, so I performed a factory reset and went to upload that backup I had saved like 20 minutes prior… When I tried to restore settings after the factory reset, the switch couldn’t read the file that it had generated like 20 minutes earlier.

        So I was stuck manually restoring the switch’s settings, and what should have been a quick 2 minute “hold the reset button and push the settings file once it has rebooted” job turned into a 45 minute long game of “find the difference between these two photos” for every single page in the settings.

    • SreudianFlip@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 hours ago

      Fukan yes

      • D\L all assets locally
      • proper 3-2-1 of local machines
      • duty roster of other contributors with same backups
      • automate and have regular checks as part of production
      • also sandbox the stochastic parrot
    • OrteilGenou@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 hours ago

      I remember back when I first started seeing a DR plan with three tiers of restore, 1 hour, 12 hours or 72 hours. I knew that to 1 hour meant a simple redirect to a DB partition that was a real time copy of the active DB, and twelve hours meant that failed, so the twelve hours was a restore point exercise that would mean some data loss, but less than one hour, or something like that.

      I had never heard of 72 hours and so raised a question in the meeting. 72 hours meant having physical tapes shipped to the data center, and I believe meant up to 12 (though it could have been 24) hours of data lost. I was impressed by this, because the idea of having a job that ran either daily or twice daily that created tape backups was completely new to me.

      This was in the early aughts. Not sure if tapes are still used…