Unified Backups: Handle existing data when restoring from a backup

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

The following discussion from !164205 (merged) should be addressed:

• @mkozono started a discussion: (+4 comments)

  question: If I understand correctly, this runs backup again, overwriting the source backup file, and then restores the source backup file, so nothing would change.

  It looks like lib/backup/targets/files.rb moves data that would otherwise be overwritten by restore, to a new directory in tmp; I assume we intended to copy that behavior?

  If so, then we should add and adjust #restore tests to prove that:

  • application data is moved out of the way, to some other directory
  • the data in the .tar.gz backup file gets expanded and modifies the application data

We have a few options to handle existing data when restoring from a backup.

Copying over from @brodock's comment in the conversation over Slack:

Option 1: Legacy behaviour: if you had something in artifacts we would move that to artifacts.202410181210 upside: it’s simple, we move files around downside: it takes extra disk space

Option 2: if we detect existing data we tell the user they need to clean that before trying to restore (alternatively allowing a scary --delete-existing-data sort of flag)

Options 3: we run a backup before restoring over existing data, if we detect existing data (upside, easy to undo a mistake, downside: can take a lot of time)

As the shortest iteration during decoupling of the cli from the rails codebase, as part of !164205 (merged) we will ignore existing data, log a warning and continue with a restore.