Emotional!

Guys I’m furious! My SD card just ended it’s life. No problem I thought - I have snapshot. WRONG! After snapshot restore, there was nothing, no sign of my previosu config. Ok, I thought, I have one more snapshot (I did it a week earlier - so it’s still ok) … and … WRONG! again. Config was partially ok, but a lot of things were messed up.
I really apreciate all the work you’ve all (developers) did, all the new components and lovelace interface, but what for, if the basic funcionality works crappy?! And after system crash, you end up with nothing. Sorry for emotional post but few weeks of my work is now wasted.

If you want to avoid my problems, do not relay only on snapshots, copy all the config yaml files and all imortant files manually. Gn. :frowning:

1 Like

Try to manually look for the config files within the snapshot. The tar file can be opened and browsed. All the config files were in there for my snapshot when I tested it.

I agree with @silvrr - many times I have restored just one yaml file from a snapshot. I can’t remember the exact folder structure within all the compressed files within a snapshot but drill down and hopefully you will find your config.

Good luk.

And Hassio claims another victim. :frowning_face:

I see the convenience of using add-ons but I don’t see the jumping thru the hoops necessary to try to fix issues with hassio when it doesn’t work exactly as expected because of its special os as worth that little bit of extra convenience.

I don’t really think I’m that limited by having to install things I need manually. And if you add a Docker install into the mix then everything becomes even WAY easier to maintain. If something breaks just delete the container and recreate it. Done in seconds!

And there is Linux help all over the internet in cases where things get a little wonky. HassOS has very limited support by virtue of design.

1 Like

I have never had a snapshot fail to restore and I’ve done it maybe 10 times.

1 Like

Yep, same here. Never a problem.

@silvrr, @klogg thanks for advice, will try to manually pull config files out from snapshot.
For now sensors history doesn’t work, Grafana nad InfluxDB database - lost, all of my automations - lost, … and strange situation - cannot add new mqtt switches, they are not visible as new entities.
I wonder if new PRi 3b+ with SSD via USB solve memory problems. Does anyone tried it already?

Got the same problem yesterday. My snapshot was of beginning of OCtober, so I lost a lot of changes in configuratiion, don’t know what happened. It would be nice to have an easier (for me) and safer way to backup configuration files.

Tried 3/4 solutions that are addons/workaround/DIY solutions, but with all I had problems configuring them.

It is a bit late for you now but my backup strategy is to:

  1. Run an HA automation every night to do a Snapshot
  2. Every morning when I turn on my PC it is scheduled to run a job which is a simple .cmd file. The .cmd file uses RoboCopy and does the following:
  3. Delete Sanpshots on my Pi older than 8 days
  4. Uses RoboCopy to copy new snapshots to my OneDrive folder on my PC
  5. Delete Snapshots older than 14 days from my OneDrive folder on my PC
  6. Uses RoboCopy to mirror my current config folder to my OneDrive folder on my PC

I also separately have a job that backs up certain data (which includes my HA data) to my NAS. This way I (should :slight_smile:) have four backups:

  • Pi Snapshot
  • Local OneDrive copy
  • Cloud OneDrive copy
  • NAS copy

I’m happy to share my RoboCopy .cmd file if anyone wants it but I can’t take responsibility for it’s use ;-). And obviously this is Windows.

And yes before any one points it out there is a flaw in this method in that when I go on holiday it will when I come home delete he number of backups equal to the number of days I am away. I just haven’t got round to dealing with that yet. Except that I always take a USB drive with my most important data with me when I go away - paranoid? moi?

Thank you for sharing your strategy klogg. I have FTP add on and auto backup to my NAS drive configured and it work fine for me. The problem is, I foolishly assumed that snapshots work flawlessly, now I know I was wrong.
I will add whole config folder to backup task.
Anyway, it would be nice to have sort of scheduler built in the snapshot functionality to automate it.

nice solution. Do you mind sharing the code (point 2)

Sorry to say this but they do work flawlessly, it’s something you introduced that has messed it up. Possibly the snapshot could’ve been written to a part of the card that was failing.

Loads of people use the Backup to DropBox add-on and write their own simple automation to trigger a snapshot and upload or just crib one of the many that have been shared by others and have 100% success with it.

1 Like

I had it backed up on my NAS, long before SD card problem started. As I mentioned before, I had 2 snapshots (made 7 and 14 days ago), one was without any config after restore, like a fresh install of Hass, the second one restored most of config, but still no sign of Indlux DB (and I get errors after installing new one - probably need to check config) and all of my automations.

Has anyone tried using High Endurance SD cards (for dashcams)?

It’s something I’m looking into at the moment as I went through a month of having my SD cards die back to back (3 in just over a month…) until I discovered I had a knock-off power supply.

I use Sandisk Ultra microSD cards. Last one lasted over a year. But that’s not the point imo. For me it’s not important if it works year or two. The problem it, that you never know when it fails.
So I’d prefer classic HDD or SSD instead of SD card, but i don’t know if Hass.io fully supports USB boot on RPi 3b+.

Yes, no brainer to use them for anything that you depend on, especially now they’re much cheaper than they used to be.

It’s rewrites that kill SD cards, like the HA database, and thats what the high endurance ones are for.

You may find that DB is one of the ones like some Node Red bits that need specifically backing up. Should be well documented if necessary though.

You missed the point about it being a corrupted snapshot that you then backed up, was just a suggestion anyway :slight_smile:

Is there any way to limit the databases’ abuse of the card?
High write card + limiting the database + good backup system in place would probably do wonders for the survivability.

Some people use USB sticks and the like to help this but the combo you said is the simplest and regular backup should be a given regardless as there are plenty of ways of tooling up the setup yourself as well as updates that alter files in ways you don’t want.

Limiting the number of days kept by Recorder makes a huge difference to the file size but would guess it isn’t writing any less.

1 Like

Just as an aside. My recorder is by inclusions only. If I am testing a new device, I will include it… other than that, I am not concerned with when the dining room light was turned on last month.

1 Like