You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Incremental backups are the next step to creating a backup as small as possible, and a good compromise between usability and efficiency is using a Git based system, similar to Fast Backup. I would say the standard we should aim for is a backup that is able to be opened by Git client like Github Desktop.
Features it should have:
Use Git features to save incremental snapshots of the world, saving space
Optional push to a user configured repository
Use intelligent strategies to also gain a speed improvement over traditional Chronos Backups
The speed improvement is less straight forward. While normally, we could compare the region file with its previous version to see if it needs updating, but for Chronos, the region file is pruned, meaning before we could do a comparison, we have to prune it, which wastes compute. To get around this, we should compute the pre-prune hash and save it in a database in the generated repository, and this will be read by the next backup to figure out whether the file changed at all and whether replacing (and thus also pruning) will be necessary. This database will then be replaced after the backup to prepare for the next backup.
Additional note: config changes can change the pruning selection without generating a different hash. We need to account for this. We can store a hash of the config itself to watch for changes. All changes to the config file should be considered "breaking".
Activity
MagicJinn commentedon Sep 2, 2026
Additional note: config changes can change the pruning selection without generating a different hash. We need to account for this. We can store a hash of the config itself to watch for changes. All changes to the config file should be considered "breaking".