Hass.io Add-on: Upload hassio snapshots to Dropbox

Tomahawk · February 17, 2018, 9:58am

Great work!

Will your add on have the option to set a default password for the .tar- file?
A security feature since the snapshot contains the security.yaml file.

DavidFW1960 · February 17, 2018, 10:13am

It doesn’t create the tar file - only backs it up.

jchasey · February 17, 2018, 10:37am

Sorry what I meant was if Daniel’s add-on was exposed as a service, you could use an automation to trigger the hassio-snapshot, then trigger the dropbox copy. No need to set timers etc within the add-on, the frequency is all controlled within the automation.
Having had a quick play it would be good to have some sort of status/timestamp of when the last successful backup was completed.
Good work.

DavidFW1960 · February 18, 2018, 12:32am

Gotcha. The service hassio.addon_start would be great to use if the addon name was recognised.
Tried {“addon”:“dropbox-sync”}, and also tried {“addon”:“dropbox_sync”} and {“addon”:“dropboxsync”} but none are recognised.

danielwelch · February 18, 2018, 1:03am

This is a great idea, and I think is probably the direction I’ll take the add-on. I took a look at the tellstick module which has this sort of functionality, and I think I’ll take inspiration from that and the use of the hassio addon stdin service call to implement this early next week.
@DavidFW1960 this will take care of any concern with starting/stopping the add-on. The add-on can just start up, stay on, and listen for messages via a service call.

danielwelch · February 19, 2018, 6:08pm

Ive just redesigned the add-on along the lines of our discussion here and pushed version 1.0.0.

See the README for full details, but some highlights:

Uploads are triggered via service calls to hassio.addon_stdin, allowing for automations and scripting of Dropbox uploads. Thanks @jchasey for the suggestion.
Uploads all .tar files in the backup directory to a specified output path, skipping files that have already been uploaded (No longer uploads entire directory).
Start the add-on once and leave it on. It will listen for messages via service calls, as detailed in the README.
- Note: this means no upload is triggered when the add-on is started, only when a service call is made.

I’ve tested this locally and it’s working great. In the process of this redesign, I had to do a deep-dive into how hassio identifies add-ons for service calls such as stdin, start, stop, etc. I share some details about this in the bottom of the readme. Short version: hassio hashes the installed repository name and uses that as an identifier in the format {REPO_HASH}_{ADDON_SLUG}. @DavidFW1960 I guess this is why you were having trouble starting/stopping the add-on previously.

I think this is a great way to come up with a unique identifier, but I don’t think it’s great that I had to figure that out on my own, manually hash my github url, and now have to document that hashed result for anyone to actually make a service call involving this (or any) add-on whatsoever.

So I have a couple proposed changes for the docs on this issue:

The name have the following format {REPO}-{SLUG}, e.g. local-xy or 3283fh-myaddon

This is wrong. It should be _, not -. Here’s the corresponding source code.
Since understanding how this hash is generated and being able to produce it for your own repository is required if you’re going to distribute an add-on that uses service calls, it should probably be documented.
- EDIT: after more reading, you can actually get this repo identifier from a call to the /addons via the hassio API. I think that would be good to document here.

Additionally, I think it’d be great if, through the Home Assistant UI, some sort of mapping of add-on name to identifier could be displayed. Off the top of my head, it seems like it’d be nice to display it as additional service information/documentation below the service selection field in developer tools, as there’s nothing currently there. But I’m unfamiliar with how these are generated and don’t know if it’d be possible.

All this is to say: I haven’t tested it with the hashed slug yet (the repo_id is local when using a local repository), so please let me know if there are problems with service calls.

jchasey · February 19, 2018, 7:39pm

Just tried the update and a couple of issues.

First the add-on did not detect there was an update available, but simply by uninstalling the old version, going back to the top level of hassio and re-selecting the add-on for install successfully enabled 1.0.0 to be installed.

Secondly when trying to test with a service call I got the following error:

2018-02-19 19:29:18 ERROR (MainThread) [homeassistant.components.hassio] Error on Hass.io API: STDIN not supported by addon

I tried using Start instead of Stdin just to check and it threw this error:

2018-02-19 19:30:52 ERROR (MainThread) [homeassistant.core] Invalid service data for hassio.addon_start: extra keys not allowed @ data['input']. Got {'command': 'upload'}

danielwelch · February 19, 2018, 8:11pm

Looks like I didn’t update the config stub used in the repository to align with the actual config in the dropbox-sync repository. I’ve updated it and specifically added "stdin": true to the config, which should fix this. I didn’t version bump because I’m only changing the repository data, and to be honest I don’t know how hassio handles updating that information. Quickest solution would probably be removing and re-adding the repository.

That second error should be expected, since you’re sending invalid input to a service.

I don’t know how hassio determines updates are available, so not sure why. I know in the past for me, it’s taken some time for hassio to display an “update available” dialog in the UI.

DavidFW1960 · February 19, 2018, 11:07pm

I just went into the addin and an update was showing as being available. I updated and started the service no problem. Now I just need to work out how to trigger it…

DavidFW1960 · February 19, 2018, 11:13pm

Called the service and I get this error:

Error on Hass.io API: STDIN not supported by addon
10:09 components/hassio.py (ERROR)

DavidFW1960 · February 19, 2018, 11:28pm

I also just noticed the service keeps stopping

DavidFW1960 · February 19, 2018, 11:30pm

I’ve just uninstalled and deleted the repo. now restarting HA and I’ll try installing again to see if that helps.

DavidFW1960 · February 19, 2018, 11:46pm

ah. It’s also now not creating a backup folder underneath the folder you specify…

So if I look in my DropBox, I have:
Apps
Apps\Home-Assistant-Backups
Apps\Home-Assistant-Backups\backup - this is where my backups ended up with the original Add-on
Apps\Home-Assistant-Backups\home-assistant-backups - this is where my backups are now going with the new addin.

My Configuration looks like this:
{
“oauth_access_token”: “xxxxxxxx”,
“output”: “/home-assistant-backups/”
}

So I think the changed way is what makes sense now.

It also worked after removing the repo and adding it in again. Nice.

One further thing - an enhancement - would it be possible to configure how many backups it keeps in the source? So everything could be backed up but then it will delete the oldest backups so you are only keeping ‘x’ number of backups locally? That would be great.

danielwelch · February 20, 2018, 12:02pm

So sounds like things are working as expected?

I can look into this. It seems like it should be possible but the addon will likely be required to use the hassio API. I’m imagining an option keep-last, which if set, will trigger calls to the hassio api to get date of all snapshots, and delete all but the last 5. I’d probably implement this in a separate python script. That’s run after an upload and only if keep-last is set.

Alternatively, this functionality could be exposed as a separate command, with its own option for keeping the last N snapshots.

dearlk · February 20, 2018, 12:47pm

Will try as well

DavidFW1960 · February 20, 2018, 9:27pm

Yeah totally working. Thanks.

Actually with keeping snapshots, it would be even better if it was handled in the Hassio Snapshot function anyway. There is no way to even delete snapshots from the GUI - all you can currently do is delete them in Samba or scp, so if this could be run from your addin would be handy.

Thanks again.

NotoriousBDG · February 20, 2018, 10:58pm

I was experimenting with an addon that copies backups to a thumb drive and handles keeping the last x backups. It’s very simple bash code, but If it helps, check out what I did at Snapshot Service enhancement to USB-dongle - #3 by NotoriousBDG.

I prefer your Dropbox approach over what I was doing with thumb drive. Dropbox is much more flexible and it’s nice to know backups are stored in the cloud…

sparkydave · February 24, 2018, 7:32am

with 0.63.3 you can now delete snapshots from the GUI. Something I’m very happy to see implemented

martikainen · February 24, 2018, 4:39pm

Anyone made an automation to run this regulary? Maybe even executing a snapshot before?

Would this work?

homeassistant:

automation:
- alias: Daily snapshot at 3 AM
  trigger:
    platform: time
    at: '3:00:00'
  action:
  - service: hassio.snapshot_full
    data_template:
      name: Automated Backup {{ now().strftime('%Y-%m-%d') }}


- alias: Daily upload to dropbox at 5 AM
  trigger:
    platform: time
    at: '3:00:00'
  action:
  - service: hassio.addon_stdin
    data_template:
      name: {"addon":"7be23ff5_dropbox_sync","input":{"command":"upload"}}

btw, thanks for a great add-on! Been looking for a good way to backup my config since I moved to hass.io

stocker · February 24, 2018, 8:26pm

This is what I did but set Dropbox upload to 4am, as the snapshot can take some time to run.