Delete existing files when restoring from backup

[KairuByte]

Feature Request

Feature Information:

Some server events that would require a restore from backup, include bad data in newly created files. Be it malicious plugins, or a bad config, those files remain in place when restoring from a backup.

It would be exceedingly helpful in such cases to wipe out existing data, and write the backed up data in it's place.

I confirm:

• [x] that I have searched for an existing feature request matching the description.

[LexiconCode]

Overwriting files as a restore method mixes the restored files with any newly created files. An example issue:

MineCraft generates chunks as players explore. With the current system of overwriting files the restored chunks and the chunks generated after the restore point would be mixed together. Only part of the map would be restored and the rest which is not overwritten would stay the same. The server administrator meant to restore to an earlier point where those new chunks did not exist yet. In the current system there is no way to do that without manually deleting files. Simply overwriting files is not a true restore.

The purpose of a restore point is to revert back to a known working state. What is a known state? That expectation is based on the purpose of restore. Some examples could be configuration change needs to be reverted, mods, map data, player inventory and so on. The bottom line is restoring by overwriting files only leads to unexpected results.

[FrozenSoda]

I agree that this feature would be important - another issue is that the current restore implementation might cause unintentional duplication of in-game items. For example in Minecraft, if a new player joins, an inventory file will be created for that player. If the player then obtain items from a chest, and the server is subsequently restored from a backup created before the player first joined, the items in the chest will be restored, but will also remain in the player's inventory since the inventory file did not exist at the time of the backup (and will not be deleted as per the current restore implementation) - now the items exist in two places.

[LexiconCode]

This should be incredibly trivial to implement.

[PhonicUK]

The reason this isn't a thing right now is because of backup exclusions. If you delete files that aren't about to be overwritten then what you have isn't a backup, but a snapshot - which precludes having exclusions of any kind.

[LexiconCode]

Most administrators want to restore the server to a working state completely. If they have to, they will manually reach into an broken server backup to restore individual files if it's relevant. That leads us to two possible ways to restore based on the intent of the admin.

1. An Admin wants to restore specific individual or sets of files to which restore by overwriting existing files.

2. An Admin wants to restore server to previous state. (They may not know which file or folder is causing issues with the server.) Requires server delete contents and then restore.

Exclusions can work in both of these scenarios.

To restate the problem: Restore by overwriting only into existing files leads to unexpected results. This is true of anything that generates files that increase in number or if a user adds mods which also may generate files. Minecraft is a great example of this issue.

I'm not up to date on how the exclusions currently function. ( I don't rely on the amp backup mechanism because of this issue.)

However, if exclusions function like the following:

1. The admin decides what's important or not by exclusion. (not exclusion template auto-generated.)
2. Excluding file or folder excludes it from backup and restore.

Fundamentally, it's a user's responsibility whether or not something is excluded explicitly.

Possible implementation.

If those two points are true, Then restoring could delete all files, excluding the files that are on the exclude filter. This would make restoring reliable.

The restore process could look like this.

1. The user has a broken server. They could choose between A or B

• A. A admin chooses to restore a date and time. which would restore by deleting all contents minus the exclusions and restoring all files from the backup.

• B. The admin clicks into a back up time and date. A file system appears and they're offered to restore individual files or folders. This would then restore by overwriting files only.

A simpler approach to A and B:

The user could have a checkbox on restore to overwrite existing files. If the box is unchecked then it would delete all files minus exclusions then restore.

[FrozenSoda]

Perhaps AMP could store the exclusion rules for each individual backup in their metadata. Prior to restoring a backup, the user can choose between these three options, where option b is the default:

a. Keep all current files and overwrite with backup contents. b. Delete all current files not matched by the exclusion rules of the backup to restore. c. Delete all current files.

If selecting option b, AMP should display which files will be retained.