2023.6 Network Storage Feature - Experiences and Questions

Doh!
That did it! Thanks!

1 Like

Sadly, it looks like there’s a fatal flaw in this new feature. @charredchar reported a disappointing test result here:

I am not exactly sure where it writes the backup files while it is creating the backup but I saw the free space shrinking during a backup and no new files on the share until it completed. Once completed the space freed up on the HA install again and the tar file appeared on the share.

So, it looks like we’re back to square one: Don’t use the HA backup if you don’t want to write excessively to your local storage device (like, if it’s low on space or it’s an SD card with limited lifetime writes.)

I was hoping to be able to automate the backups to my NAS right from HA, rather than have to “pull” just the config directory contents as part of my regular backup process, then manually do full HA backups sparingly, like just before I make a major change.

I haven’t tested the “share” option to see if that works the same way (writes locally, first.) If so, it wouldn’t seem much better than writing locally and just keeping it there.

I’m mounting to Synology SMB share.
Basic functionality works. With that I mean, that I can mount the network share and use it for backup.

However I cannot seem to make it connect to any subfolder of the share, which is a bummer.
I’ve got a “Data” share and if I enter just Data into the “Remote Share” field things work.
If I attempt to add any subfolders such as Data/Backups/HomeAssistant then I get a mounting error.

Am I missing how I should define the folder structrure or does this just not work for the moment?

Anyone having issues using the media, from the Network storage, inside the cards?

I am able to use /local/Images/xxxxxx.png for the items inside “Media-> My media”
Now inside said My media I also see the NAS folder I added and the images inside it. But if I try using it inside a card as /local/Images/NAS_Folder/xxxxxx.png doesn’t work

I understand it makes little sense to still use /local/xxxxxxxxx but I can’t find the proper way to do it

Would love to know the same.

I have a file platform set-up in my configuration so that I can create a text file using notify.text_file. Then I use a Mac automation to copy this file onto my laptop.

Long shot, but is it now possible to specify a path to create/add to the file directly onto a shared network storage folder? I managed to create a shared folder on my Synology NAS using the new network storage feature.

I tried setting ‘filename: /shared_folder/text_file.txt’ and variations on this, just getting error messages. I am at the limit of my knowledge and suspect that the new feature isn’t designed to do this. I would appreciate anyone confirming this (or giving me something to try!)

Yes. Define it in configuration.yaml using “/share” in the filename: parameter, like this:

notify:
  - platform: file
    name: testlogfile
    filename: /share/HALogFiles/testlogfile.txt
    timestamp: True
1 Like

I like it, but agree, it could use the file name instead of the hash. Also having a max number of backups would be nice…

But has anyone actually tried to restore a backup from the NAS storage folder?
I did, and it failed… It starts the restore, increases cpu load, but nothing happens…
After a few hours decided to restart, and it was still at the current…

Could be something wrong on my end (hence I figured I ask :face_with_raised_eyebrow: )
I ended up restoring a backup from an older SambaBackup, and copied the rest of the data manually from the ‘latest’. backup :thinking:

As soon as i have

Thanks so much for this. Yes it worked!

I thought I had tried that - but obviously had got something wrong.

Much appreciated.

I am using a USB stick attached to my router and mounted as samba share as a network device now for backups. The backups are created fine, but when I head over to “Config->System->Backup”, it says that I have no backups. It was the same with a samba share on a server…
When I look at the storage directly, I do have normally sized backup .tar files.
Anyone else experiencing these issues? Standard backup location is set correctly to the named share…

I saw that no backups issue when I was messing around with this too. Then it started working. Not sure if it was a restart, or a browser refresh, or just waiting, which got it working again.

No backups persists over reboot/restart/reload here.

Anyone know where the mounts are mounted?? I tried to check inside the /mnt directory but its empty.

I would like to offload some of my backups which have been built up onto my NAS without manually downloading then uploading.

Would also be nice when you hit “Create backup” you actually choose where you put that backup, and when you do have backups remote/local it should still show this back up in the list with a tag like “local/remote”.

At the moment taking backup to a remote location is a little pointless since you cannot restore from the GUI very easily, without manually uploading.

Hopefully this will come in the future.
But so nice to finally have remote shares land :partying_face:

this is great.
I can add my synology nas as target for the backups, and works perfect!!!

I will be interesting it we can change some local media folder to a diferent default target.
With this improvement we can use a folder for our nas to records of frigate, for example

I found if I have too many files in the backup folder then the HA UI just doesn’t show anything when going to backups. Backups complete just fine either way.

I would like to see a retention policy solution.

How many backups do you have?

With the backup addon I would take a daily full and keep for 45 days. Had to delete all but a handful for them to show up correctly in the updated UI

Thanks! Good to know this limitation exists. I’m sure you’ve saved some one a lot of frustration.

I only keep a few backups for disaster recovery. All I really need is the last working version, although I might keep two or three.

I do keep archival backups of configuration files, automations, templates, etc. I just copy the old version to a directory on my NAS called “old config files” and rename it to include the modified date.

I can’t imagine a situation where I’d need any more than that. The most likely scenario is a failed version update, at which point I’d just restore the most recent working version. If I lose any hardware component, I’d re-install from scratch and, again, restore the most recent backup.

I am using HAOS on a Raspi 4.

Most have been said already, just want to add this:

Also wonder where the mounts are created.
During my initial trials to get an SMB connection to my Synology NAS, I got errors that seem to say the mount is created under /data/mounts. However there is nothing like that.

I also noticed that the backup seem to be created locally, then copied to the NAS, which was not what I expected, see related post from CaptTom above.

Beside a better a more transparent way of selecting, where the backup should go, I would like to see in some place where existing backups are actually stored. Would suggest to add a column to the list of Backups with that infornation (“local” or name of network storage).

Anyway, I think this can become a useful feature!
Thanks for all your work!

1 Like

Hi all,

since I have HA running for a few months now, I thought it would be a good time to setup backups. So the new feature in 2023.6 came right on time for me.
It works quit straight forward and does its job.

There is one thing I don’t like so much and that is that I noticed that HA logs into the share that I’ve created on my NAS every 10 minutes, preventing the NAS disks from going to sleep and keep them constantly running. As I basically only use my NAS only for file storage I have no need to keep the disks spinning all the time and want to save that energy, so this is a bit of a show stopper for me.

I am wondering if this can be prevented ?
Or which other setups do people have to backup to a NAS without having this issue ?
I welcome your suggestions :grinning:

Edit: added a snap of my QNAP NAS access log.