There is no way to delete the files on the backend when the files are being fetched.

If the file is being fetched and modified, there will be a delete transaction to delete the existing file on the backend media (ie NAS, Centera etc)
This file (that has been modified) will be treated as a brand new file and dx will migrate it according to the rules defined

This delete transaction to delete existing file on the backend media is a script?

There is an automatically way to accomplish it for fetched and modified files?

thanks

Sorry....the files will not be deleted on the backend.
When a file is fetched and modified..it will be treated as a brand new file by DX.

Question here,

1) Is the file modified and saved in a diff name?

OR

2) The content of the file has been modified/updated but saved in the same name.

Message was edited by:
coreylow

In this case the customer uses both options.

Sometime modified and save in different folder, but with the same name and sometimes saved in the same name same place.
In this case the file server has more than 10 TB of the data.
In the policy defined for audit, they needs to migrate files not modified more than 730 days.
They has reports that about 700GB of this data are fetched per month, and they don¿t want to have different versions of files in different places.

This customer used an ILM software from HP called FMA that has this feature (purge files in the backend), but this software was discontinued from HP.


I¿m studying one way to use the DX for this environment.
So I¿m thinking to changes the migration rule, to migrate files for the creation date associated to other migration rule but negative to not permits migration files newest than 2 years in the modified date.

Do you know if this is possible? Or you¿ve another way to accomplish it.

Thank you very much.

Paulo

To understand what you are trying to achieve here, I suggest you log a support call and seek for advise

I'm not sure if I should be opening a new thread but this brings up a question I've had for a while and hadn't asked.

If I move a file to centera, then purge the file from the extended drive: I have one copy of the file on centera and just a stub on the extended drive.

If someone fetches the file for reading but does not modify it: I have two coppies of the file, one of centera and one on the extended drive. I can then just purge the file off the extended drive by matching a purge rule and running a background scan, Correct?

If someone fetches a file and modifies it, saving the file with the same name but changes the contents, what happens? I assumed the original is delete from Centera but this thread kind of confused me on that point.

Thanks,
Christian

Hi Christian

Your first explanation is correct.


Let me explain the way dx works with purged files. When a purged file is fetched back and modified, it becomes non dxmanaged. So you will have two copies of the file, one old copy in the Centera and one new in the dx drive.
The file that was fetched back and modified, must wait to be qualified as your move rule, to migrate to centera again and overwrite the existent file with same name.

Best Regards

Paulo

If I modify and save the file then have the old copy on centera and a new unmanaged file on the extended drive, how does the one on centera ever get cleaned up if I delete the new unmanaged file on the extended drive?

Thanks,
Christian

The best recommendation to get rid of that file in the Centera would be to manually delete it

The file that was fetched and modified is like a new file to DX.
It will become managed after be qualified as your move-rule policy.
The file that is non DXmanaged is the old copy that stayed on the backend media (Centera). The DiskXtender not recognize the existence of this file on the backend media(Centera).
If you delete the file before be dxmenaged, you will only remove the file from extended drive.
Now if the file was qualified at your move-rule it will overwrite the existent file on the backend media (centera) leaving only the stub on the Exdrive. After that, if you delete the stub. The DX automatically will remove it related file on the backend media.

You can configure the DX_recycle to prevent errors from users.

Regards
Paulo