Should we drop the destination file if backup was not successful?

[ghost]

When adding support for new systems, I also test the negative paths: for example, what happens if the HashiCorp Vault token doesn't have the required permissions or isn't valid at all.

During these tests, due to my oversight in changing the path, I often get an error message saying that the target file already exists.

This brings up the question of whether the destination file should be deleted if the backup process fails. In my opinion, there is no reason to keep it, but I am open to other suggestions.

[a-mesin]

I am for deleting it. It will most probably be malformed or even empty anyways.

[iabudiab]

I would say, let the user decide.
IMHO, delete-per-default is usually a bad idea. If someone configures the wrong destination unintentionally, then we wouldn't want to delete it without asking 😉

[ghost]

I talked with @a-mesin and we aligned on the following points:

• We should not allow writing to the destination (folder, file) if it already exists. An error should be thrown, which is already the case.
• We will NOT remove the destination file if there was an error while doing the copy. Also a 0 bytes backup can be beneficial for a recovery as the existence of the destination file could help the operator while doing the restore.
• As recommended by @iabudiab, we will provide a config flag to remove the destination file in case of an error. This must be set explicitly by the user: cleanupDestinationOnError = true
• We should do a validation in the source preparation if the source is accessible. It makes no sense to prepare the destination, if the source is not accessible (this will solve my issue already 😅)
  • In case of filesystem: Can we read from the file/folder (file/folder permissions)? Is there something to backup (file size)?
  • In case of an other system: Doing a ping command to check if system is reachable and if the auth creds are correct.

At the moment our process looks like the following:

1. Source preparation: In case of the filesystem we open the file (for streaming)
2. Destination preparation: In case of the filesystem we check if file/folder already exists (if yes we throw an error), we create the file and open it
3. Do the copy (streaming from source file into the destination file)

Now I would add to the 1th step a accessibility check and a new 4th step regarding the post backup/cleanup (I think this will be needed in the future anyway to):

4. Post backup/Clean up
   • close files/connections
   • remove destination file in case of error and if the cleanupDestinationOnError config was set to true

WDYT about these points?