Attribute "last_backup" does not update / backup status FAILED even they are actually SUCCESSFUL

[bcutter]

Following the closed issue #107 which does not seem to get any attention (closed).

Latest relevant information including an interesting finding:

• Attribute "last_backup" does not update since 5.1.2 #107 (comment)
• Attribute "last_backup" does not update since 5.1.2 #107 (comment) <-- see "Suspicious finding 1" + "Suspicious finding 2" ⚠

[bcutter]

Ping @thomasmauerer

[bcutter]

Ping2 @thomasmauerer are you able to have a look at this please?

It runs daily and completely reliable, it's just the "Last backup" attribute (which is important as I'm using it for automation purposes, getting multiple reminders a day for 5 weeks now!):

I also updated my test list @ #107 (comment).

[bcutter]

Ping 3 @thomasmauerer

[23-06-05 02:35:05] INFO: Deleting a170f58b (Partial Backup 2022.12.9 2023-06-03 02:00) local
date: invalid date 'umbenannt).tar A 3454935040 Sat Apr  8 06:49:24 2023'
[23-06-05 02:35:06] INFO: Deleting Samba_Backup_Partial_Backup_2022_12_9_2023_04_27_02_00.tar on share

Seeing this on EVERY FREAKING backup run...

[bcutter]

Today I discovered this:

Seems like they fail for a very long time already - very likely the last "successful" run really was on April 9th.

BUT that's complete BS, as the backups are actually created fine! See here:

Might be related to #152.

Every time doing a deeper dive into SAMBA backup it looks more broken 😞

Can we PLEASE finally have a look into this issue? @thomasmauerer Not a single response in months looks like this great project is more or less unmaintained, isn't it? 😢

[bcutter]

Summary:

1. File rename issue ("invalid date")
2. Status FAILED
3. Last backup attribute does not update

As simple as that. Let's fix 1. and everything will be fine again automatically ✅

[bcutter]

@thomasmauerer 👍🏼

[Tamsy]

Following the closed issue #107 which does not seem to get any attention (closed).

Latest relevant information including an interesting finding:

• Attribute "last_backup" does not update since 5.1.2 #107 (comment)
• Attribute "last_backup" does not update since 5.1.2 #107 (comment) <-- see "Suspicious finding 1" + "Suspicious finding 2" ⚠

Are you sure this is not caused by something with your particular installation?

The only difference I see is that you are doing partial backups while I have configured Samba Backup to do full backups every night. Thus doing partial backups might be the culprit.

Using Samba share on a QNAP-NAS for backups:

"Last backup" attributes are showing correctly:

Nothing in the logs and HA's Logbook says:

Samba Backup logs show only:

[bcutter]

"I'm not affected" postings don't seem helpful in my opinion. All details on the core issue have been provided. It's up to a dev / the maintainer to make something out of this.

Partial/full backup shouldn't make any difference. Regarding the file rename bug (core of the issue) it's irrelevant (Partial|Full).

[bcutter]

Repeating the same information once again:

SAMBA Backup addon log:

Plain text:

[23-07-09 02:00:09] INFO: Backup running ...
[23-07-09 02:00:10] INFO: Creating backup "Partial Backup 2022.12.9 2023-07-09 02:00"
[23-07-09 02:36:56] INFO: Copying backup 9f09c58a (Samba_Backup_Partial_Backup_2022_12_9_2023_07_09_02_00.tar) to share
[23-07-09 02:38:03] INFO: Deleting dd832d82 (Partial Backup 2022.12.9 2023-07-08 02:00) local
date: invalid date 'umbenannt).tar A 3454935040 Sat Apr  8 06:49:24 2023'
[23-07-09 02:38:04] INFO: Deleting Samba_Backup_Partial_Backup_2022_12_9_2023_06_02_02_00.tar on share
[23-07-09 02:38:05] INFO: Deleting  on share
[23-07-09 02:38:05] WARNING: del <filename>
[23-07-09 02:38:16] INFO: Backup finished

Corresponding SAMBA Backup sensor status:

[bcutter]

I digged into this even more deeply.

1. Interesting: keep_remote: "45", while log (set to debug) tells ..."backups_remote":"46".... How is this possible?
2. So I checked the SAMBA share once again. And found this, backup number 46 (the oldest one which should have been deleted already):
   

I copied that one manually around 8th/9th of April. Remember SAMBA backup sensor: "last_backup":"2023-04-09 02:29".

No coincidence, as this event matches the last successful backup date pretty closely.
...so I think it's basically a bad idea to manually copy SAMBA backups to the SAMBA share and rename it there. That's what the WARNING log entry seems to have been about. Somehow SAMBA backup can not handle such extra SAMBA backups on the SAMBA share/remote backup storage.

Long story short:

• I deleted that "extra" backup from the remote storage and triggered a SAMBA backup with minimal content (only media folder). It ran just fine (including SUCCEEDED state and an update of the last_backup attribute - FINALLY):
  
• It seems to be fixed based on that quick test.
• So I "were holding it wrong" - and the addon let me do so.
• I'd recommend to
  • ideally catch this in the code so the addon can handle this
  • at least put this in the docs, like "don't manually copy backups to the SAMBA backup remote storage and don't rename it there, the addon can not handle this and things will break!"
• Summary: caused by myself, fixed by myself, only took me 3 months, thanks for nothing @thomasmauerer. Keep up the good work.