yes this is one thing what I also found out and you have to trigger it with an automation - the addon here does do it on its own when you set the time.
For me it doesn’t work running them in parallel. I’ve set the backup location for the native backup to the network storage, but the Samba Backup now gives an error:
[23-06-08 07:00:43] INFO: Backup running ...
[23-06-08 07:00:44] INFO: Creating backup "2023-06-08 07:00_Full_HAv2023.6.0"
[23-06-08 07:03:40] INFO: Copying backup f439c76c (Samba_Backup_2023_06_08_07_00_Full_HAv2023_6_0.tar) to share
[23-06-08 07:03:40] WARNING: f439c76c.tar does not exist
[23-06-08 07:03:40] WARNING: Could not copy backup f439c76c to share. Trying again ...
[23-06-08 07:03:45] WARNING: f439c76c.tar does not exist
[23-06-08 07:03:56] INFO: Backup finished
Agree that the native backup needs functionality (like keep X versions) from the Samba Backup addon to be a worthy replacement.
That’s a shame. I haven’t run them in parallel yet, but they will do for the first time tonight. I’ll report back if for some reason it does work.
If they can’t play nicely together, I think I’ll stick with the add-in untl the native solution has “keep x versions” functionality.
Just to be clear, it would seem the big benefit to the new “native” mount process is that the backup is actually created on the remote storage (NAS or whatever) device, not created on the local HA storage and then copied to the remote.
For some this will be a minor point, and this add-on is still far superior, at least for now.
For others, myself included, this is huge. I’m still running HA from an SD card, and I have been careful to keep the writes to a minimum. I’ve been unable to do scheduled HA backups. I copy files to my NAS on a regular basis, but only do the HA backup when I’m about to change something major, like an update.
This new HA functionality should allow me to schedule regular HA backups directly to my NAS, with no worries about impacting the SD card lifespan. (I hope. I haven’t actually tried it yet. I assume it really does what it says, and not simply duplicates the create-here-then-copy-to-there functionality of this add-on.)
I have just commented on an issue (Failed error after backup, but still seemingly successful · Issue #152 · thomasmauerer/hassio-addons · GitHub) that describes the problem described above. After investigation on my system that has a backup folder mounted on my NAS, I see that the internal backup and the add-on both create a backup file on the NAS. My guess is that the add-on doesn’t see that backup and can’t copy it to the target folder. The .tar does not exist seems to support this hypothesis.
Just to be clear, it would seem the big benefit to the new “native” mount process is that the backup is actually created on the remote storage (NAS or whatever) device, not created on the local HA storage and then copied to the remote.
This does not seem to be the case in my testing. 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.
I am in the same boat where I don’t want to be constantly writing to the HA system drive to create then delete backup files. I have a storage NAS designed for both short and long term file storage that I would rather utilize and it seems neither of these options (native SMB storage or this add-on) will actually write the backup files directly to the share.
Secondary is I would much rather it try the shared drive first and only falling back to writing to the system drive for a backup if the share fails. As of right now it’ll write to the system drive first but can fail if something happens such as you run out of space, regardless of the status of the share.
1 Like
Thank you for sharing the results of that test!
This is very disappointing. I did watch to be sure it didn’t create the file in the “old” location first, then copy it to the remote storage, but I didn’t monitor the entire drive.
It’s too bad this process wasn’t well thought through. I think it’s been a perennial problem with software development for all the years I’ve been involved with the field. Developers always have the biggest, best, fastest, largest hardware, and that’s what they develop to. Users have older, slower, smaller and lower-performing hardware, and wonder why the shiny new software sucks.
Oh well. That’s life. I’ll continue to do my backups by reading from the HA storage, rather than writing to it. I was so hopeful that this would be a good solution.
Hi,
I do have the following error message on HA 6.3 on HassOS
-----------------------------------------------------------
Add-on: Samba Backup
Create backups and store them on a Samba share
-----------------------------------------------------------
Add-on version: 5.2.0
You are running the latest version of this add-on.
System: Home Assistant OS 10.3 (amd64 / generic-x86-64)
Home Assistant Core: 2023.6.3
Home Assistant Supervisor: 2023.06.2
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
cont-init: info: /etc/cont-init.d/00-banner.sh exited 0
cont-init: info: running /etc/cont-init.d/01-log-level.sh
cont-init: info: /etc/cont-init.d/01-log-level.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[23-06-24 19:12:12] INFO: ---------------------------------------------------
[23-06-24 19:12:12] INFO: Host/Share: 192.168.178.83/test
[23-06-24 19:12:12] INFO: Target directory: SambaHA
[23-06-24 19:12:12] INFO: Keep local/remote: 2/10
[23-06-24 19:12:12] INFO: Trigger time: 00:00
[23-06-24 19:12:12] INFO: Trigger days: Mon Wed Fri Sun
[23-06-24 19:12:12] INFO: ---------------------------------------------------
[23-06-24 19:12:21] INFO: Samba Backup started successfully
[23-06-25 00:00:22] INFO: Backup running ...
[23-06-25 00:00:23] INFO: Creating backup "Samba Backup 2023-06-25 00:00"
[23-06-25 00:22:35] INFO: Copying backup 2e069da6 (Samba_Backup_2023_06_25_00_00.tar) to share
[23-06-25 00:22:35] WARNING: 2e069da6.tar does not exist
[23-06-25 00:22:35] WARNING: Could not copy backup 2e069da6 to share. Trying again ...
[23-06-25 00:22:40] WARNING: 2e069da6.tar does not exist
[23-06-25 00:22:51] INFO: Backup finished
[23-06-26 00:00:56] INFO: Backup running ...
[23-06-26 00:00:56] INFO: Creating backup "Samba Backup 2023-06-26 00:00"
[23-06-26 00:24:00] INFO: Copying backup 7836ad89 (Samba_Backup_2023_06_26_00_00.tar) to share
[23-06-26 00:24:00] WARNING: 7836ad89.tar does not exist
[23-06-26 00:24:00] WARNING: Could not copy backup 7836ad89 to share. Trying again ...
[23-06-26 00:24:05] WARNING: 7836ad89.tar does not exist
[23-06-26 00:24:16] INFO: Backup finished
Any Idea about that?
Anybody an idea where I can ask?
Unfortunately - looking at the pure huge lack of response from @thomasmauerer - one needs to state this great addon as unmaintained. There are issues without any reaction for more than 2 months. I love this addon. But living with broken things for months doesn’t really feel good. Really starting to be worried about the actual maintainer. I hope Thomas is fine.
No issue at all here. Should be something on your side. What is your addon configuration?
Have a look at the issue description. It’s a file rename bug in the addon. Addon configuration is fine.
If it’s a bug in the addon why are you the only one impacted?
With latest HA release you can mount your share directly in HA and use it for backups
That’s up to a dev to answer. Everything is provided including logs.
I‘m not on latest HA (Core, Supervisor and HA OS are already capable of network mounts). And SAMBA backup still has advantages over the manual way, like e. g. version control with deleting old backups, defining which parts to include (okay it never had that, but to exclude) etc.
Unfortunateley my issue with this missing file persists on every backup. I have no idea what’s wrong. My config:
host: 192.168.178.83
share: test
target_dir: SambaHA
username: admin
password: "Password"
keep_local: "2"
keep_remote: "10"
trigger_time: "00:00"
trigger_days:
- Mon
- Wed
- Fri
- Sun
exclude_addons: []
exclude_folders: []
log_level: debug
Well… I hope someone can answer this as it appears the author may not be responding… Has anyone had any success with adding a second backup to a second remote system. I have not been able to convince it to even try the second system.
Exactly that’s the main pain point here. Not a single response for months.
I fear to say… everyone running in an issue sooner or later been left with a somehow not well-working backup solution should have a look at the new native network mount support and see if HA already can provide the same set of features out of the box like
- create backup locally
- copy backup to network share
- set file name of local/remote backups
- version control: keep X local and Y remote backups
It’s just damn annoying being left with a malfunctioning piece of software - an important one cause backups can save asses.
Last hope to finally get dev response and hopefully fix the issue in this basically really great addon is getting down to zero meanwhile unfortunately. My summary based on the last 3 months:
SAMBA BACKUP = UNMAINTAINED
1 Like
I have just started using this Add-On but I don’t think anything is broken.
I was having the exact problem detailed above, logs give warnings about not being able to rename the file, the file is created anyway (with a random name rather than the name specified in the config) says it failed in HA.
Try setting your backup location in
Settings → System → Backups → Burger/3dot menu → change default backup location
Set it to “Use data disk for backup”
Set your “Keep Internal backups” in the add-on config to 0 (if you want)
That fixed it for me
1 Like