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

The e37aba0a name or the name the snapshot has in Hassio?

The e7 etc name.

1 Like

I’ve set up a ‘manual’ script to take a snapshot and upload it as I only want ones from when I make changes…

backup_hassio:
  alias: Backup Home Assistant
  sequence:
  - service: hassio.snapshot_full
    data_template:
      name: Automated Backup {{ now().strftime('%Y-%m-%d') }}
  - delay:
      minutes: 30
  - service: hassio.addon_stdin
    data:
      addon: "7be23ff5_dropbox_sync"
      input: {"command":"upload"}

It seems to work perfectly but generates these two errors…

2018-06-13 12:27:44 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /snapshots/new/full request
2018-06-13 12:27:44 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall hassio.snapshot_full: name=Automated Backup 2018-06-13>
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/homeassistant/core.py", line 1007, in _event_to_service_call
    await service_handler.func(service_call)
  File "/usr/lib/python3.6/site-packages/homeassistant/components/hassio/__init__.py", line 211, in async_service_handler
    _LOGGER.error("Error on Hass.io API: %s", ret['message'])
TypeError: 'NoneType' object is not subscriptable

Hi there,

Just thought I’d share my setup for notifying me if the backup has not been successful. I use the ifttt Dropbox channel to check when a file has been uploaded to my Backup folder. When this happens it sends an http post to HA which then switches an input boolean on. Then, each morning, I have a script run to check that the boolean is on, and if not it notifies me that something has gone wrong. It also resets the boolean to off.

Hopefully useful to someone! See yaml below, let me know if you want me to share the ifttt setup.

######################
# Dropbox backup 
######################

### DEPENDENCIES ###

# ifttt
# Hassio Dropbox backup add-in

### CONFIGURATION ###

input_boolean:
  dropbox_sync_completed:
    initial: off

### GROUPS ###

### SCENES ###

### AUTOMATIONS ###

automation:

  - alias: Daily Dropbox backup
    trigger:
      platform: time
      at: '2:00:00'
    action:
      - service: hassio.snapshot_full
        data_template:
          name: Automated Backup {{ now().strftime('%Y-%m-%d') }}
          password: SECRET
      - delay: '02:00:00'
      - service: hassio.addon_stdin
        data_template:
          addon: "7be23ff5_dropbox_sync"
          input: {"command":"upload"}
      - delay: '02:00:00'
      - service: script.check_dropbox_successful
      - delay: '00:00:10'
      - service: input_boolean.turn_off
        entity_id: input_boolean.dropbox_sync_completed

### SCRIPTS ###

script:
  check_dropbox_successful:
    sequence:
      - condition: state
        entity_id: input_boolean.dropbox_sync_completed
        state: 'off'
      - service: notify.html5
        data:
          title: 'Home Assistant'
          message: 'Dropbox backup was not successful'
2 Likes

Hi,

After a new install of this great add-on, it seems uploading the backup .tar files to Dropbox does not work for me.
The add-on runs fine, it receives the command to upload, but treats all files as ‘already existing’ on Dropbox? Even if the Dropbox app folder is still completely empty.

I use add-on 1.2.0 on hass.io 0.71.0 (installed on a nuc with Ubuntu server 18.04, running in a docker).

I created a new app on Dropbox developers page for this and generated the token, following your instructions on Github.

My config for the add-on is:

{
  "oauth_access_token": "dedacted my access token...",
  "output": ""
}

The log file shows:

Log
starting version 3.2.4
[Info] Files will be uploaded to: /
[Info] Saving OAUTH_ACCESS_TOKEN to /etc/uploader.conf
[Info] Listening for messages via stdin service call...
{"command": "upload"}
[Info] Received message with command upload
[Info] Uploading all .tar files in /backup (skipping those already in Dropbox)
 > Skipping already existing file "/93d293ce.tar"
 > Skipping already existing file "/a98035c8.tar"
 > Skipping already existing file "/b1161847.tar"
 > Skipping already existing file "/b3254871.tar"
 > Skipping already existing file "/cdbf1233.tar"
 > Skipping already existing file "/f969d2cc.tar"
 > Skipping already existing file "/fa844957.tar"
 > Skipping already existing file "/fddc0a72.tar"

Any idea what is going on here?
I did open an issue on the Github repository for this.

Hey, thanks for filing an issue. I’ll continue the discussion there, although it may take me some time to resolve as I’m in the process of moving across the U.S.

1 Like

No problem, not in a hurry. :wink:
I updated the issue after some additional testing.

Mine is:

{
  "oauth_access_token": "secret",
  "output": "/home-assistant-backups/",
  "keep_last": 5
}

Do you perhaps need an output set in yours?

Hi David, thanks for your suggestion. I did update the issue I raised on Github with the following:

I tried that first, but when that did not work I reset the config to defaults and just added my access token to test if it was something in my config. The default (empty) should result in the files being placed in the root.
Did not help though. A reboot a hass.io did not help either.

I did some extra testing:

  • Does not make a difference if I create a new app with a new access token in Dropbox, either with ‘app folder access’ or ‘full Dropbox access’.
  • Does not make a difference when I use a folder name or keep the folder name empty (default).
  • Does not make a difference when that folder already exists or not, same outcome.
  • I uninstalled the add-on, rebooted the server and re-installed the add-on, still same.

Maybe this helps:

I notice when I do not use an output folder, I see the log shows like:

Skipping already existing file “/93d293ce.tar”

But when I do use a folder output name, the log shows like this:

Skipping already existing file “/hassioBackup_fullDB/”

Also, when accessing the docker container of the add-on ‘addon_7be23ff5_dropbox_sync’, I see a copy of my /backup folder from hass.io share (with all my backup .tar files). I do not know if that is supposed to be copied there?
Seems that that container for the add-on will get quite big.

THis addon was working great , until I upgraded to hassio.os 1.5 , now I cannot get it installed from the repository.

Here is the system log under the hassio menu
18-07-20 14:38:36 INFO (SyncWorker_10) [hassio.docker.interface] Pull image dwelch2101/dropbox-sync-aarch64 tag 1.2.0.
18-07-20 14:38:38 ERROR (SyncWorker_10) [hassio.docker.interface] Can’t install dwelch2101/dropbox-sync-aarch64:1.2.0 -> 500 Server Error: Internal Server Error (“readlink /var/lib/docker/overlay2: invalid argument”).

1 Like

Did you ever get this resolved. I’m moving over to a NUC from a pi and having the same problem. On the pi it worked flaswlessly, now on the NUC I’m getting the exact same problems you are. It skips all files even though the back up file in dropbox is empty.

1 Like

No, see updates on Github issue: https://github.com/danielwelch/hassio-dropbox-sync/issues/5

Daniel is busy moving and has limited time to resolve the issue. He seems to know now what causes this behaviour.
I believe it is caused by the bindings to the hass.io docker container being incorrect for our type of installation. Those are created during the installation of the add-on.

Thanks for the update. I was hoping you had found a work around in the mean time.

You can copy the dropbox_uploader.sh script which is being used by the add-on to your /config folder.
Then run it manually from a bash shell when remotely connect to hass.io instance through SSH.
That works for me, I will try to create something to have that automated as well. Probably using a command_line switch and an automation to trigger it.

Sorry everyone. Because of the move I’ve actually been without a home assistant instance myself :face_with_hand_over_mouth: although I do have a virtual box for testing. I haven’t updated to HassOS and haven’t been able to troubleshoot. I will be updating as soon as I’m back up and running (closing on a house in early August), so hopefully can troubleshoot then.

1 Like
  1. What kind of auth key is needed (“oauth_access_token”) because in DB account I have “App key”, “App secret” which are short keys (like 15 char), and a “OAuth 2” with a “Generated access token” and is a very long key (which disappears and must be regenerated in DB after e while). So which one to use?
  2. My folder is created not in root of DB but in Apps folder (where all other apps are storing too their folder). Is that normal, should be in root of DB?
  3. It doesn’t upload any of my backups (I have 4), I have no errors. Does it need any yaml configuration?
1 Like

Look forward to using it when it’s working again. Thanks for this!

Depends on your setup but it still works fine using hassio/hassos on a Pi.

1 Like

Sweet. That’s what I’m running.

Yes, the only problem that I’ve seen reliably reproduced is a weird issue with users running on NUC setups which I haven’t had time to troubleshoot. See the GitHub issues page. A few reports of problems since Hassio switched over to HassOS from resinOS, but seems like for most it’s still working. I haven’t changed anything in the add-on for quite awhile.

2 Likes