Dear Gary
On 03.12.2012 21:02, Gary Roach wrote:
>>> Everything worked fine for /etc. /root and /var. When I tried to backup
>>> / home the system chugged along for a long time and then went to sleep.
>>>
>> You mean the system went into sleep mode during the restore?
>>
> Yes. That appears to be the case. A system info tool I have showed the
> process to be "waiting for reply". What ever that means.
Sorry, but in my book, "Waiting for reply" does not mean "entering sleep
mode". The former implies an activity on the client while the latter
needs some kind of wakeup call. An OS going to sleep normally dumps all
its processes from the memory into a disk based file and enters a state
where it needs some external stimulus to awake and continue its jobs. It
really doubt if
a) a system running a backuppc job could be put to sleep and
b) if this should happen nonetheless, if the backuppc client
would be able to awake the server. In the best of all scenarios,
a sleeping system would awake upon the receipt of a
Wakeup-On-Lan (WOL) packet, but I have not found any indication
that backuppc is able to deliver one such.
So, you see, the distinction between "sleeping" and "waiting" could
really make a difference here: If your client goes to sleep while
waiting for a reply from the server, the restore job most probably will
fail because backuppc does not expect a client to do so and has no way
to awake the client, as far as I know.
On the other hand, if the client was waiting for a reply of the backuppc
server and an you as an impatient user has interupted this process, who
is to blame? My home PC currently has 581 GBytes of stuff stored under
/home, compared to 13 GBytes for the rest of the OS, so surely it will
take much more time to restore /home than the rest of the system.
>>> I had to manually stop the process by killing the PID.
>>> The restore log had the following entries:
>>>
>>> 2012-11-30 09:53:41 Started restore on TargetComputer (pid=7601)
>>> 2012-11-30 10:59:23 Restore failed on TargetComputer (aborted by
>>> signal=TERM)
>>>
>> What else did you expect after having it killed?
>>
> Exactly that. Just included the whole file.
??
>>
>>> 2012-11-30 10:59:23 TargetComputer: File::RsyncP::FileList::encode:
>>> missing rdev
>>>
>> This and the following "missing rdev" messages seem to indicate that the
>> backup does not contain a value for the device ID for these files. In
>> all the errors you have showed, only pipes seem to be affected. This may
>> either indicate that backuppc does not properly handle pipes or that the
>> rsync configuration during the backup of these files was missing the -D
>> switch.
>>
>> However, this is not a problem: I'd assume that KDE will silently
>> recreate the pipes if they are missing. If not, you still can recreate
>> them from the command line using the mkfifo command.
>>
> I think the missing D switch is definitely the problem.
Yes, I think so, too. However, the -D switch should have been present
*at the time of doing your backup* in order to make a difference. And,
according to my last eMail, *this doesn't matter* because you easily can
recreate those files using mkfifo if you really have to (BTW, did you
really read it?). The only thing you need to do is rerun the restore of
your /home process *without interrupting it even if it takes a day or
two*. For your information, I restored a 2.8 Terrabyte file server from
my backuppc server 4 weeks ago without any problems. But it took almost
two days. And, depending on network throughput and server performance,
this could have been much faster or much slower. However, canceling the
restore halfway in due to my impatience would not have resulted in a
usable outcome.
>>> I use
>>> inetd.conf to start the rsync daemon with an entry of :
>>>
>>> rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon
>>>
>>> If the -D switch must be included, should it be something like rsyncd -D
>>> daemon.
>>>
>> The rsync daemon in general uses /etc/rsyncd.conf for configuration. The
>> only options it accepts are listed in the man pages under the heading
>> "DAEMON OPTIONS" and those only deal with network parameter and daemon
>> behavior. The -D option needs to be present n the client side (and it
>> needed to be there during backup, too).
>>
>>
> You seem to imply that the D switch should be included as an entry in
> the rsyncd.conf file.
No. Please read my my last email again.
> Unfortunately, there is no place for switches in
> that file. The closest thing is the "socket options" parameter in the
> "global parameters" module. After some research of "setsockopt" I found
> no indication that the D option applies to that parameter.
Please read my my last email again.
>
> Would The D switch inclusion in the rsync string in the inetd.conf file
> work (ie the end of the string being 'rsyncd -D --daemon' or some such.)
No. Please read my my last email again.
> I really appreciate the help
So please take it. This is what I would do if I were you:
o Restore your /home partition again, this time mustering the
patience to wait until it really finishes.
o Move all those files with the "missing rdev" error message
out of the way (don't delete them, you may need the information
later)
o try to use the restored system. In case you get errors related to
one of the restore failures mentioned above, recreate the fifo
using the information from the files moved out of the way.
o Alternatively, I'd inspect the error messages and I would move
the whole .kde part of your home directory to .kde.old. I'd
expect KDE to re-create .kde upon first start up: You may have
to redo some configurations, but you still have the files in
kde.old as a reference.
With kind regards
Stefan Peter
--
"In summary, I think you are trying to solve a problem that may not
need to be solved, using a tool that is not meant to solve it, without
understanding what is causing your problems and without knowing how
the tool actually works in the first place :)"
Jeffrey J. Kosowsky on the backuppc mailing list
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
