Mark a backup so it can't be overwritten during nightly backup

Well then you'd be screwed. What happens if your house gets carried away by a tornado?

This would at least open up the option to put a flag so that on reboot it would load a known backup. I'm not sure why this is such a controversial request. If you don't think it's beneficial then I guess you would never use it.

I for one see a use for it, for many reasons.

I sure did. I read the entire post. And my view has not changed. I didn't tell you not to pull a backup. I didn't disagree with it. I just really stated that it wasn't something I worry about. I did not comment for the argument. I commented because I also have lots of time and money invested which "inferred" that if it was that important to you, then back it up. You do the same with a computer. Hubitat has a limited number of staff focused on much larger issues. I'd be happy to help them by backing my own hub up. I'm sure someone already mentioned that there are scripts in the community to do this.

3 Likes

No

1 Like

No.

The Hub has a limited amount of memory/storage. We have 5 backups plus the 6th "Live DB" and with each eating 10's of megs of storage, it's a waste to 'Lock one" because the Next Request will be to increase the number, and so on. (I have 5 hubs, the largest backup is 23mb and the smallest is just under 1mb.)

There are a world of ideas, some great, some good, some just ok, and then there's the rest. The Idea of marking/locking an on-board backup is a "just ok" idea from MY viewpoint.

2 Likes

I understand your reasoning but you posted a link to the person that would likely not have used it or if they had used it would likely not have been useful. They would have still been disappointed.
You raise new issue that I could get behind

There are a few things I have or have used where a failed reboot would revert to a known good or previous running version. TiVo had two running partitions and if the update failed, it would restart with the previous version. ESXi servers do the same and my chromebook uses a similar approach. I'm not sure that would work for anything in the HE hub but it might worth a look.

From my other post

Okay.

Thank you. That's all I am really suggesting. His post gave me the idea.

Hubitat has that already.. during boot, if the 'live db' is detected as corrupt, it basically pulls in the most recent on-board backup. If that is corrupt, it goes to the next.. and so on. This is one reason the hub can once in a great while take a huge time to boot. It's also why you shouldn't pull the plug just because the hub's boot time is a minute longer than one expects.

( @zarthan I think you've been around long enough, 2 months less than me, to know all of the above, but others are new and I wanted to squeeze in a reminder. )

4 Likes

Oh I do miss the good old days of ST and absolutely no backup whatsoever.

8 Likes

Oh that's cruel to remind us of the huge benefit Hubitat gives. :smiley:

7 Likes

I had no idea that was the case. Thank you. I will stop my backup routine and hope for the best from now on. :wink:

2 Likes

That is s different circumstance. If you see no value in this that's fine. I'm not going to sit here and debate this all day. It was a request. Take it or leave it. My feelings won't get hurt. God forbid you would make the system more user friendly.

Sounds like they are already hurt.. sorry about THAT. But the Idea is there. It's going to get debated. I expect (as I do for any of MY great ideas :slight_smile: ) that you may have thought there will be little debate. But it is ultimately up to Hubitat to decide to implement or not, and when. The Community debate may or may not influence them on any given idea. There's the Steve Jobs/Apple approach to assume 'idea by committee' is always to be discarded, through to (no longer viable companies) that implement every 'up voted' idea.

It is certainly an idea that is worth the debate, and I've cast my one weak vote. :smiley:

1 Like

I have better things to do. But thanks for the laugh.

EXACTLY! Debate all you want.

1 Like

I like the idea, and see little/no downside in implementing it. +1

2 Likes

@csteele
What is it about the backups that I download that make each one for my C4 hub larger than the last one? I haven't really added any devices for a while. The backups are: 2019-07-29: 3.7 MiB, 2019-12-04: 3.9 Mib, 2020-01-11: 4.2 Mib, and 2010-01-31: 4.3 Mib. Are the hubs backing up logs? If so, is it necessary to have the logs backed up? Is there some sort of garbage collection/compacting of databases that needs to be done before a log is backed up? When are the databases compacted? If one wants to download a database, could not that trigger compacting the database before it is incorporated into the backup?

I think it is just dust. Leave a house for a while and even though you aren't there to do anything, dust collects. Just dust. :wink:

1 Like

A request to enable the USB port on the hub for external USB Stick backup. The 5 most current backups stay inside the hub and the rest get backup to the USB sticks.

4 Likes

ooohhh.. much better. :slight_smile:

... and keep one on the hub that won't be overwritten.

OOOHHH.. much much better. :cowboy_hat_face:

1 Like