#517 Issue closed: ReaR never gets to the backup step on systems with large numbers of disks

Labels: support / question

bjverzal opened issue at 2014-12-12 18:39:

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 commented at 2014-12-13 22:02:

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 commented at 2014-12-14 02:02:

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

bjverzal commented at 2014-12-14 02:05:

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
https://github.com/rear/rear/issues/517#issuecomment-66893320.

schlomo commented at 2014-12-14 09:02:

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

bjverzal commented at 2014-12-14 17:09:

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
https://github.com/rear/rear/issues/517#issuecomment-66907032.

bjverzal commented at 2014-12-14 17:12:

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
https://github.com/rear/rear/issues/517#issuecomment-66907032.

gdha commented at 2014-12-16 11:22:

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

gigawatts commented at 2014-12-16 15:31:

@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 commented at 2014-12-16 19:15:

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 commented at 2014-12-17 08:25:

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 commented at 2014-12-17 19:32:

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 commented at 2014-12-17 21:26:

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 commented at 2015-02-03 09:24:

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.


[Export of Github issue for rear/rear.]