[18.0][FIX] auto_backup: open cached dump in binary mode

[sebastienclaude]

Bug

When several db.backup records use method=local, only the first one performs the actual dump; the subsequent local records copy the file written by the first via shutil.copyfileobj(cached, destiny) in DbBackup.action_backup.

The source file cached is opened with open(backup), which defaults to text mode. Python then tries to UTF-8 decode the binary dump (ZIP archive or SQL stream containing non-UTF-8 bytes) and aborts with:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd6 in position 12: invalid continuation byte

Symptom from the backup_log mail alert:

Traceback (most recent call last):
  File ".../auto_backup/models/db_backup.py", line 206, in backup_log
    yield
  File ".../auto_backup/models/db_backup.py", line 160, in action_backup
    shutil.copyfileobj(cached, destiny)
  File "/usr/lib/python3.12/shutil.py", line 203, in copyfileobj
    while buf := fsrc_read(length):
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd6 in position 12

Fix

The destination is already opened with "wb", so the fix is to open the cached source with "rb" too:

-                        with open(backup) as cached:
+                        with open(backup, "rb") as cached:
                             shutil.copyfileobj(cached, destiny)

Reproduction / validation

Reproduced on an Odoo 18 instance with two db.backup records, both method=local (one to a local disk, one to a CIFS-mounted share). Before the patch the second copy was a zero-byte file and the cron failed nightly. After the patch the second copy is byte-identical to the first dump (110 MB ZIP, same SHA), and no further UnicodeDecodeError is raised.

Other branches

The same defect is present on branches 16.0 and 17.0 of this module (identical code). Happy to open backport PRs if requested.