this post was submitted on 12 Nov 2024
83 points (97.7% liked)

Selfhosted

40313 readers
331 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

Well, here my story, might it be useful to others too.

I have a home server with 6Tb RAID1 (os on dedicated nvme). I was playing with bios update and adding more RAM, and out of the blue after the last reboot my RAID was somehow shutdown unclean and needed a fix. I probably unplugged the power chord too soon while the system was shutting down containers.

Well, no biggie, I just run fsck and mount it, so there it goes: "mkfs.ext4 /dev/md0"

Then hit "y" quickly when it said "the partition contains an ext4 signature blah blah" I was in a hurry so...

Guess what? And read again that command carefully.

Too late, I hit Ctrl+c but already too late. I could recover some of the files but many where corrupted anyway.

Lucky for me, I had been able to recover 85% of everything from my backups (restic+backrest to the rescue!) Recreate the remaining 5% (mostly docker compose files located in the odd non backupped folders) and recovered the last 10% from the old 4Tb I replaced to increase space some time ago. Luckly, that was never changing old personal stuff that I would have regret losing, but didn't consider critical enough on backup.

The cold shivers I had before i checked my restic backup discovering that I didn't actually postponed backup of those additional folders...

Today I will add another layer of backup in the form of an external USB drive to store never-changing data like... My ISOs...

This is my backup strategy up to yesterday, I have backrest automating restic:

  • 1 local backup of the important stuff (personal data mostly)
  • 1 second copy of the important stuff on an USB drive connected to an openwrt router on the other side of home
  • 1 third copy of the important stuff on a remote VPS

And since this morning I have added:

  • a few git repos (pushed and backup in the important stuff) with all docker compose, keys and such (the 5%)
  • an additional USB local drive where I will be backup ALL files, even that 10% which never changes and its not "important" but I would miss if I lost it.

Tools like restic and Borg and so critical that you will regret not having had them sooner.

Setup your backups like yesterday. If you didn't already, do it now.

you are viewing a single comment's thread
view the rest of the comments
[–] Passerby6497@lemmy.world 4 points 1 week ago* (last edited 1 week ago)

Tools like restic and Borg and so critical that you will regret not having had them sooner.

100000%

I just experienced this when a little mini PC I bought <2y ago cooked its nvme and died this month. Guess who has been meaning to set up backups on that guy for months?

Unfortunately, that nvme is D. E. D. And even more unfortunately, that had a few critical systems for the local network (like my network controller/DHCP). Thankfully it was mostly docker containers so the services came up pretty easy, but I lost my DBs so configs and data need to be replicated :(

The first task on the new box was figuring out and automating borg so this doesn't happen again. I also set up backups via my new proxmox server, so my VMs won't have that problem too.

Now to do the whole 'actually testing the backups' thing.