#3554 Issue open: TSM: support for a different dsmc optfile via 'dsmc ... -optfile=$TSM_DSMC_OPTFILE'¶
Labels: enhancement, waiting for info, external tool
dcabro opened issue at 2026-01-14 13:08:¶
Requesting support or just a question¶
Non-default opt file or different stanza in dsm.sys - how?
Platform¶
Linux PPC64LE
Output¶
Additional information¶
I don't see any options in TSM stuff that shows how a different .opt file can be used with dsmc when destination is TSM? My main dsm.opt and first stanza in dsm.sys is reserved for application based backup (primary backup with TSM). I'm trying to add a second backup that will backup OS to TSM but can't seem to find the right directive to call this second opt file or different stanza in dsm.sys
Thanks!
jsmeix commented at 2026-01-14 13:42:¶
@dcabro
FYI
first and foremost my "boilerplate"
regarding third-party backup tools:
In general regarding issues with third-party backup tools:
Usually we at ReaR upstream do not have or use
third-party backup tools (in particular not if
a third-party backup tool is proprietary software)
so usually we cannot reproduce issues with
third-party backup tools.
In case of issues with third-party backup tools and ReaR
we at ReaR upstream can usually do nothing but totally
depend on contributions and help from those specific users
who use and know about each specific third-party backup tool.
In general regarding support for third-party backup tools:
See the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
Therein in particular (excerpt):
Usually only basic support for the various backup tools
is implemented in ReaR (e.g. plain making a backup during
"rear mkbackup" and plain restore during "rear recover").
It is very different to what extent support for each
individual backup tool is implemented in ReaR because
support for each individual backup tool is implemented
separated from each other.
Therefore for some particular backup tools the current
support in ReaR could be even only "very basic"
...
In particular for most third party backup tools there is
only support for plain backup restore during "rear recover"
but no support at all to make a backup during "rear mkbackup"
so "rear mkbackup" is useless and only "rear mkrescue" is useful
for most third party backup tools ("rear mkbackup" creates
the ReaR recovery system and makes a backup while
"rear mkrescue" only creates the ReaR recovery system)
In particular regarding backup with TSM:
Normally the backup with TSM should not be done with ReaR
i.e. normally the backup with TSM should not be done via
"rear mkbackup".
Normally the backup with TSM should be done outside
of ReaR directly with TSM and with ReaR only a
ReaR recovery system is made with "rear mkrescue"
where the TSM the restore tool and all what it needs to run
is included to be able to restore a TSM backup during
"rear recover".
Nevertheless since ReaR version 2.4 there is basic support
in ReaR to make a backup with TSM via "rear mkbackup", cf.
https://github.com/rear/rear/pull/1348
where
https://github.com/rear/rear/pull/1348/files
shows that "backup with TSM" functionality
is implemented in those two files:
backup/TSM/default/400_create_include_exclude_files.sh
(a link to
backup/NETFS/default/400_create_include_exclude_files.sh)
and the actual code in
backup/TSM/default/500_make_TSM_backup.sh
This does not provide the same functionality
as when you call TSM directly to make a backup.
jsmeix commented at 2026-01-14 14:47:¶
I did a critical copy&paste typo correction above:
What was wrong before
Normally the backup with TSM should not be done outside
of ReaR directly with TSM
is now corrected:
Normally the backup with TSM should be done outside
of ReaR directly with TSM
dcabro commented at 2026-01-14 14:54:¶
Thank you @jsmeix - it was an easy fix once you pointed me to the code that calls dsmc/TSM. Just one additional variable in 500_make_TSM_backup.sh that calls my configuration file and voilà!
Thanks again!
jsmeix commented at 2026-01-14 15:06:¶
@dcabro
after I (as a ReaR upstream member)
provided you info so you could enhance ReaR
to make it work for your specific use case,
would you mind to provide us
(i.e. the ReaR upstream people who "totally depend on
contributions and help from those specific users who use
and know about each specific third-party backup tool")
your specific enhancement
so that we could perhaps add that
as a generic enhancement to ReaR
so that all TSM users might benefit
from your enhancement?
dcabro commented at 2026-01-14 15:11:¶
I would, of course, but it does not seem to be working as I thought. I can see that initial (TSM verification?) part works fine and it uses different config, but the actual backup where it calls "dsmc incremental" does not.
I have understood that 500_make_TSM_backup.sh is the code that sends data to TSM? Is there any other script?
dcabro commented at 2026-01-14 15:27:¶
Found it. I'll send the update in a while.
jsmeix commented at 2026-01-14 15:34:¶
What I did to see which TSM specific scripts are called is:
I set BACKUP=TSM in my etc/rear/local.conf
(regardless that I don't have any TSM software)
and then I called
# usr/sbin/rear -s mkbackup | grep TSM
Source prep/TSM/default/400_prep_tsm.sh
Source layout/save/TSM/default/400_check_tsm_configuration.sh
Source output/TSM/default/950_dsmc_save_result_files.sh
Source output/TSM/default/960_dsmc_verify_isofile.sh
Source backup/TSM/default/400_create_include_exclude_files.sh
Source backup/TSM/default/500_make_TSM_backup.sh
The -s option triggers "simulation mode"
which shows what scripts are run without executing them
(so without executing them it does not fail for me
because I don't have any TSM software).
Those listed scripts are the "initial suspects"
regarding TSM specific code in ReaR.
For more detailed analysis regarding TSM specific code in ReaR
you may check where TSM specific variables are used,
for example something like
# find usr/share/rear/ -type f | xargs grep 'TSM_DSMC_RESTORE_OPTIONS'
or where dsmc appears like
# find usr/share/rear/ -type f | xargs grep 'dsmc'
and so on as needed.
dcabro commented at 2026-01-14 16:07:¶
To be able to complete rear mkrescue I ended up making changes in:
backup/TSM/default/500_make_TSM_backup.sh
output/TSM/default/950_dsmc_save_result_files.sh
mkbackup might and will probably need additional files changed.
Basically, anywhere where we have:
dsmc incremental
should be changed to:
dsmc incremental -optfile=$optfile
At the same time, at the top, we need to define where that config file is:
# local adjustment for second stanza - custom optfile
optfile=/opt/tivoli/tsm/client/ba/bin/my.opt
That different config file is quite common with TSM (they call it Storage Protect today) so I kind of hoped it would be available as standard configuration option in rear, that's why I asked in the first place (since there are some more advanced options like include/exclude etc.)
Should you need any more testing with TSM or any further improvements are added and need to be tested, I'd be glad to help!
Thank you again!
jsmeix commented at 2026-01-14 16:24:¶
@dcabro
thank you for your information what needs to be changed.
I will try to implement that as a generic enhancement
(as soon as possible but as far as time permits)
and then you could test if my implementation works for you.
I will inform you when I have something to be tested
together with information how you could test it.
jsmeix commented at 2026-01-15 12:21:¶
@dcabro
via
https://github.com/rear/rear/pull/3555
I implemented something as far as I understood
https://github.com/rear/rear/issues/3554#issuecomment-3750308243
in my jsmeix-TSM_dsmc_optfile branch here at Github
https://github.com/rear/rear/tree/jsmeix-TSM_dsmc_optfile
See
https://github.com/rear/rear/pull/3555/files
what I implemented
To test it basically follow the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
In contrast to what is described therein
you need additionally to 'git checkout'
my jsmeix-TSM_dsmc_optfile branch as follows:
git clone https://github.com/rear/rear.git
mv rear rear.github.master
cd rear.github.master
git checkout -b jsmeix-TSM_dsmc_optfile remotes/origin/jsmeix-TSM_dsmc_optfile
vi etc/rear/local.conf
usr/sbin/rear -D mkrescue
usr/sbin/rear -D mkbackup
In the 'vi etc/rear/local.conf' step you need to set
the new config variable TSM_DSMC_OPTFILE as you need it.
Specify the full path of your dsmc optfile like
TSM_DSMC_OPTFILE="/opt/tivoli/tsm/client/ba/bin/my.opt"
dcabro commented at 2026-01-15 12:47:¶
both mkrescue and mkbackup are working fine, it's using what's defined in TSM_DSMC_OPTFILE
jsmeix commented at 2026-01-16 10:53:¶
@dcabro
thank you for testing that "rear mkrescue" and
"rear mkbackup" are working with TSM_DSMC_OPTFILE.
Now the more difficult part begins which is testing
that also "rear recover" works with TSM_DSMC_OPTFILE.
To test "rear recover" you need a well separated
test system ideally on separated test hardware
with separated disks where it does not matter when
"rear recover" tests totally fail (e.g. by randomly
overwriting arbitrary accessible disks), see also
https://en.opensuse.org/SDB:Disaster_Recovery
As far as I currently see what could fail
for "rear recover" with TSM_DSMC_OPTFILE is:
Perhaps in restore/TSM/default/400_restore_with_tsm.sh
'dsmc' must be also called with '-optfile=$TSM_DSMC_OPTFILE'?
I don't know how 'dsmc restore' in that script behaves.
When it needs '-optfile=$TSM_DSMC_OPTFILE' then the file
which is specified by TSM_DSMC_OPTFILE must exist
within the running ReaR recovery system.
For example with
TSM_DSMC_OPTFILE="/opt/tivoli/tsm/client/ba/bin/my.opt"
the file /opt/tivoli/tsm/client/ba/bin/my.opt should exist
within the running ReaR recovery system because
in conf/default.conf there is
COPY_AS_IS_TSM=( ...
/opt/tivoli/tsm/client
... )
so in particular all below /opt/tivoli/tsm/client
gets included in the ReaR recovery system, cf.
the COPY_AS_IS description in conf/default.conf
But for example with
TSM_DSMC_OPTFILE="/special/path/to/somewhere/my.opt"
the file /special/path/to/somewhere/my.opt will usually
not get included in the ReaR recovery system and then
'dsmc -optfile=$TSM_DSMC_OPTFILE' cannot work therein.
This can be manually fixed via
COPY_AS_IS+=( /special/path/to/somewhere/my.opt )
but an automatism in ReaR for this case would be better.
jsmeix commented at 2026-01-16 10:59:¶
Also during "rear recover" 'dsmc' is called in
verify/TSM/default/389_check_TSM_connection.sh
dsmc query session
and in
verify/TSM/default/400_verify_tsm.s
dsmc query filespace ...
where those 'dsmc' commands may also have to be
called with '-optfile=$TSM_DSMC_OPTFILE'?
dcabro commented at 2026-01-16 14:47:¶
If one wants to use $TSM_DSMC_OPTFILE then it should be applied to all iterations of dsmc, irrelevant of the command being invoked (incremental, restore, query etc.).
Default and usual location is /opt/tivoli/tsm/client/ba/bin but it can be anywhere on the filesystem.
Since my initial tests were done on a VMware VM - I can easily clone it and test the restore options, just let me know when to git clone.
Thanks!
jsmeix commented at 2026-01-19 08:56:¶
@dcabro
thank you for the important information that $TSM_DSMC_OPTFILE
should be applied to all calls of 'dsmc'!
I will soon enhance my current
https://github.com/rear/rear/pull/3555
so that $TSM_DSMC_OPTFILE gets applied to all calls of 'dsmc'.
I will inform you when I have done it and then you could
re-test "rear mkrescue/mkbackup" plus "rear recover".
jsmeix commented at 2026-01-19 15:08:¶
@dcabro
I think I found all 'dsmc' command calls so now
in my https://github.com/rear/rear/pull/3555
all 'dsmc' commands should get called as
dsmc ... -optfile="$TSM_DSMC_OPTFILE" ...
when TSM_DSMC_OPTFILE is specified.
Thank you in advance for testing it.
It is much appreciated!
jsmeix commented at 2026-01-19 15:15:¶
@dcabro
FYI regarding safely testing "rear recover":
When you booted the ReaR recovery system on test hardware
(where "hardware" could be also a virtual machine)
and be logged in as 'root' there, you can (and should)
inspect the disks on that test machine if the disks
actually are those which you expect before you launch
"rear recover" because that will overwrite disks.
jsmeix commented at 2026-01-20 07:37:¶
I further enhanced my
https://github.com/rear/rear/pull/3555
according to my above
https://github.com/rear/rear/issues/3554#issuecomment-3759443902
... for example with
TSM_DSMC_OPTFILE="/special/path/to/somewhere/my.opt"
the file /special/path/to/somewhere/my.opt will usually
not get included in the ReaR recovery system and then
'dsmc -optfile=$TSM_DSMC_OPTFILE' cannot work therein.
This can be manually fixed via
COPY_AS_IS+=( /special/path/to/somewhere/my.opt )
but an automatism in ReaR for this case would be better.
jsmeix commented at 2026-01-20 14:30:¶
@dcabro
you could test if "rear recover" works (as time permits).
Now it should also work with something like
TSM_DSMC_OPTFILE="/non/default/path/to/my.opt"
dcabro commented at 2026-01-22 15:21:¶
mkrescue seems to get stuck at:
Wrote ISO image: /root/downloads/rear/rear/var/lib/rear/output/rear-cabrovm.iso (1.1G)
**Saving result files with TSM** < here
But not sure why. I also can't see any proper connection to TSM. Instead I see something strange, there's an IDLE Wait connection from "Unknown" Client name, which is extremely odd - I have never seen this behavior before. If a node cannot be authenticated against TSM, then there should be no connection visible. But I've never seen it show "Unknown".
My etc/rear/local.conf only contains two config lines:
BACKUP=TSM
TSM_DSMC_OPTFILE="/opt/tivoli/tsm/client/ba/bin/tsm8.opt"
and my dsmc works fine if I call that optfile directly, e.g.:
dsmc q sched -optfile=/opt/tivoli/tsm/client/ba/bin/tsm8.opt
IBM Spectrum Protect
Command Line Backup-Archive Client Interface
Client Version 8, Release 1, Level 15.0
Client date/time: 01/22/26 16:19:05
(c) Copyright by IBM Corporation and other(s) 1990, 2022. All Rights Reserved.
**Node Name: CABROVM**
Session established with server TSM8: AIX
Server Version 8, Release 1, Level 21.000
Server date/time: 01/22/26 16:19:08 Last access: 01/22/26 16:15:51
There are no schedules associated with this node.
jsmeix commented at 2026-01-23 10:04:¶
@dcabro
please provide a "rear -D mkrescue" debug log file.
Otherwise I have no chance to imagine what goes on.
Caution with possible secrets in a ReaR log file.
In particular in debugscript mode via '-D'
ReaR logs executed commands via the bash command 'set -x'
that print commands and their arguments as they are executed.
So in particular when arguments contain secret values
(e.g. something like a password or whatever else)
such secret values may appear in the log file.
So before you attach your debug log file or other files here
(GitHub is a public accessible place), inspect your files
and verify that they do not accidentally cointain secrets.
FYI:
The "Saving result files with TSM" message comes from
usr/share/rear/output/TSM/default/950_dsmc_save_result_files.sh
which I changed in my
https://github.com/rear/rear/pull/3555
as shown in
https://github.com/rear/rear/pull/3555/files
I guess it hangs up in one of those 'dsmc' calls in
if [[ -z "$TSM_ARCHIVE_MGMT_CLASS" ]]; then
if test "$TSM_DSMC_OPTFILE" ; then
LC_ALL=${LANG_RECOVER} dsmc incremental -optfile="$TSM_DSMC_OPTFILE" "${TSM_RESULT_FILES[@]}" >/dev/null
else
LC_ALL=${LANG_RECOVER} dsmc incremental "${TSM_RESULT_FILES[@]}" >/dev/null
fi
else
if test "$TSM_DSMC_OPTFILE" ; then
LC_ALL=${LANG_RECOVER} dsmc archive -optfile="$TSM_DSMC_OPTFILE" -archmc="$TSM_ARCHIVE_MGMT_CLASS" "${TSM_RESULT_FILES[@]}" >/dev/null
else
LC_ALL=${LANG_RECOVER} dsmc archive -archmc="$TSM_ARCHIVE_MGMT_CLASS" "${TSM_RESULT_FILES[@]}" >/dev/null
fi
fi
one of the two 'dsmc' calls when TSM_DSMC_OPTFILE is set
so either
LC_ALL=${LANG_RECOVER} dsmc incremental -optfile="$TSM_DSMC_OPTFILE" "${TSM_RESULT_FILES[@]}" >/dev/null
or
LC_ALL=${LANG_RECOVER} dsmc archive -optfile="$TSM_DSMC_OPTFILE" -archmc="$TSM_ARCHIVE_MGMT_CLASS" "${TSM_RESULT_FILES[@]}" >/dev/null
You may replace the >/dev/null with 0<&6 1>&7 2>&8
so that you get 'dsmc' stdin/stdout/stderr on your terminal
which may help to see what goes on while that 'dsmc' command
is executed.
In particular with 'dsmc' stdin/stdout/stderr on your terminal
you run that 'dsmc' command interactively - same as if you
manually launch that 'dsmc' command on your terminal.
Perhaps with your TSM_DSMC_OPTFILE that 'dsmc' command may
prompt you for input like an explicit user confirmation
response ('yes' or 'y') under this or that special
circumstances or whatever?
See
https://github.com/rear/rear/wiki/Coding-Style#what-to-do-with-stdin-stdout-and-stderr
jsmeix commented at 2026-02-09 14:12:¶
@dcabro
FYI:
I converted
https://github.com/rear/rear/pull/3555
to a so called "draft", cf.
https://github.blog/news-insights/product-news/introducing-draft-pull-requests/
because currently it does not move forward.
I can convert it back to a normal pull request
at any time when things move forward again.
[Export of Github issue for rear/rear.]