Open TB-SE opened 1 year ago
I have a similar (the same?) issue:
cont-init: info: /etc/cont-init.d/00-banner.sh exited 0 cont-init: info: running /etc/cont-init.d/01-log-level.sh Log level is set to INFO 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-11 05:46:50] INFO: --------------------------------------------------- [23-06-11 05:46:50] INFO: Host/Share: 10.1.10.181/pibackup [23-06-11 05:46:50] INFO: Target directory: /ha-prod [23-06-11 05:46:50] INFO: Keep local/remote: 10/15 [23-06-11 05:46:50] INFO: Trigger time: 03:33 [23-06-11 05:46:50] INFO: Trigger days: Mon Tue Wed Thu Fri Sat Sun [23-06-11 05:46:50] INFO: --------------------------------------------------- [23-06-11 05:46:58] INFO: Samba Backup started successfully [23-06-11 05:47:08] INFO: Backup running ... [23-06-11 05:47:09] INFO: Creating backup "haprod 2023.6.1 Full 2023-06-11 05:47" [23-06-11 05:49:57] INFO: Copying backup 029e9d9f (Samba_Backup_haprod_2023_6_1_Full_2023_06_11_05_47.tar) to share [23-06-11 05:49:58] WARNING: 029e9d9f.tar does not exist [23-06-11 05:49:58] WARNING: Could not copy backup 029e9d9f to share. Trying again ... [23-06-11 05:50:03] WARNING: 029e9d9f.tar does not exist [23-06-11 05:50:14] INFO: Backup finished
This started after the last HA update. I used the new Storage option to create a NFS share for backuips. This works with the internal backup function, but it may be causing issues with Samba Backup. The add-on creates the
This started after the last HA update. I used the new Storage option to create a NFS share for backuips. This works with the internal backup function, but it may be causing issues with Samba Backup. The add-on creates the .tar file on the NAS. If the add-on is expecting to find the backup file on the SD-RAM and cannot locate it on the NAS, it cannot copy it. Actually, at that point, a rename would be good enough, since I am using the same NAS folder for both.
OMG, I feel so stupid for not realising this sooner. 🤦♂️ You are absolutely right @mdisabato. I did the exact same thing and as you mentioned, the issue arrives from the fact that the file is no longer found where the addon expects it to be.
I can attest, setting the default backup location back to the internal storage makes the issue go away completely. I'll keep using the internal drive for manual backups for now.
There is a post on the forum (https://community.home-assistant.io/t/samba-backup-create-and-store-backups-on-a-samba-share/199471/577) that mentions creating the backup on the NAS reduces the write-count on the SD-RAM. I would like to see the process amended to be:
The actual backup might take longer because of network loading (definitely a variable), but that will also depend on the SD-RAM access speed.
I see similar stuff in #146 for a long time, long before the native network storage support of HA. And I even don't use that new feature, only SAMBA backup.
This addon is unmaintained, isn't it?
Feels like it. I have just found I have the same issue
Since a couple of days after upgrade HA to 2023.10.1 my backup fails. Log shows [23-10-08 00:00:16] INFO: Backup running … [23-10-08 00:00:18] INFO: Creating backup “Samba Backup 2023-10-08 00:00” parse error: Invalid numeric literal at line 1, column 5 [23-10-08 03:00:30] INFO: Backup finished Notification report Backup failed
Same for me. I think the addon is unmaintained ? @thomasmauerer ?
The bug is in this main function
function copy-backup {
local store_name
local input
local count
if [ "$SLUG" = "null" ]; then
bashio::log.error "Error occurred! Backup could not be created! Please try again"
return 1
fi
store_name=$(generate-filename "$SNAP_NAME")
# append number to filename if already existing
input="$(eval "${SMB} -c 'cd \"${TARGET_DIR}\"; ls'")"
count=$(echo "$input" | grep "\<$store_name.*\.tar\>" | wc -l)
(( "$count" > 0 )) && store_name="${store_name}${count}.tar" || store_name="${store_name}.tar"
bashio::log.info "Copying backup ${SLUG} (${store_name}) to share"
cd /backup || return 1
if ! run-and-log "${SMB} -c 'cd \"${TARGET_DIR}\"; put ${SLUG}.tar ${store_name}'"; then
bashio::log.warning "Could not copy backup ${SLUG} to share. Trying again ..."
sleep 5
run-and-log "${SMB} -c 'cd \"${TARGET_DIR}\"; put ${SLUG}.tar ${store_name}'"
fi
}
After the latest HA update (2023.06.0 and also above) I get this weird failed error, but the backup is visible both in HA and my NAS. Any input on what is suddenly not working? I'm using the samba backup sensor for some other automations which now unfortunately no longer work. 😔
Add-on version: 5.2.0 System: Home Assistant OS 10.2 (aarch64 / yellow) Home Assistant Core: 2023.6.1 Home Assistant Supervisor: 2023.06.1