Best method of Export.

[Duddey]

Management says "No More Tapes", so I am looking to get the data from our four data centers to our DR site across our WAN. We have a need to keep multiple versions, indefinitely, so replication does not appear to be the answer. Much of the data is SQL TDP, so I am looking to use exports.
Here is my dilemma. The domain defs on each of our four TSM servers are identical, so it appears that the exports will want to put them all in the samt location on the target server, if I use the 'toserver' option. I want to keep the output from each of the exports segregated so that I don't have them all in the same directory on the target server. I have been able to accomplish this by using the UNC name of the target server for the directory in the devclass rather than using the 'toserver' parameter. Am I losing any capabilities by using the devc method rather than toserver.

Thanks,
Duddey

 

[moon-buddy]

Management says "No More Tapes", so I am looking to get the data from our four data centers to our DR site across our WAN. We have a need to keep multiple versions, indefinitely, so replication does not appear to be the answer. Much of the data is SQL TDP, so I am looking to use exports.
Here is my dilemma. The domain defs on each of our four TSM servers are identical, so it appears that the exports will want to put them all in the samt location on the target server, if I use the 'toserver' option. I want to keep the output from each of the exports segregated so that I don't have them all in the same directory on the target server. I have been able to accomplish this by using the UNC name of the target server for the directory in the devclass rather than using the 'toserver' parameter. Am I losing any capabilities by using the devc method rather than toserver.

Thanks,
Duddey

You should not be loosing any data provided that you export all backups and archives.

 

[Duddey]

You should not be loosing any data provided that you export all backups and archives.

Thank you Moon-Buddy.

 

[marclant]

have a need to keep multiple versions, indefinitely, so replication does not appear to be the answer.

Might be too late now, but replication sends both active and inactive data.

 

[Duddey]

Marclant,
That's very interesting. It has always been my impression that replication was concerned with the most recent 'active' version of the files.
If a file on the source is deleted, or modified then it is also deleted or modified on the target. I need to keep point in time versions indefinitely, no matter what happens on the source. That is why I chose to go with exports, but it's never too late to change, if replication is a better method, then I am interested.

 

[marclant]

Replication is better in the sense that you can run it X number of hours every day until it has nothing left to replicate. Replication will automatically skip objects that already exist on the target as well. As long as your policies are the same on both sides, retention will be the same.

Export is less efficient if you have to stop it and restart it because it doesn't track what's been previously exported like replication does.

As far as data movement, both will give you the same end result.

 

[opeth]

don't mean to hijack a thread here, but I having to export a TON of data from one TSM server to another that is the new target for backup. I never considered replication as a possibly solution but it makes sense.
What I did not know is "Export is less efficient if you have to stop it and restart it because it doesn't track what's been previously exported" I thought export node picked up where it left off when you restart it, if that's not the case im in a bit of a mess as I am having to stop it periodically because its killing my activity log.

If I have already pointed backups to the new TSM server, and I flip on replication from the old to the new, it will start deleting data on the new because it doesn't exist on the old (source) server during expiration right? To complicate this more all this data is in permanent retention

Am I understanding this correctly?

 

[marclant]

What I did not know is "Export is less efficient if you have to stop it and restart it because it doesn't track what's been previously exported"

It's not entirely true. If the export runs to completion, but you have to rerun it again because new backups were made to the old server, it will inspect everything, the replication would not. If you cancel the export, you can restart it. More info here:

An export operation is suspended when any of the following conditions are detected:

• A SUSPEND EXPORT command is issued for the running export operation
• Segment preemption - the file that is being read for export is deleted by some other process
• Communication errors on a server-to-server export
• No available mount points
• Necessary volumes are unavailable
• I/O errors encountered

Issue the QUERY EXPORT command to display information on any running and suspended export operations.

source: https://www.ibm.com/support/knowled...0/srv.reference/r_cmd_node_othsvr_export.html

If I have already pointed backups to the new TSM server, and I flip on replication from the old to the new, it will start deleting data on the new because it doesn't exist on the old (source) server during expiration right? To complicate this more all this data is in permanent retention

Am I understanding this correctly?

Replication only moves data from the source to the target, it doesn't delete data on the target. Expiration on the target is what is responsible to remove data passed the retention.