Re: AW: TSM Replication
This is very good information but it's not exactly what they want. These commands only show you a particular client. What I'm looking for is some kind of script or command that will show you a summary of what has been replicated from the Source to the Target for an entire nodegroup, not just a particular client. When replication completes, it show you a summary of what has been deleted, replicated and so on. I need that same kind of information from the Target so that Management can see it replicated to the Target successfully. They don’t like that the Source server saying it was replicated successfully. They want to see those numbers (summary) on the Target. At this point, because the Source uses the REPLICATIONVIEW table for this information and the Target REPLIACTIONVIEW table is empty, there may not be a solution to draw out this information. Thanks for the help. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Jeanne Bruno Sent: Monday, July 25, 2016 8:20 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] AW: TSM Replication Hello. Thanks Michael. Rick does this help you? (or do you think this is sufficient for your management team?) On the source server do 'q repln <nodename' On the target server do 'q replnode ' If you have dedup on, there will probably be less files on the target server. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael Malitz Sent: Saturday, July 23, 2016 12:52 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Hallo Jeanne Bruno, Try the following: on the target server: enter q replnode it's kind of a "circumvention" -- you will see the data you would like to know, but the target server indication in the output is not correct….ignore- But most important, you execute the command on the target server and get your data from ONE central/focal point! rgds Michael.Malitz mm-it.at -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Jeanne Bruno Gesendet: Freitag, 22. Juli 2016 20:31 An: ADSM-L@VM.MARIST.EDU Betreff: Re: TSM Replication Thanks! I just did the q repln on the source server. And yes it shows the filespaces and data amount for both source and target. Beats doing the q fi on source and target! But when I do q repln on the target server I get 'no matching servers defined'. I think the original question asked by Rick's Management team was 'is there a query one can do on the TARGET server to confirm what was replicated' -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Karel Bos Sent: Friday, July 22, 2016 2:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Replications between source and target means that that data is being sent from source is being received by target. If the target doesn't confirm receive of data the replication process failes. After replication process had completed one can use the q repln command to check the replication state of any node configured to do replication. It shows how many objects and amount data of the nodes are on source and on the target. Op 22 jul. 2016 17:39 schreef "Jeanne Bruno" <jbr...@cenhud.com>: > Hello. for this: but, I need to verify that on the TSM TARGET server > as well. Management wants to be able to verity that what the TSM > SOURCE server states was replicated is the same as what the TSM TARGET server > states. > > > > We don't have replicated info on our Target server either. I'm > thinking only the source would store it and the Target server sees it > as just data and not 'replicated' data once stored in the pools. > > > > Can you verify doing 'FI' queries on both target and source. (the > capacity & percent utilization should be the same on both servers, > no?) > > Also maybe open a TSM gui or command line on one of the replicated > servers and see what's there to restore. > > > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Rick Adamson > Sent: Friday, July 22, 2016 8:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM Replication > > > > > > ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / > attachments. Never supply UserID/PASSWORD information. > > > > > > Ricky, > > I know that on the source server there is a field (BKBYTES_REPLICATED) > in the R
Re: AW: TSM Replication
Hello. Thanks Michael. Rick does this help you? (or do you think this is sufficient for your management team?) On the source server do 'q repln <nodename' On the target server do 'q replnode ' If you have dedup on, there will probably be less files on the target server. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael Malitz Sent: Saturday, July 23, 2016 12:52 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Hallo Jeanne Bruno, Try the following: on the target server: enter q replnode it's kind of a "circumvention" -- you will see the data you would like to know, but the target server indication in the output is not correct….ignore- But most important, you execute the command on the target server and get your data from ONE central/focal point! rgds Michael.Malitz mm-it.at -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Jeanne Bruno Gesendet: Freitag, 22. Juli 2016 20:31 An: ADSM-L@VM.MARIST.EDU Betreff: Re: TSM Replication Thanks! I just did the q repln on the source server. And yes it shows the filespaces and data amount for both source and target. Beats doing the q fi on source and target! But when I do q repln on the target server I get 'no matching servers defined'. I think the original question asked by Rick's Management team was 'is there a query one can do on the TARGET server to confirm what was replicated' -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Karel Bos Sent: Friday, July 22, 2016 2:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Replications between source and target means that that data is being sent from source is being received by target. If the target doesn't confirm receive of data the replication process failes. After replication process had completed one can use the q repln command to check the replication state of any node configured to do replication. It shows how many objects and amount data of the nodes are on source and on the target. Op 22 jul. 2016 17:39 schreef "Jeanne Bruno" <jbr...@cenhud.com>: > Hello. for this: but, I need to verify that on the TSM TARGET server > as well. Management wants to be able to verity that what the TSM > SOURCE server states was replicated is the same as what the TSM TARGET server > states. > > > > We don't have replicated info on our Target server either. I'm > thinking only the source would store it and the Target server sees it > as just data and not 'replicated' data once stored in the pools. > > > > Can you verify doing 'FI' queries on both target and source. (the > capacity & percent utilization should be the same on both servers, > no?) > > Also maybe open a TSM gui or command line on one of the replicated > servers and see what's there to restore. > > > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Rick Adamson > Sent: Friday, July 22, 2016 8:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM Replication > > > > > > ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / > attachments. Never supply UserID/PASSWORD information. > > > > > > Ricky, > > I know that on the source server there is a field (BKBYTES_REPLICATED) > in the REPLCIATIONVIEW table. I have used it to query the amount of > replicated data. > > Perhaps someone can chime in from IBM but I did not find this > information maintained on the target server; if fact I receive an > error when attempting to query the REPLCIATIONVIEW or REPLTASK tables on it. > > > > On another note I'm not sure it is necessary; when the "replicate" > task starts the source server initiates sessions with the target > server and begins sending data. I would think that there is some type > of integrity check and acknowledgement performed by the target server > and sent back to the source server, if there's any issues the task > would complete with a failure state. > > But again that's more of a logical assumption, I have to defer to > gurus at IBM for clarification > > > > -Rick Adamson > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] [mailto:ADSM-L@VM.MARIST.EDU]> On Behalf Of Plair, Ricky > > Sent: Friday, July 22, 2
AW: TSM Replication
Hallo Jeanne Bruno, Try the following: on the target server: enter q replnode it's kind of a "circumvention" -- you will see the data you would like to know, but the target server indication in the output is not correct….ignore- But most important, you execute the command on the target server and get your data from ONE central/focal point! rgds Michael.Malitz mm-it.at -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Jeanne Bruno Gesendet: Freitag, 22. Juli 2016 20:31 An: ADSM-L@VM.MARIST.EDU Betreff: Re: TSM Replication Thanks! I just did the q repln on the source server. And yes it shows the filespaces and data amount for both source and target. Beats doing the q fi on source and target! But when I do q repln on the target server I get 'no matching servers defined'. I think the original question asked by Rick's Management team was 'is there a query one can do on the TARGET server to confirm what was replicated' -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Karel Bos Sent: Friday, July 22, 2016 2:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Replications between source and target means that that data is being sent from source is being received by target. If the target doesn't confirm receive of data the replication process failes. After replication process had completed one can use the q repln command to check the replication state of any node configured to do replication. It shows how many objects and amount data of the nodes are on source and on the target. Op 22 jul. 2016 17:39 schreef "Jeanne Bruno" <jbr...@cenhud.com>: > Hello. for this: but, I need to verify that on the TSM TARGET server > as well. Management wants to be able to verity that what the TSM > SOURCE server states was replicated is the same as what the TSM TARGET server > states. > > > > We don't have replicated info on our Target server either. I'm > thinking only the source would store it and the Target server sees it > as just data and not 'replicated' data once stored in the pools. > > > > Can you verify doing 'FI' queries on both target and source. (the > capacity & percent utilization should be the same on both servers, > no?) > > Also maybe open a TSM gui or command line on one of the replicated > servers and see what's there to restore. > > > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Rick Adamson > Sent: Friday, July 22, 2016 8:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM Replication > > > > > > ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / > attachments. Never supply UserID/PASSWORD information. > > > > > > Ricky, > > I know that on the source server there is a field (BKBYTES_REPLICATED) > in the REPLCIATIONVIEW table. I have used it to query the amount of > replicated data. > > Perhaps someone can chime in from IBM but I did not find this > information maintained on the target server; if fact I receive an > error when attempting to query the REPLCIATIONVIEW or REPLTASK tables on it. > > > > On another note I'm not sure it is necessary; when the "replicate" > task starts the source server initiates sessions with the target > server and begins sending data. I would think that there is some type > of integrity check and acknowledgement performed by the target server > and sent back to the source server, if there's any issues the task > would complete with a failure state. > > But again that's more of a logical assumption, I have to defer to > gurus at IBM for clarification > > > > -Rick Adamson > > > > > > -Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] [mailto:ADSM-L@VM.MARIST.EDU]> On Behalf Of Plair, Ricky > > Sent: Friday, July 22, 2016 7:57 AM > > To: ADSM-L@VM.MARIST.EDU<mailto:ADSM-L@VM.MARIST.EDU> > > Subject: [ADSM-L] TSM Replication > > > > Happy Friday to everyone! > > > > Can some tell me if there is a command, script or another way to find > out the summary of how much data was replicated during the replication > process on the TARGET server? > > > > Once replication has completed, I can go into the logs on the TSM > SOURCE server and find out how many files were deleted, and how much > data was replicated, etc. but, I need to verify that on the TSM > TARGET server as well.
Re: TSM Replication
Thanks! I just did the q repln on the source server. And yes it shows the filespaces and data amount for both source and target. Beats doing the q fi on source and target! But when I do q repln on the target server I get 'no matching servers defined'. I think the original question asked by Rick's Management team was 'is there a query one can do on the TARGET server to confirm what was replicated' -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Karel Bos Sent: Friday, July 22, 2016 2:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Replications between source and target means that that data is being sent from source is being received by target. If the target doesn't confirm receive of data the replication process failes. After replication process had completed one can use the q repln command to check the replication state of any node configured to do replication. It shows how many objects and amount data of the nodes are on source and on the target. Op 22 jul. 2016 17:39 schreef "Jeanne Bruno" <jbr...@cenhud.com>: > Hello. for this: but, I need to verify that on the TSM TARGET server > as well. Management wants to be able to verity that what the TSM > SOURCE server states was replicated is the same as what the TSM TARGET server > states. > > > > We don't have replicated info on our Target server either. I'm > thinking only the source would store it and the Target server sees it > as just data and not 'replicated' data once stored in the pools. > > > > Can you verify doing 'FI' queries on both target and source. (the > capacity & percent utilization should be the same on both servers, > no?) > > Also maybe open a TSM gui or command line on one of the replicated > servers and see what's there to restore. > > > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Rick Adamson > Sent: Friday, July 22, 2016 8:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM Replication > > > > > > ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / > attachments. Never supply UserID/PASSWORD information. > > > > > > Ricky, > > I know that on the source server there is a field (BKBYTES_REPLICATED) > in the REPLCIATIONVIEW table. I have used it to query the amount of > replicated data. > > Perhaps someone can chime in from IBM but I did not find this > information maintained on the target server; if fact I receive an > error when attempting to query the REPLCIATIONVIEW or REPLTASK tables on it. > > > > On another note I'm not sure it is necessary; when the "replicate" > task starts the source server initiates sessions with the target > server and begins sending data. I would think that there is some type > of integrity check and acknowledgement performed by the target server > and sent back to the source server, if there's any issues the task > would complete with a failure state. > > But again that's more of a logical assumption, I have to defer to > gurus at IBM for clarification > > > > -Rick Adamson > > > > > > -Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] [mailto:ADSM-L@VM.MARIST.EDU]> On Behalf Of Plair, Ricky > > Sent: Friday, July 22, 2016 7:57 AM > > To: ADSM-L@VM.MARIST.EDU<mailto:ADSM-L@VM.MARIST.EDU> > > Subject: [ADSM-L] TSM Replication > > > > Happy Friday to everyone! > > > > Can some tell me if there is a command, script or another way to find > out the summary of how much data was replicated during the replication > process on the TARGET server? > > > > Once replication has completed, I can go into the logs on the TSM > SOURCE server and find out how many files were deleted, and how much > data was replicated, etc. but, I need to verify that on the TSM > TARGET server as well. Management wants to be able to verity that what > the TSM SOURCE server states was replicated is the same as what the > TSM TARGET server states. > > > > Anyway of doing this? > > > > > > I appreciate any help. > > > > > > > > > > Ricky M. Plair > > Storage Engineer > > HealthPlan Services > > Office: 813 289 1000 Ext 2273 > > Mobile: 813 357 9673 > > > > > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ CONFIDENTIALITY NOTICE: This email message, including any > attachments, is f
Re: TSM Replication
Replications between source and target means that that data is being sent from source is being received by target. If the target doesn't confirm receive of data the replication process failes. After replication process had completed one can use the q repln command to check the replication state of any node configured to do replication. It shows how many objects and amount data of the nodes are on source and on the target. Op 22 jul. 2016 17:39 schreef "Jeanne Bruno" <jbr...@cenhud.com>: > Hello. for this: but, I need to verify that on the TSM TARGET server as > well. Management wants to be able to verity that what the TSM SOURCE server > states was replicated is the same as what the TSM TARGET server states. > > > > We don't have replicated info on our Target server either. I'm thinking > only the source would store it and the Target server sees it as just data > and not 'replicated' data once stored in the pools. > > > > Can you verify doing 'FI' queries on both target and source. (the capacity > & percent utilization should be the same on both servers, no?) > > Also maybe open a TSM gui or command line on one of the replicated servers > and see what's there to restore. > > > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Rick Adamson > Sent: Friday, July 22, 2016 8:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM Replication > > > > > > ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / > attachments. Never supply UserID/PASSWORD information. > > > > > > Ricky, > > I know that on the source server there is a field (BKBYTES_REPLICATED) in > the REPLCIATIONVIEW table. I have used it to query the amount of replicated > data. > > Perhaps someone can chime in from IBM but I did not find this information > maintained on the target server; if fact I receive an error when attempting > to query the REPLCIATIONVIEW or REPLTASK tables on it. > > > > On another note I'm not sure it is necessary; when the "replicate" task > starts the source server initiates sessions with the target server and > begins sending data. I would think that there is some type of integrity > check and acknowledgement performed by the target server and sent back to > the source server, if there's any issues the task would complete with a > failure state. > > But again that's more of a logical assumption, I have to defer to gurus at > IBM for clarification > > > > -Rick Adamson > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] [mailto:ADSM-L@VM.MARIST.EDU]> On Behalf Of Plair, Ricky > > Sent: Friday, July 22, 2016 7:57 AM > > To: ADSM-L@VM.MARIST.EDU<mailto:ADSM-L@VM.MARIST.EDU> > > Subject: [ADSM-L] TSM Replication > > > > Happy Friday to everyone! > > > > Can some tell me if there is a command, script or another way to find out > the summary of how much data was replicated during the replication process > on the TARGET server? > > > > Once replication has completed, I can go into the logs on the TSM SOURCE > server and find out how many files were deleted, and how much data was > replicated, etc. but, I need to verify that on the TSM TARGET server > as well. Management wants to be able to verity that what the TSM SOURCE > server states was replicated is the same as what the TSM TARGET server > states. > > > > Anyway of doing this? > > > > > > I appreciate any help. > > > > > > > > > > Ricky M. Plair > > Storage Engineer > > HealthPlan Services > > Office: 813 289 1000 Ext 2273 > > Mobile: 813 357 9673 > > > > > > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ CONFIDENTIALITY NOTICE: This email message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information and/or Protected Health Information (PHI) > subject to protection under the law, including the Health Insurance > Portability and Accountability Act of 1996, as amended (HIPAA). If you are > not the intended recipient or the person responsible for delivering the > email to the intended recipient, be advised that you have received this > email in error and that any use, disclosure, distribution, forwarding, > printing, or copying of this email is strictly prohibited. If you have > received this email in error, please notify the sender immediately and > destroy all copies of the original message. >
Re: TSM Replication
Hello. for this: but, I need to verify that on the TSM TARGET server as well. Management wants to be able to verity that what the TSM SOURCE server states was replicated is the same as what the TSM TARGET server states. We don't have replicated info on our Target server either. I'm thinking only the source would store it and the Target server sees it as just data and not 'replicated' data once stored in the pools. Can you verify doing 'FI' queries on both target and source. (the capacity & percent utilization should be the same on both servers, no?) Also maybe open a TSM gui or command line on one of the replicated servers and see what's there to restore. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick Adamson Sent: Friday, July 22, 2016 8:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Replication ** THIS IS AN EXTERNAL EMAIL ** Use caution before opening links / attachments. Never supply UserID/PASSWORD information. Ricky, I know that on the source server there is a field (BKBYTES_REPLICATED) in the REPLCIATIONVIEW table. I have used it to query the amount of replicated data. Perhaps someone can chime in from IBM but I did not find this information maintained on the target server; if fact I receive an error when attempting to query the REPLCIATIONVIEW or REPLTASK tables on it. On another note I'm not sure it is necessary; when the "replicate" task starts the source server initiates sessions with the target server and begins sending data. I would think that there is some type of integrity check and acknowledgement performed by the target server and sent back to the source server, if there's any issues the task would complete with a failure state. But again that's more of a logical assumption, I have to defer to gurus at IBM for clarification -Rick Adamson -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU]<mailto:[mailto:ADSM-L@VM.MARIST.EDU]> On Behalf Of Plair, Ricky Sent: Friday, July 22, 2016 7:57 AM To: ADSM-L@VM.MARIST.EDU<mailto:ADSM-L@VM.MARIST.EDU> Subject: [ADSM-L] TSM Replication Happy Friday to everyone! Can some tell me if there is a command, script or another way to find out the summary of how much data was replicated during the replication process on the TARGET server? Once replication has completed, I can go into the logs on the TSM SOURCE server and find out how many files were deleted, and how much data was replicated, etc. but, I need to verify that on the TSM TARGET server as well. Management wants to be able to verity that what the TSM SOURCE server states was replicated is the same as what the TSM TARGET server states. Anyway of doing this? I appreciate any help. Ricky M. Plair Storage Engineer HealthPlan Services Office: 813 289 1000 Ext 2273 Mobile: 813 357 9673 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and/or Protected Health Information (PHI) subject to protection under the law, including the Health Insurance Portability and Accountability Act of 1996, as amended (HIPAA). If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, disclosure, distribution, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please notify the sender immediately and destroy all copies of the original message.
Re: TSM Replication
Ricky, I know that on the source server there is a field (BKBYTES_REPLICATED) in the REPLCIATIONVIEW table. I have used it to query the amount of replicated data. Perhaps someone can chime in from IBM but I did not find this information maintained on the target server; if fact I receive an error when attempting to query the REPLCIATIONVIEW or REPLTASK tables on it. On another note I'm not sure it is necessary; when the "replicate" task starts the source server initiates sessions with the target server and begins sending data. I would think that there is some type of integrity check and acknowledgement performed by the target server and sent back to the source server, if there's any issues the task would complete with a failure state. But again that's more of a logical assumption, I have to defer to gurus at IBM for clarification -Rick Adamson -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Plair, Ricky Sent: Friday, July 22, 2016 7:57 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM Replication Happy Friday to everyone! Can some tell me if there is a command, script or another way to find out the summary of how much data was replicated during the replication process on the TARGET server? Once replication has completed, I can go into the logs on the TSM SOURCE server and find out how many files were deleted, and how much data was replicated, etc. but, I need to verify that on the TSM TARGET server as well. Management wants to be able to verity that what the TSM SOURCE server states was replicated is the same as what the TSM TARGET server states. Anyway of doing this? I appreciate any help. Ricky M. Plair Storage Engineer HealthPlan Services Office: 813 289 1000 Ext 2273 Mobile: 813 357 9673 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and/or Protected Health Information (PHI) subject to protection under the law, including the Health Insurance Portability and Accountability Act of 1996, as amended (HIPAA). If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, disclosure, distribution, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please notify the sender immediately and destroy all copies of the original message.
TSM Replication
Happy Friday to everyone! Can some tell me if there is a command, script or another way to find out the summary of how much data was replicated during the replication process on the TARGET server? Once replication has completed, I can go into the logs on the TSM SOURCE server and find out how many files were deleted, and how much data was replicated, etc. but, I need to verify that on the TSM TARGET server as well. Management wants to be able to verity that what the TSM SOURCE server states was replicated is the same as what the TSM TARGET server states. Anyway of doing this? I appreciate any help. Ricky M. Plair Storage Engineer HealthPlan Services Office: 813 289 1000 Ext 2273 Mobile: 813 357 9673 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and/or Protected Health Information (PHI) subject to protection under the law, including the Health Insurance Portability and Accountability Act of 1996, as amended (HIPAA). If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, disclosure, distribution, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error, please notify the sender immediately and destroy all copies of the original message.
TSM Replication 7.1.1 question about environment.
Hi to all I am in phase of running TSM for Replication for my two backup servers, both of them in version 7.1.1 with O.S Windows2008R2 64B E5530 @ 2.40GHz (2 Processors) When I tested it, my replicate server was to a Windows2008R2 64bB with 64GB memory. Now for production I am wondering what will be the correct environment to do it , your input guys who are already doing it will be really appreciate. O.S using ? How many core ? Memory ? etc etc …. Only critical nodes at stage one will be replicate using different policies as version 7.1.1 allow it. T.I.A and best regards Robert
Re: TSM Replication 7.1.1 question about environment.
Can I assume you are using deduplication in combination with replication? What is your expected daily ingest and how much managed data will you have in the TSM server? 64GB CAN be enough for small (1-2TB ingest) with replication to function (not optimal) but for larger environments you quickly need to go higher. Put your DB and active log on SSD's, don't mess around with 15K disks, they work but don't scale well and you will add so many that SSD's are the way to go. You can use near line disks for filepool storage up until around 8TB daily ingest (pre-dedup), above that I would pick 10K disks and a lot of them. Look for the IBM Linux Tivoli Storage Manager blueprint document for some additional sizing information in regards to disk layout, but I would highly recommend using SSD for any TSM server sizing that use dedup (with replication it's really make a huge difference). On Sun, Oct 5, 2014 at 12:04 PM, Robert Ouzen rou...@univ.haifa.ac.il wrote: Hi to all I am in phase of running TSM for Replication for my two backup servers, both of them in version 7.1.1 with O.S Windows2008R2 64B E5530 @ 2.40GHz (2 Processors) When I tested it, my replicate server was to a Windows2008R2 64bB with 64GB memory. Now for production I am wondering what will be the correct environment to do it , your input guys who are already doing it will be really appreciate. O.S using ? How many core ? Memory ? etc etc …. Only critical nodes at stage one will be replicate using different policies as version 7.1.1 allow it. T.I.A and best regards Robert
AW: AW: Tsm replication 7.1
Hallo Robert, to answer the last part of your question: ...So if I have for a node a policy (archive) of keeping 365 days and on the TARGET server I just want to keep 60 days. During the first replicate node which policy works ? All data for 365 days will be replicate or just the data for 60 days ? ... Some Facts: Domains are not replicated. If same domain name exits on Target Replication Server (TRS), it will be used, otherwise the “standard” one will be choosen. Expiration is always handled by the source replication server (SRS). SRS informs TRS to delete an expired Object during replication process. Case 1: backups: Assume you allow 4 versions on SRS and only 2 versions on TRS: Replication will replicate all 4 versions (you can check with q occ and from “backups” table on TRS). “Half-Failover: If you change to the TRS with –forcefailover (or with a DSM optfile pointing to TRS (same result)) , you can restore all 4 versions from TRS. “Full-Failover”: Now, you do a “remove replnode node” on TRS : replication is removed (replstate=none and replmode=none) You still !! can restore 4 versions on TRS: Only if you do a new BACKUP (which now is possible), a “rebinding” will be done, forcing the policies of the TRS to become effective (2 versions only). Case 2: archives: As long as the SRS is the owner, you will have RETVER=365 for all replications. But if you change ownership of your node on TRS (remove replnode node), than RETVER=60 days will become the effective value for your archives. The next “expire inventory” will expire and delete all archive objects older than 60 days. Some background for archives: Archives are never rebound (in terms of active/inactive objects), because we have no versioning. Archive copies remain bound to the MANAGEMENT CLASS specified, when you archive them (only if the MG does not exist anymore or the archive CP is deleted it will be rebinded to the default MG (or the grace period if the default MG is not available). Attention: pls check also the retention for your archive directories (may be you are using also ARCHMC=) So the final message is:keep SRS and TRS policies the SAME for a node to replicated!. rgds Michael michael.mal...@tsmpoweradmin.com -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Robert Ouzen Gesendet: Donnerstag, 1. Mai 2014 07:35 An: ADSM-L@VM.MARIST.EDU Betreff: Re: AW: Tsm replication 7.1 Hi Michael Thank you very much for the information . make more sense now. Your link is very helpful too .. I have just need another clarification about the policy retention , if they are not the same in SOURCE and TARGET servers . I mean that I want to keep in TARGET server less versions (type backup) or last days (type archive). To make simple in source F.S (default) - Node (default) - server (ALL_DATA) So if I have for a node a policy (archive) of keeping 365 days and on the TARGET server I just want to keep 60 days. During the first replicate node which policy works ? All data for 365 days will be replicate or just the data for 60 days ? T.I.A Best Regards Robert Ouzen Haifa University Israel -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, April 30, 2014 3:49 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: Tsm replication 7.1 Hallo Robert, interesting questions: As I'm currently documenting and testing as well the node replication feature (see http://www.mm-it.at/de/TSM_Node_Replication_CMDs_Options_at_a_glance.html) I try to share my current knowledge: Domain Change on Target Replication Server: If you move a node to a different domain on the target, replication will move it back Means, that if I change a domain for the node on the target replication server AFTER a successful replication and then try another replication to the same node , the domain for the node on the target server changed back (without a message!!!) to the original one. replstate=purgedata E.g. if you do: de fi node-name * replstate=purgedata datatype=backup, then: è Backup rule data is then set to state Purge Data:à see q fi node * f=d è During next replication the objects will be deleted on the target server (see message during replication) and è The replstate for the filespace will be set to disabled You can see the status of the deleted objects later on with q replicaton node-name processed=xx f=d What remains to be clarified for me: also with update node you have the undocumented option of purgedata for the replstate, but I can not see any purge data status è My be TSM development can clarify - thanks Expiration: The Source server instructs target to delete objects during replication rgds Michael michael.mal...@tsmpoweradmin.com -Ursprüngliche Nachricht
Re: AW: AW: Tsm replication 7.1
From EDGE: Different retention on source vs target server is planned for a future release. (with all due disclaimers about how nothing is guaranteed for future releases...) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of michael.mal...@tsmpoweradmin.com Sent: Monday, May 19, 2014 1:33 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: AW: Tsm replication 7.1 Hallo Robert, to answer the last part of your question: ...So if I have for a node a policy (archive) of keeping 365 days and on the TARGET server I just want to keep 60 days. During the first replicate node which policy works ? All data for 365 days will be replicate or just the data for 60 days ? ... Some Facts: Domains are not replicated. If same domain name exits on Target Replication Server (TRS), it will be used, otherwise the “standard” one will be choosen. Expiration is always handled by the source replication server (SRS). SRS informs TRS to delete an expired Object during replication process. Case 1: backups: Assume you allow 4 versions on SRS and only 2 versions on TRS: Replication will replicate all 4 versions (you can check with q occ and from “backups” table on TRS). “Half-Failover: If you change to the TRS with –forcefailover (or with a DSM optfile pointing to TRS (same result)) , you can restore all 4 versions from TRS. “Full-Failover”: Now, you do a “remove replnode node” on TRS : replication is removed (replstate=none and replmode=none) You still !! can restore 4 versions on TRS: Only if you do a new BACKUP (which now is possible), a “rebinding” will be done, forcing the policies of the TRS to become effective (2 versions only). Case 2: archives: As long as the SRS is the owner, you will have RETVER=365 for all replications. But if you change ownership of your node on TRS (remove replnode node), than RETVER=60 days will become the effective value for your archives. The next “expire inventory” will expire and delete all archive objects older than 60 days. Some background for archives: Archives are never rebound (in terms of active/inactive objects), because we have no versioning. Archive copies remain bound to the MANAGEMENT CLASS specified, when you archive them (only if the MG does not exist anymore or the archive CP is deleted it will be rebinded to the default MG (or the grace period if the default MG is not available). Attention: pls check also the retention for your archive directories (may be you are using also ARCHMC=) So the final message is:keep SRS and TRS policies the SAME for a node to replicated!. rgds Michael michael.mal...@tsmpoweradmin.com -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Robert Ouzen Gesendet: Donnerstag, 1. Mai 2014 07:35 An: ADSM-L@VM.MARIST.EDU Betreff: Re: AW: Tsm replication 7.1 Hi Michael Thank you very much for the information . make more sense now. Your link is very helpful too .. I have just need another clarification about the policy retention , if they are not the same in SOURCE and TARGET servers . I mean that I want to keep in TARGET server less versions (type backup) or last days (type archive). To make simple in source F.S (default) - Node (default) - server (ALL_DATA) So if I have for a node a policy (archive) of keeping 365 days and on the TARGET server I just want to keep 60 days. During the first replicate node which policy works ? All data for 365 days will be replicate or just the data for 60 days ? T.I.A Best Regards Robert Ouzen Haifa University Israel -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, April 30, 2014 3:49 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: Tsm replication 7.1 Hallo Robert, interesting questions: As I'm currently documenting and testing as well the node replication feature (see http://www.mm-it.at/de/TSM_Node_Replication_CMDs_Options_at_a_glance.html) I try to share my current knowledge: Domain Change on Target Replication Server: If you move a node to a different domain on the target, replication will move it back Means, that if I change a domain for the node on the target replication server AFTER a successful replication and then try another replication to the same node , the domain for the node on the target server changed back (without a message!!!) to the original one. replstate=purgedata E.g. if you do: de fi node-name * replstate=purgedata datatype=backup, then: è Backup rule data is then set to state Purge Data:à see q fi node * f=d è During next replication the objects will be deleted on the target server (see message during replication) and è The replstate for the filespace will be set to disabled You can see the status of the deleted objects later on with q replicaton node-name
Tsm replication 7.1
Hi to all Long time ago I test the replication feature for DRM purpose. Now I wanted to implant it between two TSM servers version 7.1 and O.S Windows 2008 R2 64B. I have some questions: · The command replicate node if no domain exist in the TARGET server as in SOURCE server , put the node under the domain STANDARD. My question is after it can I update the node to a different domain (created on the TARGET server but in the SOURCE server is not exist) , and in the next replicate node it will go to this domain and not to STANDARD ? · In SOURCE server in the command update fi it is an option replstate=purgedata I don't quite understand the purpose ? · When replicate node with type ARCH have in ARREPLRULEDEFAULT the options : ALL_DATA , ALL_DATA_HIGH_PRIORITY , DEFAULT , NONE . I am using ALL_DATA If I have a node in the SOURCE server with archive copygroups rentention of 360 days and in the TARGET server in the archive coypgroups retention of the domain STANDARD is 90. My question what happen in the replicate node to the TARGET server when no same archive copygroups retention ? Did all data will be replicate and only after running an expire inventory in the TARGET server only the data for 90 days will remain ? or already during the replicate node only the data for 90 days with will replicate ? T.I.A Best Regards Robert
AW: Tsm replication 7.1
Hallo Robert, interesting questions: As I'm currently documenting and testing as well the node replication feature (see http://www.mm-it.at/de/TSM_Node_Replication_CMDs_Options_at_a_glance.html) I try to share my current knowledge: Domain Change on Target Replication Server: If you move a node to a different domain on the target, replication will move it back Means, that if I change a domain for the node on the target replication server AFTER a successful replication and then try another replication to the same node , the domain for the node on the target server changed back (without a message!!!) to the original one. replstate=purgedata E.g. if you do: de fi node-name * replstate=purgedata datatype=backup, then: è Backup rule data is then set to state Purge Data:à see q fi node * f=d è During next replication the objects will be deleted on the target server (see message during replication) and è The replstate for the filespace will be set to disabled You can see the status of the deleted objects later on with q replicaton node-name processed=xx f=d What remains to be clarified for me: also with update node you have the undocumented option of purgedata for the replstate, but I can not see any purge data status è My be TSM development can clarify - thanks Expiration: The Source server instructs target to delete objects during replication rgds Michael michael.mal...@tsmpoweradmin.com -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Robert Ouzen Gesendet: Mittwoch, 30. April 2014 11:53 An: ADSM-L@VM.MARIST.EDU Betreff: Tsm replication 7.1 Hi to all Long time ago I test the replication feature for DRM purpose. Now I wanted to implant it between two TSM servers version 7.1 and O.S Windows 2008 R2 64B. I have some questions: · The command replicate node if no domain exist in the TARGET server as in SOURCE server , put the node under the domain STANDARD. My question is after it can I update the node to a different domain (created on the TARGET server but in the SOURCE server is not exist) , and in the next replicate node it will go to this domain and not to STANDARD ? · In SOURCE server in the command update fi it is an option replstate=purgedata I don't quite understand the purpose ? · When replicate node with type ARCH have in ARREPLRULEDEFAULT the options : ALL_DATA , ALL_DATA_HIGH_PRIORITY , DEFAULT , NONE . I am using ALL_DATA If I have a node in the SOURCE server with archive copygroups rentention of 360 days and in the TARGET server in the archive coypgroups retention of the domain STANDARD is 90. My question what happen in the replicate node to the TARGET server when no same archive copygroups retention ? Did all data will be replicate and only after running an expire inventory in the TARGET server only the data for 90 days will remain ? or already during the replicate node only the data for 90 days with will replicate ? T.I.A Best Regards Robert
Re: AW: Tsm replication 7.1
Hi Michael Thank you very much for the information . make more sense now. Your link is very helpful too .. I have just need another clarification about the policy retention , if they are not the same in SOURCE and TARGET servers . I mean that I want to keep in TARGET server less versions (type backup) or last days (type archive). To make simple in source F.S (default) - Node (default) - server (ALL_DATA) So if I have for a node a policy (archive) of keeping 365 days and on the TARGET server I just want to keep 60 days. During the first replicate node which policy works ? All data for 365 days will be replicate or just the data for 60 days ? T.I.A Best Regards Robert Ouzen Haifa University Israel -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Michael malitz Sent: Wednesday, April 30, 2014 3:49 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] AW: Tsm replication 7.1 Hallo Robert, interesting questions: As I'm currently documenting and testing as well the node replication feature (see http://www.mm-it.at/de/TSM_Node_Replication_CMDs_Options_at_a_glance.html) I try to share my current knowledge: Domain Change on Target Replication Server: If you move a node to a different domain on the target, replication will move it back Means, that if I change a domain for the node on the target replication server AFTER a successful replication and then try another replication to the same node , the domain for the node on the target server changed back (without a message!!!) to the original one. replstate=purgedata E.g. if you do: de fi node-name * replstate=purgedata datatype=backup, then: è Backup rule data is then set to state Purge Data:à see q fi node * f=d è During next replication the objects will be deleted on the target server (see message during replication) and è The replstate for the filespace will be set to disabled You can see the status of the deleted objects later on with q replicaton node-name processed=xx f=d What remains to be clarified for me: also with update node you have the undocumented option of purgedata for the replstate, but I can not see any purge data status è My be TSM development can clarify - thanks Expiration: The Source server instructs target to delete objects during replication rgds Michael michael.mal...@tsmpoweradmin.com -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Robert Ouzen Gesendet: Mittwoch, 30. April 2014 11:53 An: ADSM-L@VM.MARIST.EDU Betreff: Tsm replication 7.1 Hi to all Long time ago I test the replication feature for DRM purpose. Now I wanted to implant it between two TSM servers version 7.1 and O.S Windows 2008 R2 64B. I have some questions: · The command replicate node if no domain exist in the TARGET server as in SOURCE server , put the node under the domain STANDARD. My question is after it can I update the node to a different domain (created on the TARGET server but in the SOURCE server is not exist) , and in the next replicate node it will go to this domain and not to STANDARD ? · In SOURCE server in the command update fi it is an option replstate=purgedata I don't quite understand the purpose ? · When replicate node with type ARCH have in ARREPLRULEDEFAULT the options : ALL_DATA , ALL_DATA_HIGH_PRIORITY , DEFAULT , NONE . I am using ALL_DATA If I have a node in the SOURCE server with archive copygroups rentention of 360 days and in the TARGET server in the archive coypgroups retention of the domain STANDARD is 90. My question what happen in the replicate node to the TARGET server when no same archive copygroups retention ? Did all data will be replicate and only after running an expire inventory in the TARGET server only the data for 90 days will remain ? or already during the replicate node only the data for 90 days with will replicate ? T.I.A Best Regards Robert
TSM replication error ANR1181E and ANR0532W
Getting errors with TSM replication only for 1 node, anyone seen this 07/21/2012 10:43:57 ANR0511I Session 9407 opened output volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:17 ANR1181E sstxn.c(507): Data storage transaction 0:656419 was aborted. (SESSION: 9407) 07/21/2012 10:44:17 ANR0532W smrepl.c(869): Transaction 0:656419 was aborted for session 9407 for node OFFICE3 (Windows). (SESSION: 9407) 07/21/2012 10:44:17 ANR0514I Session 9407 closed volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:18 ANR8340I FILE volume D:\OFFICE_PRIM2\07CC.BFS mounted. (SESSION: 9407) Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
SV: TSM replication error ANR1181E and ANR0532W
Hi Tim, Try to run a audit on the volume and see if it is OK. /Christian Från: Tim Brown [tbr...@cenhud.com] Skickat: den 23 juli 2012 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: TSM replication error ANR1181E and ANR0532W Getting errors with TSM replication only for 1 node, anyone seen this 07/21/2012 10:43:57 ANR0511I Session 9407 opened output volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:17 ANR1181E sstxn.c(507): Data storage transaction 0:656419 was aborted. (SESSION: 9407) 07/21/2012 10:44:17 ANR0532W smrepl.c(869): Transaction 0:656419 was aborted for session 9407 for node OFFICE3 (Windows). (SESSION: 9407) 07/21/2012 10:44:17 ANR0514I Session 9407 closed volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:18 ANR8340I FILE volume D:\OFFICE_PRIM2\07CC.BFS mounted. (SESSION: 9407) Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
Re: TSM replication error ANR1181E and ANR0532W
Ran audit. Appears to be ok, Would a movedata off of this volume help Its also set to readwrite/filling, could mark r/o to see if replicate Completes using new volume. Thanks, Tim -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Christian Svensson Sent: Monday, 23 July, 2012 10:10 AM To: ADSM-L@VM.MARIST.EDU Subject: SV: TSM replication error ANR1181E and ANR0532W Hi Tim, Try to run a audit on the volume and see if it is OK. /Christian Från: Tim Brown [tbr...@cenhud.com] Skickat: den 23 juli 2012 15:22 Till: ADSM-L@VM.MARIST.EDU Ämne: TSM replication error ANR1181E and ANR0532W Getting errors with TSM replication only for 1 node, anyone seen this 07/21/2012 10:43:57 ANR0511I Session 9407 opened output volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:17 ANR1181E sstxn.c(507): Data storage transaction 0:656419 was aborted. (SESSION: 9407) 07/21/2012 10:44:17 ANR0532W smrepl.c(869): Transaction 0:656419 was aborted for session 9407 for node OFFICE3 (Windows). (SESSION: 9407) 07/21/2012 10:44:17 ANR0514I Session 9407 closed volume D:\OFFICE_PRIM2\07CC.BFS. (SESSION: 9407) 07/21/2012 10:44:18 ANR8340I FILE volume D:\OFFICE_PRIM2\07CC.BFS mounted. (SESSION: 9407) Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
Re: tsm replication leaves orphaned sessions on target replicatiopn server
Hi Tim, Yeap, same thing... Do you use node groupe for replication On 19 Jul 2012 00:47, Tim Brown tbr...@cenhud.com wrote: Over time TSM can leave orphaned sessions on the TSM server that is being replicated to. This prevents future replications for those nodes until the sessions are cancelled or the replication destination server is restarted. TSM 6.3.0 on from server TSM 6.3.1 on target server Sometimes the sessions can be cancelled and sometimes they cant. Has anyone seen this issue. Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
Re: tsm replication leaves orphaned sessions on target replicatiopn server
Yes we use nodegroups Sent from my Verizon Wireless Droid -Original message- From: Chavdar Cholev chavdar.cho...@gmail.com To: ADSM-L@VM.MARIST.EDU Sent: Thu, Jul 19, 2012 17:55:24 GMT+00:00 Subject: Re: tsm replication leaves orphaned sessions on target replicatiopn server Hi Tim, Yeap, same thing... Do you use node groupe for replication On 19 Jul 2012 00:47, Tim Brown tbr...@cenhud.com wrote: Over time TSM can leave orphaned sessions on the TSM server that is being replicated to. This prevents future replications for those nodes until the sessions are cancelled or the replication destination server is restarted. TSM 6.3.0 on from server TSM 6.3.1 on target server Sometimes the sessions can be cancelled and sometimes they cant. Has anyone seen this issue. Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
tsm replication leaves orphaned sessions on target replicatiopn server
Over time TSM can leave orphaned sessions on the TSM server that is being replicated to. This prevents future replications for those nodes until the sessions are cancelled or the replication destination server is restarted. TSM 6.3.0 on from server TSM 6.3.1 on target server Sometimes the sessions can be cancelled and sometimes they cant. Has anyone seen this issue. Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: mailto:tbr...@cenhud.com tbr...@cenhud.com mailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments.
Tsm Replication Question
Hi to all A little informative question about Tsm replication. f during the process the nodes in the source server are deduplicate with Data Domain and in the target server the nodes will be deduplicate with Tsm deduplication , It's possible ? Regards Robert
Re: Tsm Replication Question
Hi Robert, This is possible but the replication process won't benefit from deduplication. When replicating, data will be rehydrated by DataDomain, transfered from source to target in native format then deduplicated by TSM server on target side. --Message d'origine-- De: Robert Ouzen Expéditeur : ADSM: Dist Stor Manager À: ADSM-L@VM.MARIST.EDU Répondre à: ADSM: Dist Stor Manager Objet: [ADSM-L] Tsm Replication Question Envoyé: 22 avril 2012 09:49 Hi to all A little informative question about Tsm replication. f during the process the nodes in the source server are deduplicate with Data Domain and in the target server the nodes will be deduplicate with Tsm deduplication , It's possible ? Regards Robert -- Best regards / Cordialement / مع تحياتي Erwann SIMON
Question about Tsm replication on V6.3
Hi I have just test the new feature on TSM server 6.3 Tsm Replication on my test environment , works fine very pleased … A little question when trying to delete the nodename who was replicated on the target server , I always get that ii can't be remove still in replicate status I update the node on both side( Source an target) with replstate=disabled I also set replserver with none parameter to reset it on the source server I reset crossdefine off on both side (Source, Target) But still can't remove the node on the target server ! Regards Robert
Antwort: [ADSM-L] Question about Tsm replication on V6.3
you need to use remove replnode xxx on both servers. Regards, Alex Heindl Von:Robert Ouzen rou...@univ.haifa.ac.il An: ADSM-L@VM.MARIST.EDU Datum: 16.04.2012 08:32 Betreff:[ADSM-L] Question about Tsm replication on V6.3 Gesendet von: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Hi I have just test the new feature on TSM server 6.3 Tsm Replication on my test environment , works fine very pleased ? A little question when trying to delete the nodename who was replicated on the target server , I always get that ii can't be remove still in replicate status I update the node on both side( Source an target) with replstate=disabled I also set replserver with none parameter to reset it on the source server I reset crossdefine off on both side (Source, Target) But still can't remove the node on the target server ! Regards Robert smime.p7s Description: S/MIME Cryptographic Signature
