My backups are 1850MB without the database included, my DB is currently 4240MB so I definitely wouldn’t want that included!.
As per what Stephen says, I do mine in the early hours of the morning, 0300 and no one is the wiser.
1 Like
I just pushed out a new release, v0.106.1, the first in over 6 months! As promised I’m focusing on bug fixes, and thankfully there haven’t really been many bugs. Stable code is the best kind of code. I’m also still doing some occasional quality of life stuff.
New Stuff
- You can now set a time after which any ignored backups are automatically deleted. Useful if you, for example, ignore backups created during add-on/HA upgrade but still forget to un-tick the checkbox to automatically create those backups.
Fixes
- Google recently changed how developers generate and use their authentication API, so I’ve had to update the addon to work with the new scheme for those authenticating using their own Google API credentials.
- When uploading backups from Drive → HA through the nabu-casa remote UI, progress would stall indefinitely because of a timeout.
To update the addon either wait for HA to notice by itself or go to “Configuration” > “Add-ons, Backups & Supervisor” > “Add-on Store” > “…” > “Check for updates”
Some have told me that Home Assistant sometimes doesn’t notice that a new version is available even when there definitely is. If anyone can provide any insight on why that happens to you, I’m all ears.
8 Likes
I’ve been using this add-on for a while now and am impressed by how streamlined and clean it is. It just works and I am much more confident in my setup now that I have good backups. I do have a question/feature request. I want to have a second instance of HA that I keep in sync with my primary instance. That way, if something goes wrong, or I need to take down my primary instance for some reason, I can just move my zwave stick over and restart with everything in place. Is there a way to do automatic restores? If not, could this be a feature that would be of interest in incorporating to the add-on?
I’ve been letting this idea stew in the back of my mind for a few days now. Looking at my thoughts below I realize now that I’ve written a lot of text. Sorry! Then again I’m also confident that overthinking features is what leads to happy users and fewer bug reports.
First let me restate a little more specifically what I think you’re thinking of, just to make sure we’re on the same page. I think you want some kind of “hot swap” backup HA installation, where when your primary installation fails a backup one is ready to take over with just a restart (and maybe plugging in some hardware). This would be accomplished by having the backup installation automatically download from Google Drive the backups created by the primary installation, then restore them automatically, presumably on the same schedule the backups are created.
This biggest problem I see with this concept is that a number of HA features/addons/integrations don’t play nice if two versions are running with identical configuration at the same time. This addon is one example, if two versions of the addon run with identical configuration (as would happen if they were automatically restored) then the two instances would overwrite eachother’s backups in Google Drive. The Nabu Casa Google Home/Alexa integration is another, it assumes only one instance should be handling requests from the cloud for a given account. If you don’t use any such features I think this could work, but it would be a fragile thing to remember to maintain as your smart home grows. When it does go wrong, it would be difficult to figure out why because the problems would only surface after the backup is created and restored on the backup, potentially days later.
Another problem is that in my experience restores rarely go smoothly. Every time I restore there is some finky addon that doesn’t download or some other bullshit that puts the installation in a bad state until I fix it, but maybe my install is just complicated.
That being said, I really like the idea of making the restore process easier and faster. I can think of two ways of getting maybe 90% of the way toward what you want, but that also isn’t likely to break things silently in the background.
-
Something you could do right now
For your backup instance, create a blank HA installation with default settings and nothing installed on it except this addon. Before connecting the addon to Google Drive change its settings to have:- “Backups in Google Drive”: 0
- “Days between snapshots”: 0
Then connect the addon to Google Drive. When the addon prompts you about preexisting snapshots in Google Drive, tell it to use the “existing” backup folder. With these setting, the addon will do nothing except stay connected to Google Drive (no automatic backups, no uploads). When the time comes to make the backup installation your primary installation you would open the addon web-ui, select the latest backup, select “Upload into Home Assistant”, wait for it to upload, when restore it.
- Pros:
- Quicker than starting from zero.
- Saves wear n’ tear on the backup machine since it isn’t really doing anything except waiting.
- Cons:
- You have to wait for the backup to download from Google Drive
- You have to wait for the restore to happen
- Requires an internet connection.
-
Something I would have to implement
Set up a blank HA install the same as (1) above except I add another setting named something like “Download the latest backup from Google Drive” (not the final name), which when enabled always downloads the latest backup from Google Drive as soon as its available. That way the backup would be available, but not yet restored.- Pros:
- Quicker than (1), no need to wait for a download.
- Only requires internet if your addons/integration need it as part of the resotre.
- Relatively safe and easy for me to implement.
- Cons:
- You have to wait for a restore (eg its not “instant” recovery).
- Pros:
Just to be clear, you could do (1) right now as it doesn’t require anything about the addon to change, (2) would be me making a new feature. With either solution you would still have to periodically manually update the supervisor version of the backup installation because every so often a new version of the supervisor changes the backup format and older versions of the supervisor can’t restore it.
Personally for my home, I don’t think its much trouble to spend the 30-60 minutes setting up a machine from zero and copying the backup manually when I need to restore. In fact I’d prefer to do that instead of having the burden of continually maintaining a backup instance. What do you guys think, would (2) be worthwhile to you?
5 Likes
Thank you for the great write-up. This entire quest was born out of a failed UPS that took place while i was traveling for work. Everything else in the house stayed up and running because it failed over to the other NAS, but the home automation did not. Until this happened while traveling, i had always thought of the HA system not being critical and me spending a couple of hours restoring it not a big deal as it rarely ever happens. During my automation journey, I had no idea how much the wife would become reliant on it. So when everything came crashing down and i was away, needless to say the wife was unhappy which prompted my search for this. It is easy for me to ask her to yank a USB stick from one machine and plug it into another while i am gone, then i can remotely restart the VM for HA and off we go. The funny thing is that i knew the system had gone down even before she noticed because of alerts, so i could have preemptively asked her to yank the USB and put it in the other machine and she would not have been the wiser.
Anyway, i like your first idea since it does not involve you having to change anything on this add-on that has been rock solid for me. I will implement that and test it to see if i can get it working. My hope being that if this ever happens again while i am out of town, i can catch it early enough where i can do the download/restore and then ask the wife to swap the USB dongle.
it will be better if we can add a keyword as @forums2012 said… cause i can call a service to make a backup with that keyword so when the integration will automatically sync, it will auto-retain too!
There may be issues with the new feature related to ignored backups:
“22-04-27 18:02:25 WARNING (MainThread) [supervisor.addons.options] Option ‘delete_ignored_after_days’ does not exist in the schema for Home Assistant Google Drive Backup”
There are numerous entries just like this in my logs.
1 Like
I get these warnings constantly also. Not sure how to update the schema to get rid of that. Running mariadb instead of sqlite for my HA if that matters at all.
Current version: 0.106.2
I keep getting Google Drive Full.
it is empty. I have rebooted … Still fails
Any pointers ?
Looks like I forgot to update the schema with the new option, the warning is harmless unless you try to save config through yaml directly (eg not in the UI). I’ll fix it in the next release.
Google Drive can use quota in a lot of ways and doesn’t always make it easy to figure out why. I’d check the following things:
- Make sure the trash is empty. Things in the trash still take up quota until the trash is emptied.
- Look at https://drive.google.com/drive/quota This should show all the files you have in Drive ordered by those taking up the most space.
- Your Google Drive storage quota is shared between many Google products (photos, gmail, etc) check out https://one.google.com/storage/management to see if any of those can be cleaned up.
If none of that still works for you, make a new google account. They’re free!
Thanks Stephen!
I am using my own Google authentication, and it has been working perfectly. In fact, I had to restore from a backup recently, so I really appreciate how seamlessly this add-on works.
However, Google sent out a warning about OAuth out-of-band calls. Any ideas? Thanks!
Hello Google OAuth Developer,
We are writing to inform you that OAuth out-of-band (OOB) flow will be deprecated on October 3, 2022, to protect users from phishing and app impersonation attacks.
What do I need to know?
Starting October 3, 2022, we will block OOB requests to Google’s OAuth 2.0 authorization endpoint for existing clients. Apps using OOB in testing mode will not be affected. However, we strongly recommend you to migrate them to safer methods as these apps will be immediately blocked when switching to in production status.
Note: New OOB usage has already been disallowed since February 28, 2022.
Below are key dates for compliance
September 5, 2022: A user-facing warning message may be displayed to non-compliant OAuth requests
October 3, 2022: The OOB flow is blocked for all clients and users will see the error page.
Please check out our recent blog post about Making Google OAuth interactions safer for more information.
What do I need to do?
Migrate your app(s) to an appropriate alternative method by following these instructions:
Determine your app(s) client type from your Google Cloud project by following the client links below.
Migrate your app(s) to a more secure alternative method by following the instructions in the blog post above for your client type.
If necessary, you may request a one-time extension for migrating your app until January 31, 2023. Keep in mind that all OOB authorization requests will be blocked on February 1, 2023.
If I read their announcement correctly, then yes, you’ll need to take some action in order to keep the credentials working in the future. I’d expect that your credentials will stop working in early October unless they extend the cutoff again. When this happens the addon will stop syncing, attempt to notify you that it is stuck, and wait for you to intervene. I’m not sure what exact error message will be displayed because I don’t know how google is going to implement its rejection of the credentials.
In march of this year (2022) I updated the instructions for generating your own credentials to work with the new requirements because Google already started blocking the generation of new OOB credentials at that time. OOB credentials are what the addon generated in version 0.105.X and prior. The addon now requests “custom/personal” credentials using a device id token that is in-line with their new standards. It was expected that something like this would happen eventually, using custom credentials has always been kind of a hack that uses Google’s authentication API’s in way they didn’t intend. Inconvenient, but that is the price of better privacy.
So if you:
- Use “custom/your own” credentials
- Generated those credentials prior to March 2022
- Wish to continue using the addon past October 2022
Then you will need to update to a recent version of the addon and then do one of the following:
- Follow the updated instructions to generate a new client id and client secret to re-authorize the addon. So long as you re-use your existing OAuth Consent screen configuration and Google Account, this should not cause any interruption in your backups. If you do change either of those then the addon won’t be able to see backups it uploaded to Google Drive in the past (ie not a deal breaker, just inconvenient).
- Alternatively, switch to using my domain (habackup.io) for authentication from the addon’s Google Drive authorization screen. This is easier and what most users do, but is arguably less private.
I will need to add a dialog to the next version of the addon informing users of this upcoming change in Google’s policies. that being said, I’m not 100% there is a way for me to determine wether or not a given set of credentials are affected by this.
Just to be clear, this change in Google’s policies only affects those who used these instructions to generate Google Drive credentials for the addon, you would probably remember if you did this because its a somewhat tedious process. Anyone who authenticated through habackup.io (the majority of people) are unaffected.
2 Likes
Oh also I just released a new version of the addon (0.107.1) yesterday, new features yay bug fixes quality-of-life yaddaa-yadda etc, etc. Here are the changes:
- Fixed a rare bug in generational backup that caused a “Multiple Deletes” warning to be shown
- Fixed a missing addon config schema entry that caused supervisor log spam (sorry).
- Added the currently used Google email address to the sidebar (just in case you forget)
In any case THE DEV DEMANDS SACRAFICE*
← Peferred
← Double plus plantinum status preferred
*The addon is free to use and there is no intention of changing that in for foreseeable future. It does cost me real money to run. Donations keep the lights on and the wife happy.
4 Likes
Thank you so much for the great linked reply. I had missed that announcement and also was running an older version and didn’t realize it. I will update everything. Thanks again for this awesome add-on. I donated in the past but will donate again for your great support!
Hey there. Great add-on! =)
Also got the mail from Google and is wondering one thing.
I go to “API Services and Credentials” → “Credentials” and there click on my OAuth 2.0 Client IDs that Im using for Google Drive Backup. Next I click on “Reset secret” or am I wrong?
I created a new set of credentials per step 4 of the updated instructions, then reauthorised using the new credentials in the add-on (be sure to click the link following “generate your own private credentials” in the first screen). This seems to have worked for me.
The old instructions created credentials with application type “Desktop app”, but the updated instructions create credentials with application type “TVs and Limited Input devices”. This would seem to imply that resetting the secret of the existing credentials won’t resolve the problem.
I haven’t tested this to make sure, but I think @crowbarz is correct that resetting the secret won’t work because the application type must be “Limited Input Device” to work with the latest version of the addon. Please also make sure that the Oauth Consent Screen is “Published” (from Step 3) because testing credentials automatically expire after 7 days.
It WORKED.
Followed from step 4 (since I already had the rest setup) and still have my old backups visible.
THANKS @crowbarz and @sabeechen