2 Servers backing up to each other, both server and both client

[megapearl]

What am I doing wrong? Having the error on both servers (both FreeBSD 9.2)

Backup starts but gives error after couple of minutes:

Crontab mail: 2013-12-31 20:03:00: burp[50461] before client 2013-12-31 20:03:00: burp[50461] begin client 2013-12-31 20:03:01: burp[50461] auth ok 2013-12-31 20:03:01: burp[50461] Server version: 1.4.10 2013-12-31 20:03:01: burp[50461] nocsr ok 2013-12-31 20:03:01: burp[50461] Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 2013-12-31 20:03:02: burp[50461] Compression level: 9 2013-12-31 20:03:02: burp[50461] do backup client 2013-12-31 20:03:02: burp[50461] Phase 1 begin (file system scan)

ddffffffffdddfddffdddffffffffdddffdffffdddffffdffdfffddfffdfdfff 64 fffdfffffffffffffffffffffffffffffffffffffffffffffffffdffffffffff 128 fffffffffffffffffffffffffffffffffffffffffffffffdfffdffdfdffffffd 192 fddffffffffffffffffdffffffffffffffffdfdfffdffdffffffffffffffffdf 256 fffffffffddfdfffffffffffffffffffffffddffffffffffffdffffddffffdff 320 ffffffffffdffffffffffffdffffffffffffdfffffffffdffffffffdffffffff 384 ffffffffffffffffffffffffffddddddddfdddddddddddddddfdddfddddddddd 448 ddddddddddddddddfdddddddddfdddddfdddddddddddddddddddfdfddfdddfdd 512 dddddddddddfddddddddfdddfdfdddddddddddddddddddddddfddddddddddddd 576 ddfdddddddddddddddddfddddfddddfdddddddddddfdddfdfddddddddddddddd 640 ddddddfdddddfddddddfddddddddddddfddddddddddddddddddddddddfdddfdd 704 ddddddfddddddddddddddddddddddddddddddddddddddddddddddddddddddddd 768 dddddddddddddddfdddddddfddddddddddddddddddddfdfdddddddddfdddddfd 832 ddddddddddddddddddddddddddfddfdddddddddfdfdddddfdddddddddddddddd 896 dddfdddddfddddddddddddddddddddddfddddddddddddfdddddfdddfdddddddf 960 dddddddddddddddddddddddddddfddddddddddddddddddddddddddfdddddfdfd 1024 ddddddfdddddddddfddddfdddfdddddddddddddddfdddddddddfdfdddddddddd 1088 ddddfddddddddfddddfdddddfdddddddddddfddfdddddddddddfddddfddddddd 1152 ddddddddddddddfdddddfdddddddddddddddddddddddddddddddfddddfdddddd 1216 ddfdddddddddddddddddddddddddfdddddfddddfddddfdddddfdddfddddddddd 1280 fdddddddddddddddddfddddddddddfdddddddddddddddddfdfddddddfdfdddfd 1344 ddddfdddfdddddddfdddddfdddfddddfdfddddddddddddddddddddddddddddfd 1408 ddddddddddddddddfddddddfddddddfdddddddfdddddddddddddddfddfddfddd 1472 ddddfddddddddddddddddddfdddfdddfdddfdddfddfdffffffffffffffffffff 1536 ffffffdfddffffffffffffffffffffffffffffffffdfffffffffffffffffffff 1600 fffffffffffffffffffffffffffffffffffffffffffffffffffffddfffffffff 1664 fffdffffffdfffffffffffffffdffffdffdfffffffffffffffffffffffffffff 1728 fffffdffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1792 ffffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffff 1856 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1920 fffdffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1984 fffffffffffffffffffffffffffffffffffffffffffffffdffffffffffffffff 2048 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2112 ffffffffffffffffffffffffffffffffdffffffffffdffffffffffffffffffff 2176 ffffffffffffffffffffffffffffffffffffffffffdfffffffffffffffffffff 2240 fffffffffffffffffffffffffffffffffffffffffffffffffffffdffffffffff 2304 fffffffffffffffffffdffffffffffdfffffffffffffffffffffffffffffffff 2368 ffffffffffffffffffffffffffffffffffffffffffdfffffffffffffffffffff 2432 fffffffdfffffffffffffffffffffffffffffdffffffffffffffffffffffffff 2496 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2560 ffffffffffffffddddddffffffffffffffffffffffffffffffffffffffffdfff 2624 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2688 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2752 ffffffffffffffffffdffffffffffffffffffffffffffffffdffffffffffffff 2816 ffffffffffffffffffffffffffffffffffdffdffffdffffffffdffffffffffff 2880 dffffffffffffdfffffffffffffffffdffffffdfffffdfffffffffffffffffff 2944 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3008 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3072 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3136 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3200 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3264 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3328 fdffffffffffffffffffffffffffffffffffffffffffdfffffffffffffffffff 3392 fffffdffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3456 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3520 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3584 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3648 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3712 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3776 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3840 dffffffffffdffffffffffffffffffffffffffffffffffffffffffffffffffff 3904 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3968 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4032 ffffffffffffffffffffffffffffffffdfffffffffffffffffffffffffffffff 4096 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4224 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4288 ffdffffffffffffffffdffffffffffffffffffffffffffffffffffffffffffff 4352 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffffff 4416 ffffffffffffdffdffffffddfffffffddfffffffffffffffffffffffffffffff 4480 ffffffffffffffffffffffffffffffddffffffffffffffffffffffffffffffdf 4544 fffffffffffffffffffffffffffffdfffffffffffdfffffffdfffdffffffffff 4608 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4672 fffffffffffffdffffffffffffffffffffffffffffffffffffffffffffffffff 4736 fffffffffffffffffffffffffffffffffffffffffdfffffffffdffffffffffff 4800 ffffffffffdffdffffdfffffffdfffffffffffffffffffffffffffffffffffff 4864 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4928 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdffff 4992 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd 5056 ffffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffff 5120 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5184 fffffffffffffffffffffffffffffffffffffffffffffffffffffdffffffffdf 5248 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5312 ffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffffffdf 5376 ffdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5440 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5504 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5568 ffffffffdffffffffffffffffffffffffffffffffffffdffffffffdfffffffff 5632 fffffffffffffdffffdfffffffffffffffffffffffffffffffffffffffffffff 5696 ffffffffffffffffffdfffffffffffffffffffffffffffffffffdfffffffffff 5760 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 5824 fffffffffffffffffffffffffffffffffffffffdffffffffffffffffffffffff 5888 fffffffffffffffffffffffffffffffffdfffffffffffffffffffffffffdfffd 5952 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6016 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6080 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6144 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6208 ffffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffdf 6272 ffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffffdf 6336 fffffffffffffffffffffffffffffffffffffffffffffffffffddfffffffffff 6400 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6464 fffffffffffffffffffffffffffffffffffffffffffffffffdffffffffffffff 6528 dffffffffffdffffffffffffffffffffffffffffffffffffffffffffffffffff 6592 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6656 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 6720 fffffffffffffffffffffffffffffffffffffffffdffffdfffffffffffffffff 6784 ffffdffffffffffffffffffffffffffffffffffffffffffdffdfffffdfffffff 6848 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffddffffdf 6912 ffffffffffffffffffffffffffffffffddffdfffffffffffffffffffffffffff 6976 ffffffffffffdffffffffffffffffffffdffffffffffffffffffffffffffffff 7040 fffffffffffffffffffffffffffffffffffffffdfffffffffffddfffffffdfff 7104 fddfffffffffffffffffffdfffffffffffffffffdfffffffffffffffffffffff 7168 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 7232 ffffffffffffffffffffffffdfffffdfffffffffffffffdfffffffffffffffff 7296 ffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffffffff 7360 fffffffffffffffffffffffffffffffffffffdffffffffffffffffffffffffff 7424 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffff 7488 dffdfffffffffffffffffffffffffffffffdffffffffffffffffdfffffffffff 7552 fffffffffffffffffffdfffffffdffffffffffffffffffffffdffffffdffffff 7616 ffffdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 7680 fffffffffffffffffffffffffffffffffffffffdffffffffffffffffffffffff 7744 ffffffffffffffffffffffffdfffffffffffffffffdfffffffffffffffffffff 7808 fffffdffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 7872 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 7936 ffffffffffffffffffffffffffffffffffffffffffffffffffffdffffffffdff 8000 ffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffffff 8064 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 8128 fffffffffffffffffffffffffffffffffffffffffffdfffffffffffffdffffff 8192 fffffffffffffffffffffffffffffffffffdffffffffffffffffffffffffffff 8256 ffffffffffffffffffffffffffdfffffffffffffffffffffffffffffffffffff 8320 ffffffffffffffffffffffffffffffffffffffffffffffffdfffffffffffffff 8384 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 8448 ffffffffffffffffffffffffffffffffffffffffffffffffdfffffffffffffff 8512 fffffffffffdfffffffffffffffffffffffffffffffffffdfffffffffffdffff 8576 fffffffffffffffffffffffffffffdffffffffffffffffdffffffffffffffffd 8640 ffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffff 8704 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 8768 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 8832 ffffffffffffffffffffffffffffffffffffffffffdfffffffffffffffffffff 8896 fffffdffffffffffffffffffffdfffffffffffffffffffffffffffffffffffff 8960 fffffffdffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9024 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9088 fffffffffffffffdffffffffffffffffffffffffffffffffffffffffffffffff 9152 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9216 ffffffffffffffffffffffffffffffffffffffffffdfffffffffffffffdfffff 9280 ffdffffffffffffffdffffffffffffffffffffffffffffffffffdfffffffffff 9344 ffffffffffffffffffffffffffffdfffffdfffdfffffffffffffffffffffffff 9408 fffffffffffffffffffffffffffffffffffffffffffdffffffffffffffffffff 9472 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9536 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9600 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9664 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9728 ffffffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffff 9792 fffffffffffffffffffdffffffdfffffffdffffffffffffffffdffffffffffff 9856 ffffffffffffffffffffffffffdfffffffffffffffffffffffffffffffffffff 9920 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 9984 fffffffffffffffffffffffffffffffffffffffffffffffffffdfffdffffffff 10048 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 10112 dfffffffffffffffffffdffffffffffffdffffffffffffffffffffffffffffff 10176 fffffffffffffffffdffffffffffffffffffffffffffffffffffffffffffffff 10240 fffffffffffffffffffffffffffdfffffffffffffffffffffffffffffdffffff 10304 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdfff 10368 ffffffffffffffffffffffffffffffffffffffffdffffffffffffdffffffffff 10432 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffdffffff 10496 ffffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffff 10560 ffffffffffffdffffffffffffffffdffffffffffffffffffffffffffffffffff 10624 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffdfffffff 10688 fffffffffffffffffdffffffffffffffffffffffffffffffffffffffffffffff 10752 fffffffffffffffffffffffffffffffffffffffffffffffffffdffffffffffff 10816 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 10880 fffffffffffffffffffffffffffffffdffffffffffffffffffffffffffffffff 10944 fdffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11008 fffffffffffffffffffffffffffffffffffffffffffdffffffffffffffffffff 11072 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11136 fffffffffffffffdffffffffffffffffffffffffffffffffffffffffffffffff 11200 ffffffffdfffffffffffffffffffffffffffffffffffffffffffffffffffffff 11264 fffffdffffffffffffffffffffffffffffffffffffdffffffffffdffffffffff 11328 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11392 ffffffffffffffffffffffffffffffffffffffffdfffffffffffffffffffffff 11456 fffffffffffffffffffffffffffffffffffffffffffffffffffffdffffffffff 11520 fffffffffffdffffffffffffffffffffffffffffffffffffffffffffffffffff 11584 ffffffffffffffffffffffffffffffffffddffffffffffffffffffffffffffff 11648 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11712 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11776 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 11840 ffffffffffffffffffffffffffffffffffffffffffffffffffdfffdfffffffff 11904 ffffffffdffffffffffddffffdffdffffdffffffffffffdffffffffdfffffdff 11968 fffdfffffdfffffdfffffdffffffffdfffffffffffffffffffffffffffffffff 12032 ffffdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffdf 12096 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12224 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12288 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12352 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12416 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 12480 fffffffffffffffffffddffffffffffffdfddffdffffffffffffffffffffffff 12544 ffffffffffffffffffffffdfffffffffffffffdfdfdffdffdfdfffffffdfdffd 12608 ffffffffffffffffffffffffffffffffffffffdfffffffffffdfffffffffffff 12672 ffffffffffffffffffffffffffffffffdfdffffffffffffffffdffdffddfdfff 12736 fffdfdffffffffffffffffffdfffdffffffffffffffffffffffffffffffffdff 12800 fdfffffddfffdfffddffffffffffffffffdffddffffdffdfffffffffdfffffff 12864 ffffffffffffffffffffffffffffffffdffffffffdfddfffffffffffffffffff 12928 fffffffffffdfffffffffffdffffffffffffffffffffffffffffffffffffffdf 12992 fffffffffffffffffffffffffffdffffffldffffffffffffffffffffffffffff 13056 ffffffffffffffffffffffffffffdfffffffffffffffffffffffffffffffffff 13120 fffffffddffffffddfffffffffffffffffffffffffffffffffffffffffffffff 13184 ffffffffffffffdffffffffddffffffffffffffffffffffffffffffdffffffff 13248 ffffffffffffffffffffffdfffffffffffdffffffffffffffffffdffffffffff 13312 fffffffffffffffffffffffffffdfffffffffffdffffffdfffdfffffffffffff 13376 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13440 ffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffffffff 13504 ffffffffffffffffffffffffffffffffffffdfffffffffffffffffffffffffff 13568 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13632 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13696 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13760 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13824 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 13888 ffffffffffffffffffffffffffffdfffffffffffffffffffffffffffffffffff 13952 fdfffffffffffffffffffffffffffffffffffffffffffffdffffffffffffffff 14016 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14080 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14144 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14208 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14272 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14336 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14400 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14464 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14528 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14592 fdfffdfdffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14656 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14720 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14784 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14848 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14912 fffffdffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 14976 ddffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15040 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15104 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15168 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15232 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15296 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15360 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15424 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 15488 ffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffffffff 15552 fffffffffffdffffffffffffffffffffffffffffffffffffffffffffffffffff 15616 ffffffffffffffdfffffffffffffffffffffffffffffffffffffffffffffffff 15680 fffffffffffffffffffffffffffffffffdffffffffffffffffffffffffffffff 15744 ffffffffffffffffffffffffffffffdfffffffffffffffffffffffffffffffff 15808 ffffffffffffffffffffffdfffffffffffffffffffffffffffffffffffffffff 15872 fffffffffffffffffffffffffffffffffffffffdfffffffffffddfffffffffff 15936 fffffddffdfffdfffdfffdfffdfffffffffffffffffffdffdfffffffdfdfffff 16000 fdfffffffffffffffffffffffffffffffffffffdfffffffffffffffdffffffff 16064 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 16128 ffffffffffffffffffffffffffffdffffffffffffdffdfffffffffffffffffff 16192 ffffffffffffffffffffffffffffffffffffffffffffdffffffffdffffffffff 16256 ffffffffffffffffdfffdffffffffdffffddfdffffffffffffffffffffffffff 16320 fffffffdddddfdfdfdfdfdffffffffddfffffffffffffffffffffffddffffdff 16384 dfffffdffffffdffffffff 16406

2013-12-31 20:03:08: burp[50461] Phase 1 end (file system scan) 2013-12-31 20:03:08: burp[50461] Phase 2 begin (send file data)

ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 64 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 128 ffffffffffffffffffffffSSL write problem2013-12-31 20:12:48: burp[50461] Got SSL_ERROR_SYSCALL in write, errno=1 (Operation not permitted) 2013-12-31 20:12:48: burp[50461] write returned: -1 2013-12-31 20:12:48: burp[50461] error in do_write 150

---

Start time: 2013-12-31 20:03:00 End time: 2013-12-31 20:12:48 Time taken: 09:48 New Changed Unchanged Deleted Total | Scanned

        Files:       150         0         0         0       150 |    14999
  Directories:         0         0         0         0         0 |     1406
   Soft links:         0         0         0         0         0 |        1
  Grand total:       150         0         0         0       150 |    16406
               ------------------------------------------------------------

         Warnings:             0

  Bytes estimated:   80393227131 (74.87 GB)
  Bytes in backup:     630807075 (601.58 MB)
   Bytes received:             0
       Bytes sent:     630807075 (601.58 MB)

---

2013-12-31 20:12:48: burp[50461] Error in phase 2 2013-12-31 20:12:48: burp[50461] Phase 2 end (send file data) 2013-12-31 20:12:48: burp[50461] error in backup 2013-12-31 20:12:48: burp[50461] after client

Burp Failure Mail: 0000001 2013-12-31 20:03:02

/mnt/backup/Backup/Burp/redacted/working/log:

2013-12-31 20:03:02: burp[86467] Client version: 1.4.10 2013-12-31 20:03:02: burp[86467] Begin phase1 (file system scan) 2013-12-31 20:03:08: burp[86467] End phase1 (file system scan) 2013-12-31 20:03:08: burp[86467] Begin phase2 (receive file data) 2013-12-31 20:12:49: burp[86467] Got SSL_ERROR_SYSCALL in read, errno=54 (Connection reset by peer) 2013-12-31 20:12:49: burp[86467] SSL read problem 2013-12-31 20:12:49: burp[86467] error in async_rw 2013-12-31 20:12:49: burp[86467] End phase2 (receive file data) 2013-12-31 20:12:49: burp[86467] error in backup phase 2

[grke]

That looks strange, and not something I have seen before. Ideas: Does it work if you back up a server to itself? Does standing in the test directory of the source and running 'make test' work? Does it work if you remove the changes to the listen socket code? Does it always fail at the same place on the same file? Is one of the machines going into sleep or suspend mode? Is there something else possibly interfering with TCP connections on the network?

[megapearl]

It does work when backing up to itself (localhost).

Test script gives error (changed the first to be #!/usr/local/bin/bash) root@server:/home/donald/burp/test # make test ./test_self cp: the -R and -r options may not be specified together

Test setup failed: could not copy ../.gitignore to /home/donald/burp/test/build

*\ [test] Error code 1

Got SSL_ERROR_SYSCALL in write, errno=1 (Operation not permitted) Got SSL_ERROR_SYSCALL in read, errno=54 (Connection reset by peer) Got SSL_ERROR_SYSCALL in read, errno=60 (Operation timed out)

Everytime the crontab runs (every half hour) I got the following error from crontab but I think this one is normal? IN CRON: /usr/local/sbin/burp -c /usr/local/etc/burp/burp.conf -a t

Mail from cron: 2014-01-01 02:33:00: burp[91232] Could not get lockfile. 2014-01-01 02:33:00: burp[91232] Another process is probably running, 2014-01-01 02:33:00: burp[91232] or you do not have permissions to write to /var/run/burp.client.pid.

The process is indeed running because the backup isn't finished yet?

It doesn't make any difference when I remove the changes to the listen socket code. It fails randomly not just the same file or same place, but almost always in the second data line (128) and 2 times in the (768) data line with one of the above 3 errors. None of the machines are going in sleep or suspend mode. I run a very restrictive firewall set (pf) which I turned off on both servers to test, but that doesn't make any difference.

[grke]

I guess the test script doesn't work because options for things like cp are different on FreeBSD.

To get rid of the cron emails, I normally put ">/dev/null 2>&1" at the end of the cron line.

I have no idea what is going wrong between the two servers. It is odd that it works locally and not between them. I am currently downloading FreeBSD to try it myself. Is there any unusual setting or configuration that I should set when I am installing it?

[megapearl]

I think the options are different, yes.

In Linux: donald@Donald-SSD:~$ cp --help Usage: cp [OPTION]... [-T] SOURCE DEST or: cp [OPTION]... SOURCE... DIRECTORY or: cp [OPTION]... -t DIRECTORY SOURCE... Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

Mandatory arguments to long options are mandatory for short options too. -a, --archive same as -dR --preserve=all --attributes-only don't copy the file data, just the attributes --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument --copy-contents copy contents of special files when recursive -d same as --no-dereference --preserve=links -f, --force if an existing destination file cannot be opened, remove it and try again (redundant if the -n option is used) -i, --interactive prompt before overwrite (overrides a previous -n option) -H follow command-line symbolic links in SOURCE -l, --link hard link files instead of copying -L, --dereference always follow symbolic links in SOURCE -n, --no-clobber do not overwrite an existing file (overrides a previous -i option) -P, --no-dereference never follow symbolic links in SOURCE -p same as --preserve=mode,ownership,timestamps --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all --no-preserve=ATTR_LIST don't preserve the specified attributes --parents use full source file name under DIRECTORY -R, -r, --recursive copy directories recursively --reflink[=WHEN] control clone/CoW copies. See below --remove-destination remove each existing destination file before attempting to open it (contrast with --force) --sparse=WHEN control creation of sparse files. See below --strip-trailing-slashes remove any trailing slashes from each SOURCE argument -s, --symbolic-link make symbolic links instead of copying -S, --suffix=SUFFIX override the usual backup suffix -t, --target-directory=DIRECTORY copy all SOURCE arguments into DIRECTORY -T, --no-target-directory treat DEST as a normal file -u, --update copy only when the SOURCE file is newer than the destination file or when the destination file is missing -v, --verbose explain what is being done -x, --one-file-system stay on this file system --help display this help and exit --version output version information and exit

In FreeBSD: SYNOPSIS cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file target_file cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpvx] source_file ... target_directory

DESCRIPTION In the first synopsis form, the cp utility copies the contents of the source_file to the target_file. In the second synopsis form, the con- tents of each named source_file is copied to the destination target_directory. The names of the files themselves are not changed. If cp detects an attempt to copy a file to itself, the copy will fail.

 The following options are available:

 -H    If the -R option is specified, symbolic links on the command line
       are followed.  (Symbolic links encountered in the tree traversal
       are not followed.)

 -L    If the -R option is specified, all symbolic links are followed.

 -P    If the -R option is specified, no symbolic links are followed.
       This is the default.

 -R    If source_file designates a directory, cp copies the directory and
       the entire subtree connected at that point.  If the source_file
       ends in a /, the contents of the directory are copied rather than
       the directory itself.  This option also causes symbolic links to be
       copied, rather than indirected through, and for cp to create spe-
       cial files rather than copying them as normal files.  Created
       directories have the same mode as the corresponding source direc-
       tory, unmodified by the process' umask.

       Note that cp copies hard linked files as separate files.  If you
       need to preserve hard links, consider using tar(1), cpio(1), or
       pax(1) instead.

 -a    Archive mode.  Same as -RpP.

 -f    For each existing destination pathname, remove it and create a new
       file, without prompting for confirmation regardless of its permis-
       sions.  (The -f option overrides any previous -i or -n options.)

 -i    Cause cp to write a prompt to the standard error output before
       copying a file that would overwrite an existing file.  If the
       response from the standard input begins with the character `y' or
       `Y', the file copy is attempted.  (The -i option overrides any pre-
       vious -f or -n options.)

 -l    Create hard links to regular files in a hierarchy instead of copy-
       ing.

 -n    Do not overwrite an existing file.  (The -n option overrides any
       previous -f or -i options.)

 -p    Cause cp to preserve the following attributes of each source file
       in the copy: modification time, access time, file flags, file mode,
       ACL, user ID, and group ID, as allowed by permissions.

       If the user ID and group ID cannot be preserved, no error message
       is displayed and the exit value is not altered.

       If the source file has its set-user-ID bit on and the user ID can-
       not be preserved, the set-user-ID bit is not preserved in the
       copy's permissions.  If the source file has its set-group-ID bit on
       and the group ID cannot be preserved, the set-group-ID bit is not
       preserved in the copy's permissions.  If the source file has both
       its set-user-ID and set-group-ID bits on, and either the user ID or
       group ID cannot be preserved, neither the set-user-ID nor set-
       group-ID bits are preserved in the copy's permissions.

-v Cause cp to be verbose, showing files as they are copied.

 -x    File system mount points are not traversed.

 For each destination file that already exists, its contents are overwrit-
 ten if permissions allow.  Its mode, user ID, and group ID are unchanged
 unless the -p option was specified.

 In the second synopsis form, target_directory must exist unless there is
 only one named source_file which is a directory and the -R flag is speci-
 fied.

 If the destination file does not exist, the mode of the source file is
 used as modified by the file mode creation mask (umask, see csh(1)).  If
 the source file has its set-user-ID bit on, that bit is removed unless
 both the source file and the destination file are owned by the same user.
 If the source file has its set-group-ID bit on, that bit is removed
 unless both the source file and the destination file are in the same
 group and the user is a member of that group.  If both the set-user-ID
 and set-group-ID bits are set, all of the above conditions must be ful-
 filled or both bits are removed.

 Appropriate permissions are required for file creation or overwriting.

 Symbolic links are always followed unless the -R flag is set, in which
 case symbolic links are not followed, by default.  The -H or -L flags (in
 conjunction with the -R flag) cause symbolic links to be followed as
 described above.  The -H, -L and -P options are ignored unless the -R
 option is specified.  In addition, these options override each other and
 the command's actions are determined by the last one specified.

 If cp receives a SIGINFO (see the status argument for stty(1)) signal,
 the current input and output file and the percentage complete will be
 written to the standard output.

---

Indeed already put ">/dev/null 2>&1" to the cron lines.

Is it normal that burp starts another instance when a client connect at it? I see it twice, and started burp server once.

root@server:/usr/home/donald/burp # ps aux|grep burp root 30978 0.0 0.1 46388 5268 ?? Ss 3:29AM 0:00.44 /usr/local/sbin/burp -c /usr/local/etc/burp/burp-server.conf root 31083 0.0 0.1 46388 6144 ?? S 3:41AM 9:25.91 /usr/local/sbin/burp -c /usr/local/etc/burp/burp-server.conf root@server:/usr/home/donald/burp

---

Maybe it has something to do with the network options in /etc/sysctl.conf and in /boot/loader.conf I put lots of options in it due to ddos attacks lately

When you install FreeBSD make sure to get the /usr/ports tree up to date. I use 'portsnap fetch update' and 'portmaster -a -y' You can install it for example by cd /usr/ports/ports-mgmt/portmaster configure it by using make config and install it by using make install, you can remove it by using 'make deinstall clean'

When installing bash via same way you can't set the prefix to /usr

All user related things in FreeBSD always go to /usr/local just to keep it organised I think.

I'll configured burp like this: './configure --prefix=/usr/local --sbindir=/usr/local/sbin --sysconfdir=/usr/local/etc/burp LDFLAGS="-L/usr/local/lib" && gmake && gmake install' and changed all the /usr things to /usr/local in the scripts.

I'll test some more network related things, pf firewall and options in sysctl.conf and loader.conf and let you now.

Thanks for the quick support!

Happy New Year! Regards Donald.

[grke]

OK, so it worked for me before you got back with those suggestions. This is what I did, as far as I remember:

Downloaded FreeBSD-9.2-RELEASE-amd64-disc1.iso from a mirror.

Set up two 64 bit Virtualbox machines with bridged network interfaces, 512MB memory and 20GB disks each. Called them freebsd1 and freebsd2.

On both machines:

Installed the operating system, using default options as much as possible. Used DHCP on the network interfaces. Didn't install 'games'. Rebooted.

On rebooting, configured sshd to let me log in as root (edit /etc/ssh/sshd_config and 'service sshd restart). Logged in as root via ssh.

cd /usr/ports make fetchindex pkg_add -r librsync pkg_add -r gmake pkg_add -r bash ln -s /usr/local/bin/bash /usr/bin/bash ln -s /usr/local/bin/bash /bin/bash

Copied burp-1.4.10.tar.bz2 to /root using scp. tar -xvf burp-1.4.10.tar.bz2 cd burp ./configure --prefix=/usr/local --sbindir=/usr/local/sbin \ LDFLAGS="-L/usr/local/lib" --disable-ipv6 gmake gmake install mv /usr/local/etc /etc/burp Edit /etc/burp/burp-server.conf to have stdout=1

ln -s /usr/local/sbin/burp_ca

Tried running the burp server, but found that burp_ca would not work because c_rehash (part of openssl) was not installed. This was odd, because various openssl parts were installed by default, but not c_rehash.

So: cd /usr/ports pkg_add -r openssl cp /usr/local/openssl/openssl.cnf.sample /usr/local/openssl/openssl.cnf

Found that some part of the system needed perl.

So: cd /usr/ports pkg_add -r perl

Tried running the burp server again: burp -c /etc/burp/burp-server.conf -F Seemed OK this time.

On freebsd1: cp /etc/burp/clientconfdir/testclient /etc/burp/clientconfdir/freebsd2

On freebsd2: In /etc/burp/burp.conf, removed 'include = /home' and added: include = / exclude = /var/spool/burp Then ran: burp -c /etc/burp/burp.conf -a b

And the backup completed after a few minutes.

Half way through the backup, after it had got farther than you had reported it working, I also ran the status monitor on the server, which worked fine: burp -c /etc/burp/burp-server.conf -a s

End of the client output:

ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 136320 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 136384 ffffffffffffffffffffffffffff 136412

---

Start time: 2014-01-01 09:57:08 End time: 2014-01-01 10:10:13 Time taken: 13:05 New Changed Unchanged Deleted Total | Scanned

        Files:    136412         0         0         0    136412 |   136412
  Directories:         0         0         0         0         0 |    35413
   Soft links:         0         0         0         0         0 |     2051
   Hard links:         0         0         0         0         0 |     5720
Special files:         0         0         0         0         0 |        4
  Grand total:    136412         0         0         0    136412 |   179600
               ------------------------------------------------------------

         Warnings:             1

  Bytes estimated:    1138431606 (1.06 GB)
  Bytes in backup:    1138432008 (1.06 GB)
   Bytes received:             0
       Bytes sent:    1138432008 (1.06 GB)

---

2014-01-01 10:10:14: burp[30746] Phase 2 end (send file data) 2014-01-01 10:10:14: burp[30746] backup finished ok 2014-01-01 10:10:14: burp[30746] after client

Server log: 2014-01-01 09:57:08: burp[30209] Client version: 1.4.10 2014-01-01 09:57:08: burp[30209] Begin phase1 (file system scan) 2014-01-01 09:57:08: burp[30209] WARNING: Dir: /dev [will not descend: file system change not allowed]

2014-01-01 09:57:53: burp[30209] End phase1 (file system scan) 2014-01-01 09:57:53: burp[30209] Begin phase2 (receive file data) 2014-01-01 10:10:13: burp[30209] End phase2 (receive file data) 2014-01-01 10:10:13: burp[30209] Begin phase3 (merge manifests) 2014-01-01 10:10:17: burp[30209] End phase3 (merge manifests) 2014-01-01 10:10:17: burp[30209] Backup ending - disconnect from client. 2014-01-01 10:10:17: burp[30209] Begin phase4 (shuffle files)

2014-01-01 10:10:17: burp[30209] Doing the atomic data jiggle...

Start time: 2014-01-01 09:57:07 End time: 2014-01-01 10:11:45 Time taken: 14:38 New Changed Unchanged Deleted Total | Scanned

        Files:    136412         0         0         0    136412 |   136412
  Directories:     35413         0         0         0     35413 |    35413
   Soft links:      2051         0         0         0      2051 |     2051
   Hard links:      5720         0         0         0      5720 |     5720
Special files:         4         0         0         0         4 |        4
  Grand total:    179600         0         0         0    179600 |   179600
               ------------------------------------------------------------

         Warnings:             1

  Bytes estimated:    1138431606 (1.06 GB)
  Bytes in backup:    1138432008 (1.06 GB)
   Bytes received:     353669922 (337.29 MB)
       Bytes sent:             0

---

2014-01-01 10:11:45: burp[30209] Backup completed. 2014-01-01 10:11:45: burp[30209] End phase4 (shuffle files)

I am wondering if maybe you have a problem with DHCP often resetting addresses, or something like that. Yes, perhaps your DDOS stuff has something to do with it.

[grke]

(and a Happy New Year) :D

[megapearl]

Still testing, and no luck, connection is timing out after due time between my two FreeBSD servers. A friend of mine is running Slackware linux and can backup successfully to one of my FreeBSD servers. So the problem lies between the two FreeBSD servers, the only difference between the two FreeBSD server is the max-mtu of the connected ISP, the mtu of FreeBSD server 1 (static ip) is 1428 and on FreeBSD server 2 (dynamic ip) is 1440. Testing out now by lowering mtu of FreeBSD server 2.

---

And some odd errors on one of the FreeBSD servers (configuration is the same on both)

Jan 3 02:03:01 server burp[31029]: Running timer script: redacted /mnt/backup/Backup/Burp/redacted/current /mnt/backup/Backup/Burp reserved1 reserved2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,23 Jan 3 02:03:01 server burp[31029]: In timeband: Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Jan 3 02:03:01 server burp[31029]: date: illegal time format Jan 3 02:03:01 server burp[31029]: /usr/local/etc/burp/timer_script: Date command returned error for redacted. Jan 3 02:03:01 server burp[31029]: Do a backup of redacted now. Jan 3 02:03:01 server burp[31029]: usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... Jan 3 02:03:01 server burp[31029]: [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] Jan 3 02:03:01 server burp[31029]: /usr/local/etc/burp/timer_script returned: 0

Why is date command giving error in the script? is date command syntax different on Linux and FreeBSD?

[grke]

Yes, date is different on FreeBSD, but the timer script has code in it for running the FreeBSD version (unless you have an old timer script - search timer_script for 'FreeBSD' to make sure - running 'make install' doesn't overwrite an already existing timer script - otherwise, I guess date changed again in FreeBSD, or there is some other problem).

Are you sure the server with the dynamic address isn't having it's address/interface go up and down at intervals? Perhaps establish a TCP connection to it with netcat and see if it gets interrupted.

[megapearl]

I think there is some other problem, timer scripts are the same on both servers (I see the FreeBSD code in both of them), maybe date on server1 (the one with static ip) which is an upgrade from FreeBSD 8 to 9 to 9.2 syntax is different from the one of server2 (dynamic ip) fresh 9.2 installation.

Usage looks the same on both:

usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]

Yes I'm sure interface doesn't go down on the dynamic one, I don't see any errors in dmesg, and am constantly logged in on both of the servers from 3g umts network from another location.

[grke]

Sorry, but I think I am unable to help more on the "Operation not permitted" problem.

Given that local backups work (which don't do anything different in code, but just use a local address), the slackware backup also works, as do the two FreeBSD 9.2 servers that I set up myself, it does seem like something external to burp. I'd love to know what the problem is, mind.

For the date problem, maybe adding some debug to the timer_scripts could help with figuring out the problem? Maybe $min_timesecs is expanding to something weird.

[megapearl]

Strange, still "Got SSL_ERROR_SYSCALL in read, errno=60 (Operation timed out)" errors and "Got SSL_ERROR_SYSCALL in read, errno=1 (Operation not permitted)" and sometimes "error in get_lock_and_clean()" error.

Just testing now to do a manually backup using /usr/local/sbin/burp -c /usr/local/etc/burp/burp.conf -a b So far so good, maybe the -a t from cron doesn't work well on one of the FreeBSD servers due to the timescript??

How can I add debug output to the timer_scripts?

And do you have a rc start/stop script handy for FreeBSD which I can place in /etc/usr/local/etc/rc.d to start burp server automaticly upon startup? I tried to edit the debian one but syntax is different of kill and some other commands.

[megapearl]

It look likes it won't work from out cron using -a t, when I run burp from cli from out screen with -a b the backup do work, what's the difference between the -a t en -a b, or does it have something to do with the timer_script?

root@server:/usr/home/donald # screen -r ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1856 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1920 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 1984 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2048 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2112 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2176 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2240 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2304 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2368 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2432 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2496 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2560 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2624 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2688 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2752 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2816 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2880 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 2944 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3008 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3072 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3136 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3200 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3264 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3328 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3392 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3456 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3520 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3584 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3648 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3712 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3776 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3840 ffffffffffffffffffffffffffmfffffffffffffffffffffffffffffffffffff 3904 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 3968 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4032 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4096 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 4160 fffffffffffffffffffffffffffffffffffffffffffffffffffff 4213

---

Start time: 2014-01-04 10:43:43 End time: 2014-01-05 03:38:22 Time taken: 16:54:39 New Changed Unchanged Deleted Total | Scanned

        Files:      4209         0         0         0      4209 |     4209
    Meta data:         4         0         0         0         4 |        4
  Directories:         0         0         0         0         0 |      172
  Grand total:      4213         0         0         0      4213 |     4385
               ------------------------------------------------------------

         Warnings:             0

  Bytes estimated:   24254149886 (22.59 GB)
  Bytes in backup:   24254150270 (22.59 GB)
   Bytes received:             0
       Bytes sent:   24254150270 (22.59 GB)

---

2014-01-05 03:38:22: burp[85255] Phase 2 end (send file data) 2014-01-05 03:38:22: burp[85255] backup finished ok 2014-01-05 03:38:22: burp[85255] after client root@server:/ #

[grke]

Assuming that your cron job runs 'burp -a t' as the same user, there is very little difference. 'burp -a b' avoids running the timer script and just does a backup. 'burp -a t' runs the timer script to decide whether to do a backup.

You could try running 'burp -a b' from your cron job instead of '-a t' (you might want to make the cron less frequently though).

Another idea I had is that maybe the locking is broken in some way and two 'burp -a t' processes are managing to run. It doesn't seem to quite match what you are reporting though, but I thought I would mention it as an idea.

Earlier, I mentioned adding debug to the timer script. By that I meant, editing the script to print things at potentially interesting places, so you can see which parts are running and with what parameters. For example, before the freebsd 'date' command, you could add: echo "min_timesecs: $min_timesecs"

Sorry, I have no FreeBSD init script. However, if you manage to create one, I will be pleased to add it to the source and you to the AUTHORS list. :)

[megapearl]

burp -a b does work, even from cron, I still think it has something to do with the timer_script.

This is what the timer_script does when I run it manually:

root@backup:/usr/local/etc/burp # ./timer_script redacted /mnt/storage/Backup/Burp/redacted/current /mnt/storage/Backup/Burp reserved1 reserved2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,2 Running timer script: redacted /mnt/storage/Backup/Burp/redacted/current /mnt/storage/Backup/Burp reserved1 reserved2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,2 In timeband: Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 date: illegal time format usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] ./timer_script: Date command returned error for redacted. Do a backup of redacted now. root@backup:/usr/local/etc/burp #

I'll create an init script and post it here.

[megapearl]

I created this script, which I placed in /usr/local/etc/rc.d and works for me: And I added these to /etc/rc.conf:

burp_enable="YES" burp_flags="-c /usr/local/etc/burp/burp-server.conf"

I can now start and stop burp with:

service burp start and service burp stop

---

!/bin/sh

. /etc/rc.subr

name=burp rcvar=burp_enable

command="/usr/local/sbin/${name}"

pidfile="/var/run/burp/${name}-server.pid"

required_files="/usr/local/etc/burp/${name}-server.conf"

sig_reload="USR1"

load_rc_config $name run_rc_command "$1"

---

[grke]

Is installing stuff in /usr/local normal for FreeBSD? If yes, that's great, I'll add those files to git.

The timer_script stuff: What is strange is that your backups are already part the way through when they go wrong - a few minutes after the timer_script does anything. I notice that when the timer script has a date error, it returns 0, which means that burp should do a backup. Effectively, all your 'burp -a t' commands are the same as a 'burp -a b'. This makes me think that maybe there might be a problem with locking in some fashion (as mentioned earlier - ie, more than one child server program ends up running and upsetting each other), or the problem is unrelated.

Just had a thought - the date command being run is this:

LANG=C LC_TIME=C date -r $min_timesecs +"%Y-%m-%d %H:%M:%S" Try running this by hand to see what happens: /bin/bash (or whatever the path to bash is) LANG=C LC_TIME=C date -r 10 +"%Y-%m-%d %H:%M:%S" That is, switch to a bash prompt then try the date command. Have you changed the interpreter in the first line in the timer script to something other than /bin/bash? Maybe the problem is that a different shell is running and doesn't know how to do the leading environment variables.

I am pretty sure the problem is not the timer script, but let's sort that out so that it is no longer an issue. :)

[megapearl]

Yes, all 'user' related stuff goes into /usr/local, every program you install through the ports or packages goes into /usr/local, only the base system and base daemons go into /usr

Maybe there is a locking problem then, could it be that "error in get_lock_and_clean()" error??

I also changed the pid location of burp to /var/run/burp/burp-server.pid instead of /var/run/burp-server.pid in the rc script and burp-server.conf because the client creates a pid also, and it looks 'nicer' if they are both in one dir.

Date command does work as espected, so $min_timesecs does output something strange on FreeBSD:

root@backup:/usr/local/etc/burp # bash [root@backup /usr/local/etc/burp]# LANG=C LC_TIME=C date -r 10 +"%Y-%m-%d %H:%M:%S" 1970-01-01 01:00:10 [root@backup /usr/local/etc/burp]#

No I didn't change the timer_script interpreter, only changed /usr/bin/bash to /usr/local/bin/bash

[grke]

Could you try adding this before the freebsd 'date' command in the timer_script: echo "min_timesecs: $min_timesecs" Then, see what it prints in the server log when the client connects with 'burp -a t'.

burp-server.pid is the main server process. The client one the you are thinking of is the client process. The ones that I am thinking of are the ones on the server that lock out individual server child processes. These are supposed to ensure that only one client called 'clientX', for example, can connect to the server at a time. These are the ones that 'get_lock_and_clean()' are concerned with.

However, there was a bug in get_lock_and_clean() recently that isn't completely dealt with in burp-1.4.10. False failure notifications sometimes get sent because some of the code wasn't differentiating between not getting a lock and getting an error when trying to get a lock. I have fixed this in the 'stable candidate' branch and released 1.3.46 with the fix in, but haven't yet updated the 1.4.x branch (lack of time, carpal tunnel operation, etc).

1.4.x is for new features only. 1.3.x is the branch that will soon become stable, hopefully with 1.3.46. If you are not using 1.4.x for some essential feature, I would recommend switching to 1.3.46. This should at least stop the occasional 'error in get_lock_and_clean()' notifications.

[grke]

(sorry for not noticing/remembering the get_lock_and_clean() thing sooner)

[megapearl]

No problem, I'll downgrade to 1.3.46. Output of min_timesecs is null or nothing.

Added echo "min_timesecs: test $min_timesecs test" after date:

In log: Jan 8 10:03:01 server burp[71300]: min_timesecs: test test Jan 8 10:03:01 server burp[71300]: usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... Jan 8 10:03:01 server burp[71300]: [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] Jan 8 10:03:01 server burp[71300]: /usr/local/etc/burp/timer_script returned: 1

[grke]

Can you figure out why $min_timesecs is not set?

There is a line in the timer script like this: min_timesecs=$((secs+intervalsecs))

Can you add a similar echo just before that to find out what $secs and $intervalsecs are? And if one of them looks strange, work backwards similarly to find out where the strangeness starts?

[megapearl]

$secs = not set (null, nothing) $intervalsecs = 72000

So, the FreeBSD date command in the timer_script doesn't output seconds?

[grke]

So, add another echo before the bit where secs gets assigned. The date command there uses $ts as an argument: echo "ts: $ts" if ! secs=$(LANG=C LC_TIME=C date +%s -d "$ts")

[grke]

Presumably, $ts will be unset or something strange. It is getting read out of $timestamp, which should be the path $current/timestamp.

If $current/timestamp exists, what is in it?

[megapearl]

I'll look into it when I'm at home, and let you know, in the meantime I downgraded to 1.46 stable, and tried to backup, still the same error, even with -a b from cli, so the 'operation not permitted' error has nothing to do with the timescript... as you said ;-)

The lock error is with 1.4.6 gone now:

burp[20892] Got SSL_ERROR_SYSCALL in write, errno=1 (Operation not permitted) SSL write problem2014-01-10 14:44:25: burp[20892] write returned: -1 2014-01-10 14:44:25: burp[20892] error in do_write

And lots and lots of: Jan 10 15:23:35 backup kernel: Limiting open port RST response from 225 to 200 packets/sec Jan 10 15:23:36 backup kernel: Limiting open port RST response from 519 to 200 packets/sec Jan 10 15:23:37 backup kernel: Limiting open port RST response from 205 to 200 packets/sec Jan 10 15:23:56 backup kernel: Limiting open port RST response from 442 to 200 packets/sec Jan 10 15:23:57 backup kernel: Limiting open port RST response from 504 to 200 packets/sec Jan 10 15:23:58 backup kernel: Limiting open port RST response from 731 to 200 packets/sec Jan 10 15:23:59 backup kernel: Limiting open port RST response from 895 to 200 packets/sec Jan 10 15:24:00 backup kernel: Limiting open port RST response from 792 to 200 packets/sec Jan 10 15:24:01 backup kernel: Limiting open port RST response from 324 to 200 packets/sec Jan 10 15:24:27 backup kernel: Limiting open port RST response from 216 to 200 packets/sec

Don't know if it has something to do with the operation not permitted error...

[megapearl]

$ts = 2014-01-10 00:02:02

and

root@backup:/mnt/storage/Backup/Burp/redacted/current # cat timestamp 0000122 2014-01-10 00:02:02 root@backup:/mnt/storage/Backup/Burp/redacted/current #

What should it be?

[grke]

$ts looks fine. It gets passed into this date command to get $secs:

LANG=C LC_TIME=C date +%s -d "$ts"

So, you need to run this to see what happens: bash LANG=C LC_TIME=C date +%s -d "2014-01-10 00:02:02"

[grke]

I don't know exactly what that RST stuff is, but from looking at google, it is nothing to do with burp.

Something else I am wondering - does this server have some sort of intrusion detection system on it that is messing with TCP connections, like snort or something?

You mentioned: "Maybe it has something to do with the network options in /etc/sysctl.conf and in /boot/loader.conf I put lots of options in it due to ddos attacks lately" It seems to me that playing with network options is a likely cause of the problem. You could maybe try copying /etc/sysctl.conf and /boot/loader.conf from the server that works (assuming that the servers are otherwise identical).

[megapearl]

root@backup:/mnt/storage/Homes/donald # bash [root@backup /usr/local/etc/burp]# LANG=C LC_TIME=C date +%s -d "2014-01-10 00:02:02" date: illegal time format usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@backup /usr/local/etc/burp]#

What is the +%s, maybe date don't understand it.

I already removed al those options in /etc/sysctl.conf and /boot/loader.conf Both servers already uses the exact same configuration. I don't run any intrusion detection system, only the pf firewall. Sometimes burp backup goes okay, maybe some bandwidth problem or timeout in the network, I'll monitor and try some different options in the pf firewall and let you know when it does work.

[grke]

Does the same date command work on the other server?

The +%s tells date to output the date formatted as seconds since the unix epoch. The date command is printing [+format] as a possible option in the usage output. Maybe it just doesn't understand the %s part. Or maybe it wants it at the end of the line: LANG=C LC_TIME=C date -d "2014-01-10 00:02:02" +%s

Anyway, I am thinking that if one of your servers has a different version of the date command, and weird network interruptions are happening on it that don't happen on your other server, perhaps it is time to rebuild the server?

[megapearl]

It's on both servers:

root@server:/usr/home/donald # bash [root@server /usr/home/donald]# uname -a FreeBSD redacted 9.2-RELEASE-p2 FreeBSD 9.2-RELEASE-p2 #1: Sat Dec 7 19:56:34 CET 2013 donald@redacted:/usr/obj/usr/src/sys/MAINSERVER amd64 [root@server /usr/home/donald]# LANG=C LC_TIME=C date +%s -d "2014-01-10 00:02:02" date: illegal time format usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@server /usr/home/donald]# LANG=C LC_TIME=C date -d "2014-01-10 00:02:02" +%s usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@server /usr/home/donald]#

AND

root@backup:/mnt/storage/Homes/donald # bash [root@backup /mnt/storage/Homes/donald]# uname -a FreeBSD redacted 9.2-RELEASE-p2 FreeBSD 9.2-RELEASE-p2 #3: Fri Dec 13 21:22:13 CET 2013 donald@redacted:/usr/obj/usr/src/sys/FILESERVER amd64 [root@backup /mnt/storage/Homes/donald]# LANG=C LC_TIME=C date +%s -d "2014-01-10 00:02:02" date: illegal time format usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@backup /mnt/storage/Homes/donald]# LANG=C LC_TIME=C date -d "2014-01-10 00:02:02" +%s usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@backup /mnt/storage/Homes/donald]#

Tried +%s at the end also.

Yes I'll replace both servers, just waiting till FreeBSD 10 is released.

[megapearl]

Date +%s without other parameters does work:

[root@backup /mnt/storage/Homes/donald]# date +%s 1389868700 [root@backup /mnt/storage/Homes/donald]#

[root@backup /mnt/storage/Homes/donald]# LANG=C LC_TIME=C date -d "2014-01-10 00:02:02" usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] [root@backup /mnt/storage/Homes/donald]#

It's the -d parameter that gives the error:

Manual gives:

 -d dst  Set the kernel's value for daylight saving time.  If dst is non-
         zero, future calls to gettimeofday(2) will return a non-zero for
         tz_dsttime.

What else can I try?

[grke]

After experimenting on FreeBSD, I think you can try changing these two lines in the timer script: secs=$(LANG=C LC_TIME=C date +%s -d "$ts") nowsecs=$(LANG=C LC_TIME=C date +%s -d "$now")

to: secs=$(LANG=C LC_TIME=C date -j -f "%Y-%m-%d %H:%M:%S" "$ts" +%s) nowsecs=$(LANG=C LC_TIME=C date -j -f "%Y-%m-%d %H:%M:%S" "$now" +%s)

[megapearl]

Changed the lines, while keeping the middle line with now= in it (between the two) so, it's now:

    if   ! secs=$(LANG=C LC_TIME=C date -j -f "%Y-%m-%d %H:%M:%S" "$ts" +%s) \
      || ! now=$(LANG=C LC_TIME=C date +"%Y-%m-%d %H:%M:%S") \
      || ! nowsecs=$(LANG=C LC_TIME=C date -j -f "%Y-%m-%d %H:%M:%S" "$now" +%s)
    then
            echo "$0: Date command returned error for $client."
            return 0
    fi

    min_timesecs=$((secs+intervalsecs))

    # GNU coreutils 'date' command should accept the following (even
    # slightly old versions).
    if ! min_time=$(LANG=C LC_TIME=C date -d "Jan 1, 1970 00:00:00 +0000 + $min_timesecs seconds" +"%Y-%m-%d %H:%M:%S")
    then
            # FreeBSD 'date' will return an error with the above, so try
            # a version that FreeBSD 'date' should be happy with.
            if ! min_time=$(LANG=C LC_TIME=C date -r $min_timesecs +"%Y-%m-%d %H:%M:%S")
            then
                    echo "$0: Date command returned error for $client."
                    return 0
            fi
    fi

Jan 19 22:02:01 backup burp[24273]: forked child pid 24579 Jan 19 22:02:01 backup burp[24579]: auth ok for: redacted Jan 19 22:02:01 backup burp[24579]: Client redacted does not want a certificate signed Jan 19 22:02:01 backup burp[24579]: Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 Jan 19 22:02:01 backup burp[24579]: Client supports being sent counters. Jan 19 22:02:02 backup burp[24579]: Logging to /mnt/storage/Backup/Burp/redacted/0000123 2014-01-10 20:02:02/log Jan 19 22:02:02 backup burp[24579]: Running timer script: redacted /mnt/storage/Backup/Burp/redacted/current /mnt/storage/Backup/Burp reserved1 reserved2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,12,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,2 Jan 19 22:02:02 backup burp[24579]: 2,23 Jan 19 22:02:02 backup burp[24579]: Out of timeband: Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,12,19,20,21,22,23 Jan 19 22:02:02 backup burp[24579]: usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... Jan 19 22:02:02 backup burp[24579]: In timeband: Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,23 Jan 19 22:02:02 backup burp[24579]: Last backup: 2014-01-10 00:02:02 Jan 19 22:02:02 backup burp[24579]: Next after : 2014-01-10 20:02:02 (interval 20h) Jan 19 22:02:02 backup burp[24579]: 2014-01-10 20:02:02 < 2014-01-19 22:02:02. Jan 19 22:02:02 backup burp[24579]: Do a backup of redacted now. Jan 19 22:02:02 backup burp[24579]: [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] Jan 19 22:02:02 backup burp[24579]: /usr/local/etc/burp/timer_script returned: 0 Jan 19 22:02:02 backup burp[24579]: Running backup of redacted Jan 19 22:02:02 backup burp[24579]: in do_backup_server Jan 19 22:02:02 backup burp[24579]: Logging to /mnt/storage/Backup/Burp/redacted/0000123 2014-01-19 22:02:02/log Jan 19 22:03:01 backup burp[24590]: before client Jan 19 22:03:03 backup burp[24590]: begin client Jan 19 22:03:04 backup burp[24590]: auth ok Jan 19 22:03:04 backup burp[24590]: Server version: 1.3.46 Jan 19 22:03:04 backup burp[24590]: nocsr ok Jan 19 22:03:04 backup burp[24590]: Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 Jan 19 22:03:18 backup burp[24590]: Compression level: 9 Jan 19 22:03:18 backup burp[24590]: do backup client Jan 19 22:03:18 backup burp[24590]: Phase 1 begin (file system scan)

and the other server:

Jan 19 22:02:01 server burp[73640]: before client Jan 19 22:02:01 server burp[73640]: begin client Jan 19 22:02:01 server burp[73640]: auth ok Jan 19 22:02:01 server burp[73640]: Server version: 1.3.46 Jan 19 22:02:01 server burp[73640]: nocsr ok Jan 19 22:02:01 server burp[73640]: Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 Jan 19 22:02:02 server burp[73640]: Compression level: 9 Jan 19 22:02:02 server burp[73640]: do backup client Jan 19 22:02:02 server burp[73640]: Phase 1 begin (file system scan) Jan 19 22:03:04 server burp[73531]: forked child pid 73647 Jan 19 22:03:04 server burp[73647]: auth ok for: redacted Jan 19 22:03:04 server burp[73647]: Client redacted does not want a certificate signed Jan 19 22:03:04 server burp[73647]: Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 Jan 19 22:03:04 server burp[73647]: Client supports being sent counters. Jan 19 22:03:05 server burp[73647]: Logging to /mnt/backup/Backup/Burp/redacted/0000180 2014-01-10 23:33:12/log

Jan 19 22:03:18 server burp[73647]: Running timer script: redacted /mnt/backup/Backup/Burp/redacted/current /mnt/backup/Backup/Burp reserved1 reserved2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,23 Jan 19 22:03:18 server burp[73647]: Out of timeband: Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,19,20,21,22,23 Jan 19 22:03:18 server burp[73647]: In timeband: Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,22,23 Jan 19 22:03:18 server burp[73647]: usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... Jan 19 22:03:18 server burp[73647]: Last backup: 2014-01-09 22:03:01 Jan 19 22:03:18 server burp[73647]: Next after : 2014-01-10 18:03:01 (interval 20h) Jan 19 22:03:18 server burp[73647]: 2014-01-10 18:03:01 < 2014-01-19 22:03:18. Jan 19 22:03:18 server burp[73647]: Do a backup of redacted now. Jan 19 22:03:18 server burp[73647]: [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format] Jan 19 22:03:18 server burp[73647]: /usr/local/etc/burp/timer_script returned: 0 Jan 19 22:03:18 server burp[73647]: Running backup of redacted Jan 19 22:03:18 server burp[73647]: in do_backup_server Jan 19 22:03:18 server burp[73647]: Logging to /mnt/backup/Backup/Burp/redacted/0000180 2014-01-19 22:03:18/log

Still the usage: date error, so maybe we're missing something else...

[grke]

No, I think it is working now. It is hitting the last 'date' before it hits the final FreeBSD one. If you want to get rid of the error, you can change this:

GNU coreutils 'date' command should accept the following (even

    # slightly old versions).
    if ! min_time=$(LANG=C LC_TIME=C date -d "Jan 1, 1970 00:00:00 +0000 + $min_timesecs seconds" +"%Y-%m-%d %H:%M:%S")
    then
            # FreeBSD 'date' will return an error with the above, so try
            # a version that FreeBSD 'date' should be happy with.
            if ! min_time=$(LANG=C LC_TIME=C date -r $min_timesecs +"%Y-%m-%d %H:%M:%S")
            then
                    echo "$0: Date command returned error for $client."
                    return 0
            fi
    fi

To this: if ! min_time=$(LANG=C LC_TIME=C date -r $min_timesecs +"%Y-%m-%d %H:%M:%S") then echo "$0: Date command returned error for $client." return 0 fi

[grke]

That is, delete the outer if/fi part.

There is another issue in github to make example configuration files into templates whose outputs change when installing on different operating systems. The timer script could do the same.

[megapearl]

Removed it, and looks good now:

Jan 20 12:02:00 backup burp[39637]: forked child pid 40316 Jan 20 12:02:01 backup burp[40316]: auth ok for: redacted Jan 20 12:02:01 backup burp[40316]: Client redacted does not want a certificate signed Jan 20 12:02:01 backup burp[40316]: Client uses TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384 Jan 20 12:02:01 backup burp[40316]: Client supports being sent counters. Jan 20 12:02:02 backup burp[40316]: Logging to /mnt/storage/Backup/Burp/redacted/0000123 2014-01-19 22:02:02/log Jan 20 12:02:05 backup burp[40316]: Running timer script: redacted /mnt/storage/Backup/Burp/redacted/current /mnt/storage/Backup/Burp reserved1 reserv ed2 20h Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,12,19,20,21,22,23 Sat,Sun,00,01,02,03,04,05,06,07,08,17,18,19,20,21,2 Jan 20 12:02:05 backup burp[40316]: 2,23 Jan 20 12:02:05 backup burp[40316]: In timeband: Mon,Tue,Wed,Thu,Fri,00,01,02,03,04,05,12,19,20,21,22,23 Jan 20 12:02:05 backup burp[40316]: Last backup: 2014-01-10 00:02:02 Jan 20 12:02:05 backup burp[40316]: Next after : 2014-01-10 20:02:02 (interval 20h) Jan 20 12:02:05 backup burp[40316]: 2014-01-10 20:02:02 < 2014-01-20 12:02:05. Jan 20 12:02:05 backup burp[40316]: Do a backup of redacted now. Jan 20 12:02:05 backup burp[40316]: /usr/local/etc/burp/timer_script returned: 0 Jan 20 12:02:05 backup burp[40316]: Running backup of redacted Jan 20 12:02:05 backup burp[40316]: in do_backup_server Jan 20 12:02:05 backup burp[40316]: Logging to /mnt/storage/Backup/Burp/redacted/0000123 2014-01-20 12:02:05/log

Now, let's find out what the ssl errors are, and why they occur...

[megapearl]

Both servers upgraded to FreeBSD 10, still having the same problem from Server A to Server B, SSL errors Strange thing is Server B to A goes flawless.

So far tested:

Server A to Server B -> SSL_ERROR_SYSCALL in read, errno=60 (Operation timed out) or Permission Denied error Server B to Server A -> no problem Server A to Friend (slackware) -> no problem Server B to Friend (slackware) -> no problem Friend (slackware) to Server B -> no problem Server A to itself (localhost) -> no problem Server B to itself (localhost) -> no problem

Any ideas how to debug? It's really frustrating AAARGH ;-) Is it possible to mail reports per client? Slackware friend want to know if his backup succeeded or failed?

[grke]

Hello,

The notify_ options can be overridden per client in the clientconfdir/ files on the server.

Given that the only place that these SSL errors happen is on your server B, I would say that it is very likely to be a problem with server B, and not burp. Given that it is very likely not burp, adding debug to burp isn't going to help. You will just see an SSL call return an error, as it is already reporting. When you upgraded to FreeBSD 10, did you reinstall the whole operating system, or did you upgrade on top of FreeBSD 9?

[megapearl]

On top op FreeBSD 9, but it overwrites the whole base, only merges configuration files, and if the os is unsure, it asks and I edited all config files by hand. (all configs at server A and B are the same) Yes, I don't think the problem is with burp, but if the problem is server B, why can my slackware friend successfull backup to me (Server B)...

[grke]

I don't know. Possibly, it is some router, switch, or hub, on your network going between server A and server B doing some kind of content scanning. If you made a new server, and it works ok, then you could rule out the router/switch/hub/hardware side of it.

[grke]

I realise now that a better way to do the dates is to make a small C program that outputs what I want it to, and have timer_script read that instead. I will create a new issue for that.

The other stuff related to the strange server is beyond my control, so I will close this issue.

[BobRyanConsulting]

FreeBSD has the coreutils port which includes /usr/local/bin/gdate which we're using with this script successfully. It may be simpler to add that as a dependency and check for its presence in the script.

[grke]

Thanks for your idea, I will add your comment to the issue that I mentioned in my comment above, which is still open: https://github.com/grke/burp/issues/209