Sorry, not sure I understand the use-case and the feature request itself. On what step do you want to perform the purge of the cloud data and what do you mean by " files that are no longer part of the latest backup "?

Hi Matt,

Sorry, maybe I did not express myself clear enough.

The schedule restore jobs I suppose are often used to verify the backup state in the cloud on regular basis.

Let suppose we have a FILE BACKUP JOB that runs one time daily in the morning, and another scheduled backup RESTORE JOB with the option do not restore deleted files selected that restores the backup one time daily in the evening. If we consider the cloud backup repository is the “source” of the restore job, than the “destination” is the location where the files should be restored.

The current state of the CloudBerry implementation of the scheduled restore process is as follows, having in mind that we have selected that the restore job should not restore deleted files:

1. On the first day run of the restore job, it creates the destination folder and restores ALL data (files) from backup source (fair enough)
2. On the second day (scheduled) run the job restores to the same destination, however this time it restores ONLY THE NEW FILES and skips the files that already exist in restore destination. (That is nice ;), because we don’t need to restore files that haven’t change since the last backup and are still in restore destination)
3. On the third day run the restore job acts identical to the second run, restoring ONLY THE NEW files
4. And so on…

But this, however does not mean that we have in our restore destination the exact same content of the last backup state as it is in the backup repository (1:1). This is due to the fact that the scheduled restore job kept restoring new files, skipping already existing files in restore destination, which eventually led to accumulation of files that are obsolete in the restore destination. “Obsolete”, considering that such files were maybe deleted by the user and are no more part of the latest backup (respectively restore point), having in mind that we have selected that the restore job should not restore deleted files.



The New Feature could be: a “Mirror restore” (MIR) with PURGE similar to the behavior of the robocopy MIR switch. If user selects that option of scheduled restore job than the jobs restores as usual (skipping old, restoring new files, and not restoring deleted files), but also purging files in the restore destination that are no longer part of the latest restore point.

This way after each run of the restore job we will have in our restore destination (1:1) mirror of the latest restore point (state) of the backup as it is since the last run of the relevant backup job.


USE-CASE :

Daily Backup validation by means of running a scheduled restore job, that restores in a specified restore folder the content of the backup as it is in the backup repository in the cloud. In the end there should be a restore destination folder with 1:1 mirrored content as the latest backup in the cloud.

This eventually means that the restore job should: skip already existing files in restore destination (it is how it works at the moment), restore only new files, and purge files that are not a part of the latest backup restore point (such files were deleted in the past and are part of old backup( old version)).

The same as Robocopy MIR Switch.

I think this feature would be really nice to have, even must to have that would give more value to the CloudBerry backup.

Thank You

Denny

Ok, thanks for the detailed explanation!
Forwarded that info to our developers and created a feature request on your behalf.

Thank you Matt