Hi folks, I’ve got a VM that is running my Firefly iii instance and Paperless instance as containers. A lot of work and time goes into managing these tools and I want to make sure I don’t lose them. This is my setup:

Turenas Scale machine 1 -> VM1 - Docker containers. The VM sits on its own dataset in Truenas.

I replicate the dataset to Truenas Scale 2 one a week and this machine only goes on on Sunday to save power.

I Rsync the dataset to a 3rd machine where there is a hard disk that I store offsite.

I recognize that I could lose up to one week of work but that is nothing compared to the human hrs spent building those databases from scratch.

Apart from snapshotting e rsyncing every day, what else could I do to make this more resilient without increasing CAPEX and OPEX costs?

  • ikidd@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    4 hours ago

    I’d say that should work. I do a similiar thing with my proxmox server, I have a second node that I bring up once a week and rep to, and the PBS backups on a different machine get repped internally as well as to a USB drive that is swapped every week and taken offsite.

    I’ve recovered the proxmox server and all VMs, as well as restored individual docker stacks on my docker VMs from this setup.

    • trilobiteOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      8 hours ago

      make me shake … brrr

      I’m going to try and see is I can get a VM running on the second Truenas server using the replicated dataset. I only use the second machine to duplicate datasets in case the first machine fails and have to rebuild it.

      • just_another_person@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 hours ago

        That’ll do it if all you’re checking for is valid working operation after a restore.

        Make some notes that you tested it and what you had to do to get it working in the backup job as well. Could save you A LOT of panic in the future.