#612 Issue closed: TSM Bug

Labels: enhancement, waiting for info, support / question

tyl0re opened issue at 2015-07-07 10:31:

TSM has a bug when

resour [X] (where x >1)

is set. Hardlinks are not restored corectly

When it is 2, TSM has 2 threads, each thread makes it own hardlinks. So 1 file with 10 Hardlinks gets 2 files with 5 hardlinks. It could only be resolved by changing or setting "resour 1" in the dsm.sys
Maybe Rear should set it so it is done correctly

schlomo commented at 2015-07-07 10:56:

(fixed the markdown so that the main part is not swallowed by GitHub Flavoured Markdown).

Can you say why this bug only affects ReaR? ReaR actually does not do TSM backups (except of the ReaR result files), so I would expect this bug to hit the regular TSM usage as well.

I would be very careful to have ReaR modify the users TSM configuration. An exception could be made for modifying it after it is copied to the ReaR rescue system.

tyl0re commented at 2015-07-08 07:32:

Zitat von Schlomo Schapiro notifications@github.com:

(fixed the markdown so that the main part is not swallowed by GitHub
Flavoured Markdown).

Can you say why this bug only affects ReaR? ReaR actually does not do
TSM backups (except of the ReaR result files), so I would expect this
bug to hit the regular TSM usage as well.

I would be very careful to have ReaR modify the users TSM
configuration. An exception could be made for modifying it after it is
copied to the ReaR rescue system.

—
Reply to this email directly or view it on GitHub[1].

When we have user TSM we used RESOUR=2 for more speed on Backup. On a
restore of Hardlink you have to set RESOUR=1. Since Rear Restores a
Complete Server Resour=1 should be always be set.
Its a "Feature" (Bug) Of TSM, that restores with RESOUR grater 1 doenst
work with hardlinks , we had to learn the hard have learnd the hard way. If
Someone dosnt know of this "Feature". he will restore the Server, and most
likely , dont notice that he has lost his hardlinks.

[1] https://github.com/rear/rear/issues/612#issuecomment-119168459

schlomo commented at 2015-07-08 08:27:

Good argument. I would go with ReaR changing the setting in the rescue
image. To make sure that we don't hurt anybody I would suggest the
following:

  1. You inform/ask on the mailing list (more people read the list than check
    the Github issues) about this topic and see if anybody objects (and why)
  2. The code that copies the TSM client and config will patch the config in
    the rescue system and emit a warning or at least info about what it is
    doing so that users can see in the log what happens

Will you do that and send us a pull request?

Thanks for your help in making ReaR better,
Schlomo

On 8 July 2015 at 09:32, tyl0re notifications@github.com wrote:

Zitat von Schlomo Schapiro notifications@github.com:

(fixed the markdown so that the main part is not swallowed by GitHub
Flavoured Markdown).

Can you say why this bug only affects ReaR? ReaR actually does not do
TSM backups (except of the ReaR result files), so I would expect this
bug to hit the regular TSM usage as well.

I would be very careful to have ReaR modify the users TSM
configuration. An exception could be made for modifying it after it is
copied to the ReaR rescue system.

—
Reply to this email directly or view it on GitHub[1].

When we have user TSM we used RESOUR=2 for more speed on Backup. On a
restore of Hardlink you have to set RESOUR=1. Since Rear Restores a
Complete Server Resour=1 should be always be set.
Its a "Feature" (Bug) Of TSM, that restores with RESOUR grater 1 doenst
work with hardlinks , we had to learn the hard have learnd the hard way. If
Someone dosnt know of this "Feature". he will restore the Server, and most
likely , dont notice that he has lost his hardlinks.

[1] https://github.com/rear/rear/issues/612#issuecomment-119168459

—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/612#issuecomment-119469196.

tyl0re commented at 2015-07-08 08:43:

Zitat von Schlomo Schapiro notifications@github.com:

Good argument. I would go with ReaR changing the setting in the rescue
image. To make sure that we don't hurt anybody I would suggest the
following:

  1. You inform/ask on the mailing list (more people read the list than
    check
    the Github issues) about this topic and see if anybody objects (and why)
  2. The code that copies the TSM client and config will patch the config
    in
    the rescue system and emit a warning or at least info about what it is
    doing so that users can see in the log what happens

Will you do that and send us a pull request?

Since we changed to Comvault, i have not test system in the moment, to test
it. Ill just rememberd that this was on the TSM checklist , so i thought
maby a good idea to let you know.

Out Managemnt has decided to USE Onetouch and Comvault. So rear gets
obsolated here. I use it for my PC at home, but there i dont have TSM

schlomo commented at 2015-07-08 08:52:

Hi,

thanks for letting us know. Do you mean 1-Touch Recovery like shown in
http://documentation.commvault.com/commvault/v10/article?p=products/1touch_linux/recover.htm
?

Very interesting read. First time that I see YaST outside of SUSE Linux.
They also seem to have solved the problems that we also worked on, like
mapping storage between old and new system. And Multipath support (does
theirs work well?).

Do you happen to have a feature comparison between 1-Touch and ReaR?

Let's keep this bug open as a reminder for this issue - after all this is
pretty deep TSM knowledge you share here.

Could I still ask you to write to the mailing list with a pointer to this
issue so that the other TSM user will be aware of it?

Kind Regards,
Schlomo

On 8 July 2015 at 10:43, tyl0re notifications@github.com wrote:

Zitat von Schlomo Schapiro notifications@github.com:

Good argument. I would go with ReaR changing the setting in the rescue
image. To make sure that we don't hurt anybody I would suggest the
following:

  1. You inform/ask on the mailing list (more people read the list than
    check
    the Github issues) about this topic and see if anybody objects (and why)
  2. The code that copies the TSM client and config will patch the config
    in
    the rescue system and emit a warning or at least info about what it is
    doing so that users can see in the log what happens

Will you do that and send us a pull request?

Since we changed to Comvault, i have not test system in the moment, to test
it. Ill just rememberd that this was on the TSM checklist , so i thought
maby a good idea to let you know.

Out Managemnt has decided to USE Onetouch and Comvault. So rear gets
obsolated here. I use it for my PC at home, but there i dont have TSM

—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/612#issuecomment-119500840.

tyl0re commented at 2015-07-08 09:06:

Zitat von Schlomo Schapiro notifications@github.com:

Very interesting read. First time that I see YaST outside of SUSE Linux.
They also seem to have solved the problems that we also worked on, like
mapping storage between old and new system. And Multipath support (does
theirs work well?).

Most of the Linux Server Are VMs so i couldt test Multipath. It has
worked with Hardware Server with default Hardware. It works on AIX,
and Windows es well. Solaris still has to be tested.

Their Boot CD seems to restore the rescue System, and then boot the
Rescue System within the Booted system.

There have been one Problem. On one Sevrer we used Bonding device.
Since the Bootcd doenst support Boning, bonding must be removed for
restoring it.

Do you happen to have a feature comparison between 1-Touch and ReaR?

No, the main reason was "Onethouch is from Comvault they support it".
SO when there will be the Next Version Onetouch will work. I
Personally prefer Rear, its much easier, and since it Bash its easy to
extend it.

Could I still ask you to write to the mailing list with a pointer to this
issue so that the other TSM user will be aware of it?

Ill will do it

schlomo commented at 2015-07-08 09:09:

Thanks. BTW, ReaR handles bonding automatically :-)

On 8 July 2015 at 11:06, tyl0re notifications@github.com wrote:

Zitat von Schlomo Schapiro notifications@github.com:

Very interesting read. First time that I see YaST outside of SUSE Linux.
They also seem to have solved the problems that we also worked on, like
mapping storage between old and new system. And Multipath support (does
theirs work well?).

Most of the Linux Server Are VMs so i couldt test Multipath. It has
worked with Hardware Server with default Hardware. It works on AIX,
and Windows es well. Solaris still has to be tested.

Their Boot CD seems to restore the rescue System, and then boot the
Rescue System within the Booted system.

There have been one Problem. On one Sevrer we used Bonding device.
Since the Bootcd doenst support Boning, bonding must be removed for
restoring it.

Do you happen to have a feature comparison between 1-Touch and ReaR?

No, the main reason was "Onethouch is from Comvault they support it".
SO when there will be the Next Version Onetouch will work. I
Personally prefer Rear, its much easier, and since it Bash its easy to
extend it.

Could I still ask you to write to the mailing list with a pointer to this
issue so that the other TSM user will be aware of it?

Ill will do it

—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/612#issuecomment-119507731.

tyl0re commented at 2015-07-08 09:52:

Zitat von Schlomo Schapiro notifications@github.com:

Thanks. BTW, ReaR handles bonding automatically :-)

:-), i know it sadly hasnt helped to get Rear back :-).

I look forward when we migrade SAP HANA to Comvault. Rear Has worked, sort
of
It is "GPFS", Special Storage Controler,....   . I cant imagine onetouch
is working.

Rear works when restoring only the OS, Booting, Seting up the Filesystem,
THen Restoring the Data

Another Problem , wasnt aware with TSM Settings
You can Set TSM to change the Client Password Every Day, for security
Reasons.
When doing so every day the file /etc/adsm/TSM.PWD is changed.

Rear Checks by default every day for Changes :

30 1 * * * root /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue

So it will generate an new CD every day. Since i dont Overwrite the Image
(upload is done by web via php Script that puts a
timestamp to the iso) My Fileserver got Filled up.

gdha commented at 2015-07-08 11:49:

About 1-Touch Recovery :
http://documentation.commvault.com/commvault/v10/article?p=products/1touch_linux/setup.htm
Very interesting, but too complicated for simple people - it is not easy to
use in a stressed situation like a real DR... And there examples are VMs,
so, what about UEFI physical Gen9 systems?

On Wed, Jul 8, 2015 at 10:52 AM, Schlomo Schapiro notifications@github.com
wrote:

Hi,

thanks for letting us know. Do you mean 1-Touch Recovery like shown in

http://documentation.commvault.com/commvault/v10/article?p=products/1touch_linux/recover.htm
?

Very interesting read. First time that I see YaST outside of SUSE Linux.
They also seem to have solved the problems that we also worked on, like
mapping storage between old and new system. And Multipath support (does
theirs work well?).

gdha commented at 2015-08-06 12:33:

@tyl0re How would you propose the fix for the recover mode with TSM? We do not have a TSM environment to experiment with...

tyl0re commented at 2015-08-06 13:24:

cat /opt/tivoli/tsm/client/ba/bin/dsm.sys|egrep -v "^[\t[:space:]]_resour"|sed "s/^[\t[:space:]]_Servername(.*)/Servername\1\n resour 1/I" > dsm.sys.new
Denke das sollte gehen und dan die neue dsm.sys.new nehmen

gdha commented at 2016-02-09 13:41:

So far on-one else complained - will not implement this suggestion until we a report which states this is correct or not...
We close it for now -re-open if necessary.

[Export of Github issue for rear/rear.]