[17.0] [ADD] auto_backup_fs_file: introduce Auto Backup Fs File module

[rrebollo]

New Module: Automatic Database Backups via FSSPEC

This module introduces automated database backups storing feature using an FSSPEC implementation, along with the necessary configurations and views.

The primary goal of this addon was to provide a way to directly download backups. We explored the work done in the storage repository around the FSSPEC library, which seemed like the most suitable approach.

Refactoring Considerations

Currently, some refactoring could be done in the auto_backup addon to make it more flexible and extensible. This might include:

• Removing SFTP support, at least partially.
• Potentially extracting or restructuring the storage feature.

However, these improvements are out of scope for this PR.

Roadmap

• [x] Store generated backup files using an FSSPEC implementation.
• [x] Implement the cleanup process.
• [x] pass coverage checks
• [x] dedicated activity notification ??category??
• [x] i18n (es)

@BinhexTeam

[jelenapoblet]

Results of a functional review:

• workd correctly after a couple of clicks here and there, I was able to do the backup and download it.
• After more playing around I got this error:
• Database backup failed.

Database backup failed.

Traceback (most recent call last): File "/opt/odoo-server/extra_addons/oca/server-tools/auto_backup/models/db_backup.py", line 214, in backup_log yield File "/opt/odoo-server/extra_addons/oca/server-tools/auto_backup_fs_file/models/db_backup.py", line 43, in action_backup fs_backup.fs_file_backup_ids = [ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo-server/odoo/fields.py", line 1334, in __set__ records.write({self.name: write_value}) File "/opt/odoo-server/addons/mail/models/mail_thread.py", line 317, in write result = super(MailThread, self).write(values) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo-server/odoo/models.py", line 4452, in write field.write(self, value) File "/opt/odoo-server/odoo/fields.py", line 4353, in write self.write_batch([(records, value)]) File "/opt/odoo-server/odoo/fields.py", line 4374, in write_batch self.write_real(records_commands_list, create) File "/opt/odoo-server/odoo/fields.py", line 4564, in write_real flush() File "/opt/odoo-server/odoo/fields.py", line 4520, in flush comodel.create(to_create) File "<decorator-gen-0>", line 2, in create File "/opt/odoo-server/odoo/api.py", line 431, in _model_create_multi return create(self, arg) ^^^^^^^^^^^^^^^^^ File "/opt/odoo-server/odoo/models.py", line 4654, in create records = self._create(data_list) ^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo-server/odoo/models.py", line 4901, in _create field.create([ File "/opt/odoo-server/extra_addons/oca/storage/fs_file/fields.py", line 282, in create cache_value = self.convert_to_cache(value, record) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo-server/extra_addons/oca/storage/fs_file/fields.py", line 418, in convert_to_cache name=self._get_filename(record), value=base64.b64decode(value) ^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/base64.py", line 88, in b64decode return binascii.a2b_base64(s, strict_mode=validate) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MemoryError 

[rrebollo]

I’ve merged your proposals, @adasatorres.
@jelenapoblet, could you please run the test again using at least a medium-sized backup?

[jelenapoblet]

Functional review: Everything works as expected. I was able to create a backup by selecting the FS Storage, download the resulting ZIP file, and successfully import it into a local container. My only concern is that the UX could be more user-friendly. Accessing the backup via the “Technical” section makes sense for an initial setup, but for downloading backups, a dedicated menu icon could significantly improve the user experience.

[rrebollo]

Hi @jelenapoblet,

Thanks for the suggestion! I've added it to the roadmap.

Just to confirm, you're referring to an app menu, correct?

[jelenapoblet]

Instead of a menu icon, would activity notifications make more sense? When a backup finishes, send a notification and include a direct link that takes admins straight to the backup to view or download.

[AnsarLatif]

Tested with fs_file dependency installed — auto_backup_fs_file works as expected. Scheduled action created, manual backup successful, no errors. PR works well for scheduled backups. It would be great to also have a menu item for manual backup download.

[jelenapoblet]

@rrebollo do you think we can do an extra push to get this done ?

[rrebollo]

@jelenapoblet Hi! Just a quick update on the progress. As you probably saw yesterday, I pushed several improvements. I’m now finishing the test suite. Without those tests, the work in this PR doesn’t really make much sense, since that’s what guarantees the new features don’t break any of the existing behavior provided by AutoBackup. It also gives us a solid base to evolve the feature safely in the future. Tests should be ready today, if everything goes well.

Although we’re currently proposing this PR as an addition in the form of a new addon, the more I work on it, the clearer it becomes that its natural destination should eventually be AutoBackup itself. AutoBackup currently includes several storage backend mechanisms, while this proposal simplifies the whole process by defining FS as the underlying storage layer. The actual implementation depends on whichever FS library is used in Python, but from the addon’s perspective, the storage becomes entirely transparent. With that, much of the existing storage-management machinery in AutoBackup could ultimately be replaced by this approach. That’s something for a future discussion with the maintainers, but the long-term direction is obvious.

I also want to mention something related to the notification feature you suggested, Jorge. It fits perfectly in the main (Auto backup) addon: after a backup finishes—regardless of the storage backend—a user should be notified and able to download the resulting file. At the moment, we’re only implementing it in our addon when FS storage is used, but the idea is clearly generic.

I’m still evaluating whether to keep the notification logic here or move it into a separate improvement PR targeting AutoBackup directly. It depends on how flexible the current storage code in AutoBackup is. If it allows me to plug in the notification mechanism without much effort, I might propose it upstream. If not, I’ll leave it here for now. But it’s clear that this feature isn’t tied to FS specifically—it’s something that belongs in the core workflow, no matter which storage backend is used.

[jelenapoblet]

Hi @rrebollo , thanks for your comment. I agree that the notification could live in a separate module, that makes sense. However, this module should allow users to download the ZIP file generated from the backup. Right now, that isn’t possible from the interface. Autobackup works great when you have FTP or SSH access, but it’s not designed for end users. This development effort should address the user-side use case: being able to download the backup directly.