increasing restore speeds for the COPY POOLS (DRP)

[smetter]

I occasionally schedule a move nodedata operation for
nodes that have a huge amount of small files,
this way, re-organising the data on the tapes,
so that fewer locate commands need to be performed,
this way increasing restore performance for these nodes.
However,
this will only improve restore speeds for these nodes
when restoring from the onsite media (primary tape pools),
but this will have no effect on the restore performance
from tapes that are members of the copy pools (in case
of a disaster recovery)
I was wondering how the same can be done to improve DRP restore speeds.
I could have the relevant tapes come back from the offsite location,
check them in as private, update their access to readonly,
schedule a move nodedata for the relevant nodes on the copypool,
check out these tapes again with a move drm
and send everything back to the vault.
But...
this is obviously not very practical.
Is there a better way to improve restore speeds for
the copy pools (to improve DRP restore performance) ?
I guess collocation on the copy pools could help but
it will still not have the same benefit as a move nodedata
for nodes with a huge amount of small files I think,
but this will cause too much partially filled volumes
at the offsite location I think.

Any thoughts on this?

 

[moon-buddy]

Short answer: enable collocation by node for the copy pool

 

[smccambly]

Unfortunately there is no easy/single solution to the problem of collocating physically offsite copy pool media.

If you have already identified the nodes with the large numbers of small files and are doing the MOVE NODEDATA commands on the primary pools, then I would suggest you also do it for the offsite copy pool.

Since the data is already nicely collocated from your first MOVE NODEDATA efforts, the process should not take very long. You will be re-creating the copy pool data for these nodes on new media (using the data from the primary pools), and then probably be causing a lot of reclamation operations on the copy pool media as well, but it do what you are trying to accomplish.

Scott McCambly

 

[smetter]

Thanks for your answers.

We've decided to take a monthly selective backup of certain filesystems on certain servers, to a different nodename in a different policy domain. (only 1 version)

This way, for filesystems with a huge amount of data, spread over tons of small files,
we can use the selective backup first to restore most of the data in a fast way,
and then do a restore from the latest incremental backup under the normal nodename, using option replace ifnewer.

We will probably also move the normal nodes to a different stgpool and enable collocation by filespace later.