Re: Force Restore of files tagged UNIT(*SSD) to Spinny Disk -- MIDRANGE-L

× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

One more thought. We used to have a mix of SSD and spinnys. We no longer
have that, so I cannot experiment. However, I recall there was a time when
I could alter the UNIT attribute and the move would be made immediately.
There were other times (either through OS upgrades or PTFs) when I would
change the attribute and it required a save/restore to make the effect felt
(never tried your RGZPFM).

Anway, I see two possible solutions based on what you find to be the
behavior. If the UNIT attribute happens immediately, you do the restore
and then change the attribute. If it is delayed, then you change the
attribute on the source machine, save, and then change the attribute back,
theoretically not affecting the SSD status on the source machine, since the
affect is not immediate.

Have a customer with SSD and Spinny. Many files in production DB tagged
UNIT(*SSD). Monthly they restore production backup (about 1TB) to
training library and you guessed it all those files pile on the SSDs
overfilling them. Any idea how to make the Restore override the
UNIT(*SSD) and put them on spinny disk?

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.