0

I backup our servers using rsync like this

rsync -av --delete /mnt/backup backupserverIPadress::backupfolder > /mnt/logs/textfile.txt

It was working fine until 10 days ago. When I check on the output in textfile.txt I found building file list ... only

I am almost sure that there have been changes in the server in the last days.

splattne
  • 28,508
  • 20
  • 98
  • 148
Libyano
  • 141
  • 2
  • 2
  • 8
  • Where did the errors from `rsync` go? If anything bad happened, that's where the information is. Your backup scripts should have arranged for you to be notified if `rsync` emitted any error or exited with a nonzero status. – Gilles 'SO- stop being evil' Sep 15 '10 at 23:34

1 Answers1

1

You may not be getting the whole picture. If anything (like errors) are sent to STDERR you will not see them in you log files. Try this command instead which will also redirect STDERR to the log file (note the end of the command):

rsync -av --delete /mnt/backup backupserverIPadress::backupfolder > /mnt/logs/textfile.txt 2>&1

You might want to also add in the --dry-run option. From the rsync manual:

This makes rsync perform a  trial  run  that  doesn't  make  any
changes (and produces mostly the same output as a real run).  It
is most commonly used in  combination  with  the  -v,  --verbose
and/or  -i,  --itemize-changes options to see what an rsync com-
mand is going to do before one actually runs it.

The output of --itemize-changes is supposed to  be  exactly  the
same on a dry run and a subsequent real run (barring intentional
trickery and system call failures); if it isn't, that's  a  bug.
Other  output should be mostly unchanged, but may differ in some
areas.  Notably, a dry run does not send  the  actual  data  for
file  transfers,  so --progress has no effect, the "bytes sent",
"bytes received", "literal data", and "matched data"  statistics
are  too  small,  and the "speedup" value is equivalent to a run
where no file transfers were needed.
jftuga
  • 5,731
  • 4
  • 42
  • 51