Capacity Tier - file time stamps

[Cragdoo]

Hopefully this is just my misunderstanding about Capacity Tier, but I think I found a potential gotcha in my lab

Example

I have a Backup job with a single VM, set with 2 retention points. The VM is backed up to a SOBR with S3 Capacity tier and set to move backups older than 1 day.

I perform my 1st backup, BKP_Aat 10 am, which of course is an active full. I then perform a 2nd incremental backup, BKP_B at 10:30am. I then perform a new active backup, BKP_C at 11:30am, to seal the chain of the previous 2 backup files. So now I have 3 files

BKP_A .vbk, 10:00
BKP_B .vib , 10:30
BKP_C .vbk. , 11:00

I then performed a manual 'copy backup and dependencies to the capacity tier), this completed 100% at say 1pm.

I then notice the metadata files now have a new time stamp of when the files were copied to the capacity tier. Now when I attempt to do a file level restore from the Capacity tier, the restore points are reporting the new time stamp.

BKP_A .vbk, 13:00
BKP_B .vib , 13:00
BKP_C .vbk. , 11:00

This could cause potential confusion if say users/customers ask for files to be restore from a certain date. E.g. we backed up a customers VM 10 days ago, and today we decide (or through policy) to move the VM backup data to the Capacity tier. From what i see the files now have today's time stamp, so if that customer says "please restore file <x> from 10 days ago" ...how would we know the correct backup files to select?

hope that makes sense.

[Cragdoo]

and I've just retried another new job, but this time it's working as expected. The time stamps on the actual backup files are updated, but the time stamp on the restore items is the correct time stamp .... strange.

[Gostev]

Normally, restore point time should not change as it is not affected by tiering, and this is what UI displays in the Restore dialogs.
Backup file time stamp will of course change, because we create a stub file the moment when offload competes.