This request stems from this thread
You state quite clearly that backups are only kept for 5 days and we need to offload them if we want to keep any longer. I am fine with that.
Something that could add to the user experience, especially for new or inexperienced users, would be the ability to mark a backup as read-only. By that I mean one that wouldn't be overwritten during the nightly backup schedule. Another option would be to add a 30 day backup into the mix.
The problem with this is that if the Hub has a major failing the read only backup might get corrupted or be inaccessible for some reason. I don't think there is any substitute for taking a proper off-hub copy of a backup, and providing that feature might lull users into thinking they didn't need to take any.
There are several backup scripts in the communities.
Don't disagree.
I basically stated that. What would the harm be? This shouldn't be that difficult to implement. It would be nice to be able to easily go back to a known working state.
That's not the point.
My understanding is that you're only backing up part of what's there. .. I'm not 100% sure of that, but it seems that I've read that in other threads. I just go with it. Maybe I like living dangerously, but I rarely pull backups. But, I rarely make a lot of changes. My environment has been in operation for better than two years and I've only had to do a restore one time and had Bobby holding my hand to do it. I don't care if I have to redo everything one day. I say "bring it on". It'll be better organized and more thought out. It's a hobby for me. Anyone who knows me here, knows my setup and knows that I'm not just talking about a few lights.
[EDIT]
The only real problem I see is that I think I've forgotten how to find a light switch, a fan, the thermostat, and how to turn a key. I don't know what a doorbell sounds like anymore. It would be a confusing week in the Brandt residence.
Did you read the circumstances of why I submitted this feature request?
Having a backup that got marked as "don't delete" would be what people EXPECTED to always be that safety net. As @Geoff_T says what happens when that is corrupted or inaccessible. A rolling copy of 5 isn't much better than not having any if what you have is junk. It would NOT protect anyone. Getting more than one copy OFF the device is more reliable, but NOT infallible either, but you have more chances, the more versions you have.
As I have wrote in my previous.
I'd put something as up to user/admin if he want's to make nightly backup or not.
I cannot accept that thing is behaving on it's own without my/users/admins control.
Don't You all agree with me ?
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.
No
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.
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. )
Oh I do miss the good old days of ST and absolutely no backup whatsoever.
Oh that's cruel to remind us of the huge benefit Hubitat gives. 
I had no idea that was the case. Thank you. I will stop my backup routine and hope for the best from now on. 
Download the Hubitat app
