Corrupted backup

[mwrben]

Upgraded to 9.0 from 7.2
I use rclone to backup directly to pcloud. Previously worked faultlessly. Now backup folder is OK, but nested folders e.g. homeassistant.tar.gz do not open up - triggers message that not an archive or corrupted.

[patman15]

Looking at the code, this behaviour was changed in commit 3eb51c2.
Nested folders are included in the backup itself.
Not sure what the intended behaviour should be, as rsync still does it as previously, although sub-folders are then copied redundantly (once direct, once included in the backup).

[mwrben]

The sequence I've seen is that the backup file is a .tar file
I extract that and I get a folder containing a number of tar.gz files
With 7.2 I can then extract those without any problem, with 9.0 the files won't extract.
For now I've downgraded back to 7.2 which continues to work fine

[patman15]

The sequence I've seen is that the backup file is a .tar file I extract that and I get a folder containing a number of tar.gz files

That should be still the case. The backup file itself is generated by HA locally. The add-on just does the transfer. Can you post a log using debug enabled and your configuration?
Also, did you try to restore the backup using the HA GUI? If so, there is no need to extract anything before you do so!

[mwrben]

debug log and config attached. I couldn't see anything obvious in the log file.
debug log.txt
new rclone config.txt

[ikifar2012]

the backup is fully generated by the by supervisor, the only change I can think of that might impact what you are seeing is if you were using zip password before we have moved to using the supervisor's built in password option so it generates an encrypted tar instead of packing the tar in a zip. Otherwise looking at your logs the backup was successful, try making a backup manually from the UI, download it and see if it is corrupt, if not, try running the remote backup addon again. Also ensure you have sufficient free space on your home assistant machine to ensure it has enough space to complete the backup

[mwrben]

Thanks for looking at this. I can't be the only one using rclone to backup to a cloud service, so if it's not just my setup this issue should reappear. The only thing I've found is if I simply look inside a gz file, the ones that work the first line has for example �‹��'�Öb�ÿssl.tar í—]o£8�†s]©ÿ!ÊílƒÍ—a¤JC� characters , but in the same gz file in the failed backup it has 娔৬弓両灐ꆾↅ掯﫪⨔䯈喝녨붵㻚崚厶
Maybe this is significant. For now I will go back to 7.2 which works fine. I can close this if you wish.

[SirGoodenough]

I just did a test restore, from the backup generated by this addon via the supervisor and I have a password applied I had to add the password to restore it or it just error-ed.
1, do you have a password applied in the addon config?
2, did you plug that password in when you tried to restore something?

Not using the rclone, but am using the ssl backup and the rsync.
The rsync files are all there and restore fine.
The ssl backup files I was able to import back into HA and when I put in the password in HA, was able ro restore one of the folders. I didn't want to restore all, but what I did restore went fine. Test passed...

[mwrben]

I've found the the issue. It's a very subtle thing related to the config file. With 7.2 I did not use a password to protect the backup, the config file had the option:- zip_password: ""
In the new config for 9.0, the new option for backup_password was simply omitted if it wasn't set - and this led to the archive not opening. I added in the option backup_password: "" back to the config file and everything now works.

[SirGoodenough]

Well if that is required it might be a bug. I didn't try with an empty password.

[patman15]

Well if that is required it might be a bug. I didn't try with an empty password.

Need to check when I"m back. There were some configuration option issues with non-existent entries versus empty string. This is not equal and causes troubles, probably also with the password setting.
Please keep the issue open until verified.

[realtmf]

FWIW, I had to restore some files (ssl.tar.gz) from backup and experienced the same issue after upgrading to 2022.9.0 (thanks for providing this useful addon, though!)
Edit: the workaround of adding in the option backup_password: "" fixed it all right.

[patman15]

@realtmf Thanks for the feedback, I have an idea what the issue is, I'll provide a fix in the coming weeks.

[ikifar2012]

I have attempted a fix, it appears to work for me, I am going to release it now as it does appear to work, feel free to reopen this issue if you have any issues after updating

[mwrben]

Updated to 9.1
I removed the workaround of backup_password: "" from the config and I can confirm the archive was fine.
Thank you for fixing.

[ikifar2012]

I am re-opening this issue due to a bug found by @SirGoodenough, it appears now it is always defaulting to no password, I think I have the solution, just need to test

[patman15]

@ikifar2012 I think the easiest solution is to replace the default value '' with "" in

remote-backup-addon/remote-backup/run.sh

Line 101 in bae7265

local data="{\"name\":\"${BACKUP_NAME}\", \"password\": \"$(bashio::config 'backup_password' '')\"}"

Note that the right escaping needs to be used. Just an educated guess as I cannot test it at the moment.

[ikifar2012]

@patman15 I did try the single quotes yesterday and was unreliable, as sometimes the config returns null, as of right now I have an if statement working with a warning to the user that there backup is unencrypted if they use no password it seems to work, I am just about to push the pr, turns out the reason the if statement I pushed out yesterday didn't work was because of me using the var ${backup_password} instead of the config option "backup_password"