ReaR never gets to the backup step on systems with large numbers of disks

[bjverzal]

In our GPFS Analytical environment, the ReaR goes through the setup steps but never starts the actual backup because it takes so long to query all of the disk on the system

(root@myserver) /root # wc -l /proc/partitions
2458 /proc/partitions

[schlomo]

Wow, I have never seen so many block devices!

Can you please provide a log and your configuration?

Also, does the same happen with rear mkrescue too?

[bjverzal]

We've not tried rear mkrescue. I'll respond to the mail with an attachment because I cannot paste a zip file here.

[bjverzal]

I've update the Git thread. Here is the attachment with the requested
information in it. I have included:

lshw
multipath -ll
/etc/redhat-release
rear.log

On Sat, Dec 13, 2014 at 4:02 PM, Schlomo Schapiro notifications@github.com
wrote:

Wow, I have never seen so many block devices!

Can you please provide a log and your configuration?

Also, does the same happen with rear mkrescue too?

—
Reply to this email directly or view it on GitHub
#517 (comment).

[schlomo]

Attachments don't work. Please use https://gist.github.com for your logs and also add your ReaR configuration (there or here).

[bjverzal]

https://gist.github.com/1ac2bf0072c5d85f6d10.git

I have there, the following:

/etc/redhat-release
lshw
multipath -ll
rear.log

Thanks!

On Sun, Dec 14, 2014 at 3:02 AM, Schlomo Schapiro notifications@github.com
wrote:

Attachments don't work. Please use https://gist.github.com for your logs
and also add your ReaR configuration (there or here).

—
Reply to this email directly or view it on GitHub
#517 (comment).

[bjverzal]

As to the configuration:

NFS v4 to an AIX server. I think we are on Version 15 of ReaR. The
configs are standard across all 1600 of our servers. Only these two with
the large number of disks are failing.

On Sun, Dec 14, 2014 at 3:02 AM, Schlomo Schapiro notifications@github.com
wrote:

Attachments don't work. Please use https://gist.github.com for your logs
and also add your ReaR configuration (there or here).

—
Reply to this email directly or view it on GitHub
#517 (comment).

[gdha]

@bjverzal the link to the gist stays blank with me?

[gigawatts]

@gdha I am a co-worker of @bjverzal, if you knock the .git off the end of his gist, you can see the 4 files. The raw's of each are as follows:

https://gist.githubusercontent.com/bjverzal/1ac2bf0072c5d85f6d10/raw/redhat-release
https://gist.githubusercontent.com/bjverzal/1ac2bf0072c5d85f6d10/raw/rear.log
https://gist.githubusercontent.com/bjverzal/1ac2bf0072c5d85f6d10/raw/multipath.out
https://gist.githubusercontent.com/bjverzal/1ac2bf0072c5d85f6d10/raw/lshw.out

[gigawatts]

If there is a quick hack I can implement that ONLY scans the partition structure of sda, for example, instead of all disks, that is all I really need to get these couple servers backed up properly. Then we can try for a "real" solution later.

[gdha]

A quick hack could be to put in script /usr/share/rear/layout/save/GNU/Linux/28_multipath_layout.sh the following lines in front of the other code:

if [[ "$AUTOEXCLUDE_MULTIPATH" =~ ^[yY1] ]] ; then
    return
fi

[gigawatts]

I assume we should also then set AUTOEXCLUDE_MULTIPATH = 1 in our local.conf, to activate this skip?

Edit: Never mind. I tried adding the if statement you provided without defining that variable anywhere, and it seems to have worked! I will be adding this hack to all my systems currently experiencing this issue.

Thank you very very much @gdha !

[schlomo]

It seems to be enabled by default:

$ grep -r AUTOEXCLUDE_MULTIPATH .
./usr/share/rear/lib/layout-functions.sh:    if [[ -n "$res" || "$AUTOEXCLUDE_MULTIPATH" =~ ^[yY1] ]]; then
./usr/share/rear/conf/default.conf:AUTOEXCLUDE_MULTIPATH=y
./usr/share/rear/layout/save/default/32_autoexclude.sh:if [[ "$AUTOEXCLUDE_MULTIPATH" =~ ^[yY1] ]] ; then
./doc/user-guide/06-layout-configuration.txt:A similar mechanism exists for multipath disks. The +AUTOEXCLUDE_MULTIPATH=y+

Maybe the check was just missing from 28_multipath_layout.sh

[gdha]

no the check was not there on purpose as we like to have our multipath config in our layout and what later it will be commented anyway. It is always nice to see what was originally configured on your system (handy in DR mode to see what was on the production system).
However, in rare cases there are just too many devices. I would not modify this script.
Just gonna close this issue.