#1188 Issue `closed`: better feedback during recovery¶

Labels: support / question, fixed / solved / done

razorfish-sl opened issue at 2017-02-03 04:55:¶

centos 7.2
Relax-and-Recover 2.00-git201701271258 / 2017-01-27

during a recovery job
network is pulling 80MB/s, after 1 day still pulling 80MB/S , but nothing appears to be going out to disk
after 183gb of a 700 gb job

restoring just shows
"restoring for xyz seconds"

nothing in error logs, no feed back...

gdha commented at 2017-02-10 17:00:¶

@razorfish-sl did you check the network latency? Perhaps you were on half-duplex instead of full-duplex?

razorfish-sl commented at 2017-02-10 21:04:¶

Nope...... 1000 Base T that works for every other program.
Might be due to the MTU... (restore to a VM)

or perhaps some sort of virtual block device?

That said: some sort of Debug option to increase feedback during file recovery would be very helpful.

gdha commented at 2017-02-24 12:31:¶

The verbosity you request is already present for tar see:

./conf/default.conf:BACKUP_PROG_OPTIONS="--anchored"
./conf/default.conf:BACKUP_PROG_OPTIONS_CREATE_ARCHIVE=""
./conf/default.conf:BACKUP_PROG_OPTIONS_RESTORE_ARCHIVE=""

just add what you need in your /etc/rear/local.conf file

gdha commented at 2017-03-10 09:32:¶

@razorfish-sl Any feedback or was your question answered sufficient?

gdha commented at 2017-04-25 18:05:¶

closing as question was answered

razorfish-sl commented at 2017-05-13 07:11:¶

sorry not to get back sooner.
ok checked it out and resolved the issue.

Network was on full duplex
I picked it up on other cross country Rsync jobs
it is something related to synology backup devices and the Rsync daemon.

Switching it to NFS it is speeding along now, i can max out the NIC on single large files now.

jsmeix commented at 2017-05-15 09:37:¶

@razorfish-sl
your initial description was too terse for me to imagine
what might go on on your particular system.
Because of your latest "single large files" snippet perhaps my
comments in restore/NETFS/default/400_restore_backup.sh
might be also of interest for you therein in particular my
comments regarding 'tar --verbose' messages that point to
https://github.com/rear/rear/issues/1116#issuecomment-267065150
which concluded that

during restore of huge files there is no useful 'tar' output
and that leads to useless progress 'Restored' values.

I guess for 'rsync' the same may happen so that perhaps
there are currently no good ReaR progress messages
while huge files are stored or restored via rsync?

Hardcore-fs commented at 2017-06-02 22:31:¶

Yep sorry,
when i find a problem, I log it then expand the details as i get more info from other systems.
by huge I mean single files of anything from 2-100gb (VM image files) over a 100base T
The receiving end was using an Rsync server, it must not have been threaded correctly.

MY main issue was that during a large transfer, short of looking at switch traffic there is no feed back other than the "seconds counter" of rear.

[Export of Github issue for rear/rear.]

#1188 Issue closed: better feedback during recovery¶