From boxbackup at fluffy.co.uk Sun Aug 6 15:51:42 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sun, 6 Aug 2006 15:51:42 +0100 (BST) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> Message-ID: Hi John, On Wed, 19 Jul 2006, Chris Wilson wrote: >> Do you see any problems? The ExcludeDir commands seem to work fine but >> both ExcludeFile commands do not (every time it stops and starts the >> service it tries to backup the pagefile.sys which gives an error). > > This looks like a bug. I will investigate and get back to you. I've released a new version of the Windows native client which may help you. I think that the problem was that exclude/alwaysinclude directives were processed in a case sensitive way, which makes sense on Unix but not on Windows. Please could you try the new client and let me know if it helps? You can download it at: [http://bbdev.fluffy.co.uk/svn/box/chris/win32/releases/boxbackup-chris_general_716-backup-client-mingw32.zip] Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Mon Aug 7 13:32:52 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 14:32:52 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup Message-ID: <44D732F4.8060200@kontrapunkt.com> Hello... I keep getting errors like the ones seen below when backing up my OS X client to my OS X server. Any ideas? I'm running the debug client. Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught (Connection TLSWriteFailed 7/33), reset state and waiting to retry... Thanks, Tobias Balle-Petersen From boxbackup at fluffy.co.uk Mon Aug 7 14:01:25 2006 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Mon, 07 Aug 2006 15:01:25 +0200 Subject: [Box Backup] Exclude everything except one filetype? Message-ID: <44D739A5.4070902@nethinks.com> Hi, maybe I'm missing something here ... I'm trying to backup a directory tree, but only a certain filetype (extension) is supposed to be stored - I tried like this: nsf { Path = c:\lotus\domino\data AlwaysIncludeFilesRegex = *.(nsf|NSF)$ ExcludeDir = c:\lotus\domino\data } Problem is, it still stores all the files, even the ones that don't end with .nsf ... what am I missing? (This is on Linux server 0.09 with Win32 client 0.09h) tnx, -garry From boxbackup at fluffy.co.uk Mon Aug 7 14:07:57 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 7 Aug 2006 14:07:57 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D732F4.8060200@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> Message-ID: <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> Are the clocks synchronised? Did you follow the certificate generation process exactly? Rememebering that server and client certificates have different signing commands? Ben On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: > Hello... > > I keep getting errors like the ones seen below when backing up my > OS X client to my OS X server. Any ideas? > I'm running the debug client. > > > Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: > ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n > Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: error: > 1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry > Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: > ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n > Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught (Connection > TLSWriteFailed 7/33), reset state and waiting to retry... > > Thanks, > Tobias Balle-Petersen > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Mon Aug 7 14:16:40 2006 From: boxbackup at fluffy.co.uk (Stefan Norlin) Date: Mon, 7 Aug 2006 15:16:40 +0200 Subject: [Box Backup] Exclude everything except one filetype? References: <44D739A5.4070902@nethinks.com> Message-ID: <058401c6ba23$b8541e20$1601060a@cs> > nsf > { > Path = c:\lotus\domino\data > AlwaysIncludeFilesRegex = *.(nsf|NSF)$ > ExcludeDir = c:\lotus\domino\data > } > > Problem is, it still stores all the files, even the ones that don't end > with .nsf ... what am I missing? Hi! This should be clarified a couple of more times somewhere since it is a very common question. It should be "perl-style" regular expressions. So you should write something like AlwaysIncludeFilesRegex = .*\.(nsf|NSF)$ instead. . - Any character .* - Any character 0 or more times \. - The "." literal Stefan From boxbackup at fluffy.co.uk Mon Aug 7 14:17:49 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 15:17:49 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> Message-ID: <44D73D7D.7090008@kontrapunkt.com> Hello... Would I be able to create new certificates without having to recreate my store? If yes, how is the procedure different than the initial procedure? Thanks Ben Summers wrote: > > Are the clocks synchronised? > > Did you follow the certificate generation process exactly? > Rememebering that server and client certificates have different > signing commands? > > Ben > > > On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: > >> Hello... >> >> I keep getting errors like the ones seen below when backing up my OS >> X client to my OS X server. Any ideas? >> I'm running the debug client. >> >> >> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n >> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n >> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught (Connection >> TLSWriteFailed 7/33), reset state and waiting to retry... >> >> Thanks, >> Tobias Balle-Petersen >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 14:21:00 2006 From: boxbackup at fluffy.co.uk (Stefan Norlin) Date: Mon, 7 Aug 2006 15:21:00 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> Message-ID: <05a301c6ba24$537c93a0$1601060a@cs> > Would I be able to create new certificates without having to recreate my > store? If yes, how is the procedure different than the initial procedure? Yes. Nothing special. Certificates are only used for authentication as opposed to the key which is used for encryption. Stefan From boxbackup at fluffy.co.uk Mon Aug 7 14:20:44 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 7 Aug 2006 14:20:44 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D73D7D.7090008@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> Message-ID: On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: > Hello... > > > Would I be able to create new certificates without having to > recreate my store? Yes, as long as the account numbers do not change for the clients. > If yes, how is the procedure different than the initial procedure? It isn't. Certificates are replaceable. But... don't let the config scripts overwrite the keys file. (.raw extension) Ben > > Ben Summers wrote: >> >> Are the clocks synchronised? >> >> Did you follow the certificate generation process exactly? >> Rememebering that server and client certificates have different >> signing commands? >> >> Ben >> >> >> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >> >>> Hello... >>> >>> I keep getting errors like the ones seen below when backing up my >>> OS X client to my OS X server. Any ideas? >>> I'm running the debug client. >>> >>> >>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp >>> (426)\n >>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp >>> (426)\n >>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>> retry... >>> >>> Thanks, >>> Tobias Balle-Petersen >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Mon Aug 7 14:25:11 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 15:25:11 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> Message-ID: <44D73F37.4000404@kontrapunkt.com> Hello... Thanks for the advice, I'll give it a try and post the results. I am wondering though... How can a certificate be "kind of OK" ? My backup runs, but usually quits at some point with the errors seen in my original logfile? The certificate is not rejected at the time of connection? Tobias Ben Summers wrote: > > On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: > >> Hello... >> >> >> Would I be able to create new certificates without having to recreate >> my store? > > Yes, as long as the account numbers do not change for the clients. > >> If yes, how is the procedure different than the initial procedure? > > It isn't. Certificates are replaceable. > > But... don't let the config scripts overwrite the keys file. (.raw > extension) > > Ben > > >> >> Ben Summers wrote: >>> >>> Are the clocks synchronised? >>> >>> Did you follow the certificate generation process exactly? >>> Rememebering that server and client certificates have different >>> signing commands? >>> >>> Ben >>> >>> >>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> I keep getting errors like the ones seen below when backing up my >>>> OS X client to my OS X server. Any ideas? >>>> I'm running the debug client. >>>> >>>> >>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n >>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n >>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught (Connection >>>> TLSWriteFailed 7/33), reset state and waiting to retry... >>>> >>>> Thanks, >>>> Tobias Balle-Petersen >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 14:29:15 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 15:29:15 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <05a301c6ba24$537c93a0$1601060a@cs> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <05a301c6ba24$537c93a0$1601060a@cs> Message-ID: <44D7402B.9020608@kontrapunkt.com> Hello... Being a bit confused, what files would I need to replace on the server and client? Thanks Stefan Norlin wrote: >> Would I be able to create new certificates without having to recreate >> my store? If yes, how is the procedure different than the initial >> procedure? > > Yes. > > Nothing special. > > Certificates are only used for authentication as opposed to > the key which is used for encryption. > > Stefan > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 14:32:45 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 7 Aug 2006 14:32:45 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D73F37.4000404@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> Message-ID: <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: > Hello... > > Thanks for the advice, I'll give it a try and post the results. > > I am wondering though... How can a certificate be "kind of OK" ? My > backup runs, but usually quits > at some point with the errors seen in my original logfile? The > certificate is not rejected at the time of connection? Sorry, I assumed from your message it never made a connection. Certificates either work or don't work. So, what does the log look like on the server when you set ExtendedLogging = yes ? Ben > Ben Summers wrote: >> >> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >> >>> Hello... >>> >>> >>> Would I be able to create new certificates without having to >>> recreate my store? >> >> Yes, as long as the account numbers do not change for the clients. >> >>> If yes, how is the procedure different than the initial procedure? >> >> It isn't. Certificates are replaceable. >> >> But... don't let the config scripts overwrite the keys file. (.raw >> extension) >> >> Ben >> >> >>> >>> Ben Summers wrote: >>>> >>>> Are the clocks synchronised? >>>> >>>> Did you follow the certificate generation process exactly? >>>> Rememebering that server and client certificates have different >>>> signing commands? >>>> >>>> Ben >>>> >>>> >>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>> >>>>> Hello... >>>>> >>>>> I keep getting errors like the ones seen below when backing up >>>>> my OS X client to my OS X server. Any ideas? >>>>> I'm running the debug client. >>>>> >>>>> >>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp >>>>> (426)\n >>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp >>>>> (426)\n >>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>> retry... >>>>> >>>>> Thanks, >>>>> Tobias Balle-Petersen >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Mon Aug 7 14:35:15 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 15:35:15 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> Message-ID: <44D74193.6090103@kontrapunkt.com> Hello I will enable extendedlogging on the server and post the results in this thread. Thanks for all your help. Ben Summers wrote: > > On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: > >> Hello... >> >> Thanks for the advice, I'll give it a try and post the results. >> >> I am wondering though... How can a certificate be "kind of OK" ? My >> backup runs, but usually quits >> at some point with the errors seen in my original logfile? The >> certificate is not rejected at the time of connection? > > Sorry, I assumed from your message it never made a connection. > Certificates either work or don't work. > > So, what does the log look like on the server when you set > ExtendedLogging = yes ? > > Ben > > > >> Ben Summers wrote: >>> >>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> >>>> Would I be able to create new certificates without having to >>>> recreate my store? >>> >>> Yes, as long as the account numbers do not change for the clients. >>> >>>> If yes, how is the procedure different than the initial procedure? >>> >>> It isn't. Certificates are replaceable. >>> >>> But... don't let the config scripts overwrite the keys file. (.raw >>> extension) >>> >>> Ben >>> >>> >>>> >>>> Ben Summers wrote: >>>>> >>>>> Are the clocks synchronised? >>>>> >>>>> Did you follow the certificate generation process exactly? >>>>> Rememebering that server and client certificates have different >>>>> signing commands? >>>>> >>>>> Ben >>>>> >>>>> >>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>> >>>>>> Hello... >>>>>> >>>>>> I keep getting errors like the ones seen below when backing up my >>>>>> OS X client to my OS X server. Any ideas? >>>>>> I'm running the debug client. >>>>>> >>>>>> >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>> SocketStreamTLS.cpp(426)\n >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>> SocketStreamTLS.cpp(426)\n >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>> retry... >>>>>> >>>>>> Thanks, >>>>>> Tobias Balle-Petersen >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 14:48:27 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 15:48:27 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> Message-ID: <44D744AB.207@kontrapunkt.com> Hello... Turns out extended logging was enabled on the server. This is all I get (not running debug server). Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception Connection TLSReadFailed (Probably a network issue between client and server.) (7/34) -- terminating child This is my bbstored.conf on the server: RaidFileConf = /etc/box/raidfile.conf AccountDatabase = /etc/box/bbstored/accounts.txt # Uncomment this line to see exactly what commands are being received from clients. ExtendedLogging = yes # scan all accounts for files which need deleting every 15 minutes. TimeBetweenHousekeeping = 900 Server { PidFile = /var/run/bbstored.pid User = box ListenAddresses = inet:xxxxxx CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem TrustedCAsFile = /etc/box/bbstored/clientCA.pem } ' Thanks Ben Summers wrote: > > On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: > >> Hello... >> >> Thanks for the advice, I'll give it a try and post the results. >> >> I am wondering though... How can a certificate be "kind of OK" ? My >> backup runs, but usually quits >> at some point with the errors seen in my original logfile? The >> certificate is not rejected at the time of connection? > > Sorry, I assumed from your message it never made a connection. > Certificates either work or don't work. > > So, what does the log look like on the server when you set > ExtendedLogging = yes ? > > Ben > > > >> Ben Summers wrote: >>> >>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> >>>> Would I be able to create new certificates without having to >>>> recreate my store? >>> >>> Yes, as long as the account numbers do not change for the clients. >>> >>>> If yes, how is the procedure different than the initial procedure? >>> >>> It isn't. Certificates are replaceable. >>> >>> But... don't let the config scripts overwrite the keys file. (.raw >>> extension) >>> >>> Ben >>> >>> >>>> >>>> Ben Summers wrote: >>>>> >>>>> Are the clocks synchronised? >>>>> >>>>> Did you follow the certificate generation process exactly? >>>>> Rememebering that server and client certificates have different >>>>> signing commands? >>>>> >>>>> Ben >>>>> >>>>> >>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>> >>>>>> Hello... >>>>>> >>>>>> I keep getting errors like the ones seen below when backing up my >>>>>> OS X client to my OS X server. Any ideas? >>>>>> I'm running the debug client. >>>>>> >>>>>> >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>> SocketStreamTLS.cpp(426)\n >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>> SocketStreamTLS.cpp(426)\n >>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>> retry... >>>>>> >>>>>> Thanks, >>>>>> Tobias Balle-Petersen >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 14:52:41 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 7 Aug 2006 14:52:41 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D744AB.207@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> Message-ID: <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> After bbackupd retries, does it succeed? Might you have a dodgy connection to the server? (getting the obvious out of the way) Are the discs full on your server? What are the account stats? Ben On 7 Aug 2006, at 14:48, Tobias Balle-Petersen wrote: > Hello... > > Turns out extended logging was enabled on the server. This is all > I get (not running debug server). > > Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile > (0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) > Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile > (0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) > Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain > Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) > Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) > Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile > (0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) > Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile > (0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) > Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain > Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping > Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping > Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for > BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n > Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception > Connection TLSReadFailed (Probably a network issue between client > and server.) (7/34) -- terminating > child > > > This is my bbstored.conf on the server: > RaidFileConf = /etc/box/raidfile.conf > AccountDatabase = /etc/box/bbstored/accounts.txt > > # Uncomment this line to see exactly what commands are being > received from clients. > ExtendedLogging = yes > > # scan all accounts for files which need deleting every 15 minutes. > > TimeBetweenHousekeeping = 900 > > Server > { > PidFile = /var/run/bbstored.pid > User = box > ListenAddresses = inet:xxxxxx > CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem > PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem > TrustedCAsFile = /etc/box/bbstored/clientCA.pem > } > ' > > Thanks > > > > > Ben Summers wrote: >> >> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: >> >>> Hello... >>> >>> Thanks for the advice, I'll give it a try and post the results. >>> >>> I am wondering though... How can a certificate be "kind of OK" ? >>> My backup runs, but usually quits >>> at some point with the errors seen in my original logfile? The >>> certificate is not rejected at the time of connection? >> >> Sorry, I assumed from your message it never made a connection. >> Certificates either work or don't work. >> >> So, what does the log look like on the server when you set >> ExtendedLogging = yes ? >> >> Ben >> >> >> >>> Ben Summers wrote: >>>> >>>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>>> >>>>> Hello... >>>>> >>>>> >>>>> Would I be able to create new certificates without having to >>>>> recreate my store? >>>> >>>> Yes, as long as the account numbers do not change for the clients. >>>> >>>>> If yes, how is the procedure different than the initial procedure? >>>> >>>> It isn't. Certificates are replaceable. >>>> >>>> But... don't let the config scripts overwrite the keys file. >>>> (.raw extension) >>>> >>>> Ben >>>> >>>> >>>>> >>>>> Ben Summers wrote: >>>>>> >>>>>> Are the clocks synchronised? >>>>>> >>>>>> Did you follow the certificate generation process exactly? >>>>>> Rememebering that server and client certificates have >>>>>> different signing commands? >>>>>> >>>>>> Ben >>>>>> >>>>>> >>>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>>> >>>>>>> Hello... >>>>>>> >>>>>>> I keep getting errors like the ones seen below when backing >>>>>>> up my OS X client to my OS X server. Any ideas? >>>>>>> I'm running the debug client. >>>>>>> >>>>>>> >>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>>> retry... >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias Balle-Petersen >>>>>>> _______________________________________________ >>>>>>> boxbackup mailing list >>>>>>> boxbackup at fluffy.co.uk >>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>> >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>> >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Mon Aug 7 15:06:42 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 16:06:42 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> Message-ID: <44D748F2.8010603@kontrapunkt.com> > > After bbackupd retries, does it succeed? Might you have a dodgy > connection to the server? (getting the obvious out of the way) > bbackupd never seems to retry. How soon is it supposed to retry? My client backups to two stores. One store is at a remote facility, the other is on the LAN. The errors occur on connections to both stores. It's possible I have a network problems. How would I be able to determine if that is where my problem originates? > Are the discs full on your server? No, se stats below. > > What are the account stats? Store on LAN: Used 1388578.2Mb 82% ******************************** Old files 7465.0Mb 0% Deleted files 117210.1Mb 6% ** Directories 995.0Mb 0% Soft limit 1536000.0Mb 90% ************************************ Hard limit 1689600.0Mb 100% **************************************** Store at remote location: Used 1853036.0Mb 75% ****************************** Old files 24185.1Mb 0% Deleted files 391448.4Mb 15% ****** Directories 5432.4Mb 0% Soft limit 2355200.0Mb 95% ************************************** Hard limit 2457600.0Mb 100% **************************************** Thanks > > Ben > > > On 7 Aug 2006, at 14:48, Tobias Balle-Petersen wrote: > >> Hello... >> >> Turns out extended logging was enabled on the server. This is all I >> get (not running debug server). >> >> Aug 7 14:12:18 maigo bbstored[8586]: Receive >> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >> Aug 7 14:12:18 maigo bbstored[8586]: Receive >> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >> Aug 7 14:12:19 maigo bbstored[8586]: Receive >> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >> Aug 7 14:12:19 maigo bbstored[8586]: Receive >> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >> Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping >> Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping >> Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for >> BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n >> Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception >> Connection TLSReadFailed (Probably a network issue between client and >> server.) (7/34) -- terminating >> child >> >> >> This is my bbstored.conf on the server: >> RaidFileConf = /etc/box/raidfile.conf >> AccountDatabase = /etc/box/bbstored/accounts.txt >> >> # Uncomment this line to see exactly what commands are being received >> from clients. >> ExtendedLogging = yes >> >> # scan all accounts for files which need deleting every 15 minutes. >> >> TimeBetweenHousekeeping = 900 >> >> Server >> { >> PidFile = /var/run/bbstored.pid >> User = box >> ListenAddresses = inet:xxxxxx >> CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem >> PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem >> TrustedCAsFile = /etc/box/bbstored/clientCA.pem >> } >> ' >> >> Thanks >> >> >> >> >> Ben Summers wrote: >>> >>> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> Thanks for the advice, I'll give it a try and post the results. >>>> >>>> I am wondering though... How can a certificate be "kind of OK" ? My >>>> backup runs, but usually quits >>>> at some point with the errors seen in my original logfile? The >>>> certificate is not rejected at the time of connection? >>> >>> Sorry, I assumed from your message it never made a connection. >>> Certificates either work or don't work. >>> >>> So, what does the log look like on the server when you set >>> ExtendedLogging = yes ? >>> >>> Ben >>> >>> >>> >>>> Ben Summers wrote: >>>>> >>>>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>>>> >>>>>> Hello... >>>>>> >>>>>> >>>>>> Would I be able to create new certificates without having to >>>>>> recreate my store? >>>>> >>>>> Yes, as long as the account numbers do not change for the clients. >>>>> >>>>>> If yes, how is the procedure different than the initial procedure? >>>>> >>>>> It isn't. Certificates are replaceable. >>>>> >>>>> But... don't let the config scripts overwrite the keys file. (.raw >>>>> extension) >>>>> >>>>> Ben >>>>> >>>>> >>>>>> >>>>>> Ben Summers wrote: >>>>>>> >>>>>>> Are the clocks synchronised? >>>>>>> >>>>>>> Did you follow the certificate generation process exactly? >>>>>>> Rememebering that server and client certificates have different >>>>>>> signing commands? >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>>>> >>>>>>>> Hello... >>>>>>>> >>>>>>>> I keep getting errors like the ones seen below when backing up >>>>>>>> my OS X client to my OS X server. Any ideas? >>>>>>>> I'm running the debug client. >>>>>>>> >>>>>>>> >>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception thrown: >>>>>>>> ConnectionException(Conn_TLSWriteFailed) at >>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>>>> retry... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias Balle-Petersen >>>>>>>> _______________________________________________ >>>>>>>> boxbackup mailing list >>>>>>>> boxbackup at fluffy.co.uk >>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>>> _______________________________________________ >>>>>>> boxbackup mailing list >>>>>>> boxbackup at fluffy.co.uk >>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 15:14:40 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 7 Aug 2006 15:14:40 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D748F2.8010603@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> <44D748F2.8010603@kontrapunkt.com> Message-ID: On 7 Aug 2006, at 15:06, Tobias Balle-Petersen wrote: > >> >> After bbackupd retries, does it succeed? Might you have a dodgy >> connection to the server? (getting the obvious out of the way) >> > bbackupd never seems to retry. How soon is it supposed to retry? 100 seconds later. > > My client backups to two stores. One store is at a remote facility, > the other is on the LAN. The errors occur on connections to both > stores. > It's possible I have a network problems. How would I be able to > determine if that is where my problem originates? Large file transfers between servers? Stats look OK. How often do you sleep the desktop? Might it have gone to sleep during a connection, then when you woke it up it thought the connection was active, but the server had timed out? I run revision 547 (just after the latest release) on Mac OS X myself. Ben > > >> >> Ben >> >> >> On 7 Aug 2006, at 14:48, Tobias Balle-Petersen wrote: >> >>> Hello... >>> >>> Turns out extended logging was enabled on the server. This is >>> all I get (not running debug server). >>> >>> Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile >>> (0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>> Aug 7 14:12:18 maigo bbstored[8586]: Receive StoreFile >>> (0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size >>> uncertain >>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>> Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile >>> (0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>> Aug 7 14:12:19 maigo bbstored[8586]: Receive StoreFile >>> (0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size >>> uncertain >>> Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping >>> Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping >>> Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for >>> BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n >>> Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception >>> Connection TLSReadFailed (Probably a network issue between client >>> and server.) (7/34) -- terminating >>> child >>> >>> >>> This is my bbstored.conf on the server: >>> RaidFileConf = /etc/box/raidfile.conf >>> AccountDatabase = /etc/box/bbstored/accounts.txt >>> >>> # Uncomment this line to see exactly what commands are being >>> received from clients. >>> ExtendedLogging = yes >>> >>> # scan all accounts for files which need deleting every 15 minutes. >>> >>> TimeBetweenHousekeeping = 900 >>> >>> Server >>> { >>> PidFile = /var/run/bbstored.pid >>> User = box >>> ListenAddresses = inet:xxxxxx >>> CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem >>> PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem >>> TrustedCAsFile = /etc/box/bbstored/clientCA.pem >>> } >>> ' >>> >>> Thanks >>> >>> >>> >>> >>> Ben Summers wrote: >>>> >>>> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: >>>> >>>>> Hello... >>>>> >>>>> Thanks for the advice, I'll give it a try and post the results. >>>>> >>>>> I am wondering though... How can a certificate be "kind of >>>>> OK" ? My backup runs, but usually quits >>>>> at some point with the errors seen in my original logfile? The >>>>> certificate is not rejected at the time of connection? >>>> >>>> Sorry, I assumed from your message it never made a connection. >>>> Certificates either work or don't work. >>>> >>>> So, what does the log look like on the server when you set >>>> ExtendedLogging = yes ? >>>> >>>> Ben >>>> >>>> >>>> >>>>> Ben Summers wrote: >>>>>> >>>>>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>>>>> >>>>>>> Hello... >>>>>>> >>>>>>> >>>>>>> Would I be able to create new certificates without having to >>>>>>> recreate my store? >>>>>> >>>>>> Yes, as long as the account numbers do not change for the >>>>>> clients. >>>>>> >>>>>>> If yes, how is the procedure different than the initial >>>>>>> procedure? >>>>>> >>>>>> It isn't. Certificates are replaceable. >>>>>> >>>>>> But... don't let the config scripts overwrite the keys file. >>>>>> (.raw extension) >>>>>> >>>>>> Ben >>>>>> >>>>>> >>>>>>> >>>>>>> Ben Summers wrote: >>>>>>>> >>>>>>>> Are the clocks synchronised? >>>>>>>> >>>>>>>> Did you follow the certificate generation process exactly? >>>>>>>> Rememebering that server and client certificates have >>>>>>>> different signing commands? >>>>>>>> >>>>>>>> Ben >>>>>>>> >>>>>>>> >>>>>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>>>>> >>>>>>>>> Hello... >>>>>>>>> >>>>>>>>> I keep getting errors like the ones seen below when backing >>>>>>>>> up my OS X client to my OS X server. Any ideas? >>>>>>>>> I'm running the debug client. >>>>>>>>> >>>>>>>>> >>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during >>>>>>>>> Write: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad >>>>>>>>> write retry >>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting >>>>>>>>> to retry... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias Balle-Petersen >>>>>>>>> _______________________________________________ >>>>>>>>> boxbackup mailing list >>>>>>>>> boxbackup at fluffy.co.uk >>>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> boxbackup mailing list >>>>>>>> boxbackup at fluffy.co.uk >>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> boxbackup mailing list >>>>>>> boxbackup at fluffy.co.uk >>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>> >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>> >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>> >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Mon Aug 7 15:23:09 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 16:23:09 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> <44D748F2.8010603@kontrapunkt.com> Message-ID: <44D74CCD.6050607@kontrapunkt.com> Ben Summers wrote: >> >> My client backups to two stores. One store is at a remote facility, >> the other is on the LAN. The errors occur on connections to both stores. >> It's possible I have a network problems. How would I be able to >> determine if that is where my problem originates? > > Large file transfers between servers? The client is running on an xserve which also serves AFP services. Large files are often transferred. > > How often do you sleep the desktop? Might it have gone to sleep during > a connection, then when you woke it up it thought the connection was > active, but the server had timed out? The server is set to never sleep. > > I run revision 547 (just after the latest release) on Mac OS X myself. I'm running an older OS. 10.4.2 maybe.. > > > Ben > > >> >> >>> >>> Ben >>> >>> >>> On 7 Aug 2006, at 14:48, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> Turns out extended logging was enabled on the server. This is all >>>> I get (not running debug server). >>>> >>>> Aug 7 14:12:18 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>>> Aug 7 14:12:18 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >>>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >>>> Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping >>>> Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping >>>> Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for >>>> BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n >>>> Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception >>>> Connection TLSReadFailed (Probably a network issue between client >>>> and server.) (7/34) -- terminating >>>> child >>>> >>>> >>>> This is my bbstored.conf on the server: >>>> RaidFileConf = /etc/box/raidfile.conf >>>> AccountDatabase = /etc/box/bbstored/accounts.txt >>>> >>>> # Uncomment this line to see exactly what commands are being >>>> received from clients. >>>> ExtendedLogging = yes >>>> >>>> # scan all accounts for files which need deleting every 15 minutes. >>>> >>>> TimeBetweenHousekeeping = 900 >>>> >>>> Server >>>> { >>>> PidFile = /var/run/bbstored.pid >>>> User = box >>>> ListenAddresses = inet:xxxxxx >>>> CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem >>>> PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem >>>> TrustedCAsFile = /etc/box/bbstored/clientCA.pem >>>> } >>>> ' >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>>> Ben Summers wrote: >>>>> >>>>> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: >>>>> >>>>>> Hello... >>>>>> >>>>>> Thanks for the advice, I'll give it a try and post the results. >>>>>> >>>>>> I am wondering though... How can a certificate be "kind of OK" ? >>>>>> My backup runs, but usually quits >>>>>> at some point with the errors seen in my original logfile? The >>>>>> certificate is not rejected at the time of connection? >>>>> >>>>> Sorry, I assumed from your message it never made a connection. >>>>> Certificates either work or don't work. >>>>> >>>>> So, what does the log look like on the server when you set >>>>> ExtendedLogging = yes ? >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>>> Ben Summers wrote: >>>>>>> >>>>>>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>>>>>> >>>>>>>> Hello... >>>>>>>> >>>>>>>> >>>>>>>> Would I be able to create new certificates without having to >>>>>>>> recreate my store? >>>>>>> >>>>>>> Yes, as long as the account numbers do not change for the clients. >>>>>>> >>>>>>>> If yes, how is the procedure different than the initial procedure? >>>>>>> >>>>>>> It isn't. Certificates are replaceable. >>>>>>> >>>>>>> But... don't let the config scripts overwrite the keys file. >>>>>>> (.raw extension) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Ben Summers wrote: >>>>>>>>> >>>>>>>>> Are the clocks synchronised? >>>>>>>>> >>>>>>>>> Did you follow the certificate generation process exactly? >>>>>>>>> Rememebering that server and client certificates have >>>>>>>>> different signing commands? >>>>>>>>> >>>>>>>>> Ben >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>>>>>> >>>>>>>>>> Hello... >>>>>>>>>> >>>>>>>>>> I keep getting errors like the ones seen below when backing >>>>>>>>>> up my OS X client to my OS X server. Any ideas? >>>>>>>>>> I'm running the debug client. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>>>>>> retry... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias Balle-Petersen >>>>>>>>>> _______________________________________________ >>>>>>>>>> boxbackup mailing list >>>>>>>>>> boxbackup at fluffy.co.uk >>>>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> boxbackup mailing list >>>>>>>>> boxbackup at fluffy.co.uk >>>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> boxbackup mailing list >>>>>>>> boxbackup at fluffy.co.uk >>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>>> _______________________________________________ >>>>>>> boxbackup mailing list >>>>>>> boxbackup at fluffy.co.uk >>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 15:25:33 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Mon, 07 Aug 2006 16:25:33 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <93F3673B-9BFA-4B75-A501-436D9925CEE3@fluffy.co.uk> <44D748F2.8010603@kontrapunkt.com> Message-ID: <44D74D5D.2070601@kontrapunkt.com> Ben Summers wrote: > > On 7 Aug 2006, at 15:06, Tobias Balle-Petersen wrote: > >> >>> >>> After bbackupd retries, does it succeed? Might you have a dodgy >>> connection to the server? (getting the obvious out of the way) >>> >> bbackupd never seems to retry. How soon is it supposed to retry? > > 100 seconds later. It does not retry within 100 seconds. The log says : Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught (Connection TLSWriteFailed 7/33), reset state and waiting to retry... Aug 7 14:26:44 yoiko bbackupd[27003]: File statistics: total file size uploaded 7063447934, bytes already on server 123192787, encoded size 3314257403 Aug 7 14:26:44 yoiko bbackupd[27003]: TRACE: Wait on command socket, delay = 1024000000\n Does that mean it wants to wait 1024000000 seconds for the retry? My config on the client says: KeepAliveTime = 600 Thanks > >> >> My client backups to two stores. One store is at a remote facility, >> the other is on the LAN. The errors occur on connections to both stores. >> It's possible I have a network problems. How would I be able to >> determine if that is where my problem originates? > > Large file transfers between servers? > > Stats look OK. > > How often do you sleep the desktop? Might it have gone to sleep during > a connection, then when you woke it up it thought the connection was > active, but the server had timed out? > > I run revision 547 (just after the latest release) on Mac OS X myself. > > Ben > > >> >> >>> >>> Ben >>> >>> >>> On 7 Aug 2006, at 14:48, Tobias Balle-Petersen wrote: >>> >>>> Hello... >>>> >>>> Turns out extended logging was enabled on the server. This is all >>>> I get (not running debug server). >>>> >>>> Aug 7 14:12:18 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>>> Aug 7 14:12:18 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x418759c198100,0x9b696d3c9c56b06f,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >>>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Send Success(0x1c04f5) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receive >>>> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >>>> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >>>> Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping >>>> Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping >>>> Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for >>>> BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n >>>> Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception >>>> Connection TLSReadFailed (Probably a network issue between client >>>> and server.) (7/34) -- terminating >>>> child >>>> >>>> >>>> This is my bbstored.conf on the server: >>>> RaidFileConf = /etc/box/raidfile.conf >>>> AccountDatabase = /etc/box/bbstored/accounts.txt >>>> >>>> # Uncomment this line to see exactly what commands are being >>>> received from clients. >>>> ExtendedLogging = yes >>>> >>>> # scan all accounts for files which need deleting every 15 minutes. >>>> >>>> TimeBetweenHousekeeping = 900 >>>> >>>> Server >>>> { >>>> PidFile = /var/run/bbstored.pid >>>> User = box >>>> ListenAddresses = inet:xxxxxx >>>> CertificateFile = /etc/box/bbstored/xxxxxx-cert.pem >>>> PrivateKeyFile = /etc/box/bbstored/xxxxxx-key.pem >>>> TrustedCAsFile = /etc/box/bbstored/clientCA.pem >>>> } >>>> ' >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>>> Ben Summers wrote: >>>>> >>>>> On 7 Aug 2006, at 14:25, Tobias Balle-Petersen wrote: >>>>> >>>>>> Hello... >>>>>> >>>>>> Thanks for the advice, I'll give it a try and post the results. >>>>>> >>>>>> I am wondering though... How can a certificate be "kind of OK" ? >>>>>> My backup runs, but usually quits >>>>>> at some point with the errors seen in my original logfile? The >>>>>> certificate is not rejected at the time of connection? >>>>> >>>>> Sorry, I assumed from your message it never made a connection. >>>>> Certificates either work or don't work. >>>>> >>>>> So, what does the log look like on the server when you set >>>>> ExtendedLogging = yes ? >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>>> Ben Summers wrote: >>>>>>> >>>>>>> On 7 Aug 2006, at 14:17, Tobias Balle-Petersen wrote: >>>>>>> >>>>>>>> Hello... >>>>>>>> >>>>>>>> >>>>>>>> Would I be able to create new certificates without having to >>>>>>>> recreate my store? >>>>>>> >>>>>>> Yes, as long as the account numbers do not change for the clients. >>>>>>> >>>>>>>> If yes, how is the procedure different than the initial procedure? >>>>>>> >>>>>>> It isn't. Certificates are replaceable. >>>>>>> >>>>>>> But... don't let the config scripts overwrite the keys file. >>>>>>> (.raw extension) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Ben Summers wrote: >>>>>>>>> >>>>>>>>> Are the clocks synchronised? >>>>>>>>> >>>>>>>>> Did you follow the certificate generation process exactly? >>>>>>>>> Rememebering that server and client certificates have >>>>>>>>> different signing commands? >>>>>>>>> >>>>>>>>> Ben >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7 Aug 2006, at 13:32, Tobias Balle-Petersen wrote: >>>>>>>>> >>>>>>>>>> Hello... >>>>>>>>>> >>>>>>>>>> I keep getting errors like the ones seen below when backing >>>>>>>>>> up my OS X client to my OS X server. Any ideas? >>>>>>>>>> I'm running the debug client. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: SSL err during Write: >>>>>>>>>> error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: TRACE: Exception >>>>>>>>>> thrown: ConnectionException(Conn_TLSWriteFailed) at >>>>>>>>>> SocketStreamTLS.cpp(426)\n >>>>>>>>>> Aug 7 14:26:34 yoiko bbackupd[27003]: Exception caught >>>>>>>>>> (Connection TLSWriteFailed 7/33), reset state and waiting to >>>>>>>>>> retry... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias Balle-Petersen >>>>>>>>>> _______________________________________________ >>>>>>>>>> boxbackup mailing list >>>>>>>>>> boxbackup at fluffy.co.uk >>>>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> boxbackup mailing list >>>>>>>>> boxbackup at fluffy.co.uk >>>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> boxbackup mailing list >>>>>>>> boxbackup at fluffy.co.uk >>>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>>> _______________________________________________ >>>>>>> boxbackup mailing list >>>>>>> boxbackup at fluffy.co.uk >>>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> boxbackup mailing list >>>>>> boxbackup at fluffy.co.uk >>>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>>> _______________________________________________ >>>>> boxbackup mailing list >>>>> boxbackup at fluffy.co.uk >>>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>>>> >>>> >>>> _______________________________________________ >>>> boxbackup mailing list >>>> boxbackup at fluffy.co.uk >>>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >>> _______________________________________________ >>> boxbackup mailing list >>> boxbackup at fluffy.co.uk >>> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Mon Aug 7 15:07:33 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 7 Aug 2006 15:07:33 +0100 (BST) Subject: [Box Backup] Exclude everything except one filetype? In-Reply-To: <44D739A5.4070902@nethinks.com> References: <44D739A5.4070902@nethinks.com> Message-ID: Hi Garry, > I'm trying to backup a directory tree, but only a certain filetype > (extension) is supposed to be stored - I tried like this: > > nsf > { > Path = c:\lotus\domino\data > AlwaysIncludeFilesRegex = *.(nsf|NSF)$ > ExcludeDir = c:\lotus\domino\data > } > > Problem is, it still stores all the files, even the ones that don't end > with .nsf ... what am I missing? > > (This is on Linux server 0.09 with Win32 client 0.09h) Stefan is correct about the Perl regular expressions, but it may not be enough for you, since there is another "bug" in that version of the client. Exclude paths are compared in a case-sensitive way which does not make sense on Windows. Please try my latest client build (716) as well as Stefan's change, to see if that helps? [http://boxbackup.hostworks.ca/index.php/Windows_client_releases] Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Mon Aug 7 23:15:49 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 7 Aug 2006 23:15:49 +0100 (BST) Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D744AB.207@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> Message-ID: Hi Tobias, > Aug 7 14:12:19 maigo bbstored[8586]: Receive > StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) > Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain > Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping > Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping > Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for BACKUP-A: > IN=3315979694 OUT=965309836 TOTAL=4281289530\n > Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception Connection > TLSReadFailed (Probably a network issue between client and server.) (7/34) -- > terminating child This looks like an SSL timeout issue. Did you enable Keep-Alives? (set KeepAliveTime = 60 in bbackupd.conf on the client). Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 8 08:27:00 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 08 Aug 2006 09:27:00 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> Message-ID: <44D83CC4.30508@kontrapunkt.com> Hello... Yes I have enabled Keep alive on the clients. My config says: KeepAliveTime = 600 I used to have 60, but changed to 600 to see if it made a difference. It did not. Could running two clients on the same machine be causing my problems? Tobias Chris Wilson wrote: > Hi Tobias, > >> Aug 7 14:12:19 maigo bbstored[8586]: Receive >> StoreFile(0x1c04f4,0x41874f6384b40,0x219eb70753911453,0x0,OPAQUE) >> Aug 7 14:12:19 maigo bbstored[8586]: Receiving stream, size uncertain >> Aug 7 14:24:55 maigo bbstored/hk[241]: Starting housekeeping >> Aug 7 14:24:55 maigo bbstored/hk[241]: Finished housekeeping >> Aug 7 14:26:31 maigo bbstored[8586]: Connection statistics for >> BACKUP-A: IN=3315979694 OUT=965309836 TOTAL=4281289530\n >> Aug 7 14:26:31 maigo bbstored[8586]: in server child, exception >> Connection TLSReadFailed (Probably a network issue between client and >> server.) (7/34) -- terminating child > > This looks like an SSL timeout issue. Did you enable Keep-Alives? (set > KeepAliveTime = 60 in bbackupd.conf on the client). > > Cheers, Chris. From boxbackup at fluffy.co.uk Tue Aug 8 09:25:16 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 8 Aug 2006 09:25:16 +0100 (BST) Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D83CC4.30508@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> Message-ID: Hi Tobias, > Yes I have enabled Keep alive on the clients. My config says: > KeepAliveTime = 600 > > I used to have 60, but changed to 600 to see if it made a difference. It > did not. Can you check that keepalives are actually working? Run tcpdump on one of the machines to watch the traffic between the two, and make sure that there is actually some traffic each way every 60 seconds in the period between "Receiving stream, size uncertain" and "Connection TLSReadFailed". If you're not sure, you can email the tcpdump output to me. Ben and Nick, I was under the impression that keepalives involved a command request by the client, so they should show up in the extended log? I don't see any evidence of that here. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 8 10:03:22 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 08 Aug 2006 11:03:22 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> Message-ID: <44D8535A.6050708@kontrapunkt.com> Hello... The "Connection TLSReadFailed"only happens from time to time, so I would have to log tcpdump and wait for the error to happen. What parameters should I use for tcpdump? Maybe I should change the KeepAliveTime to 10 for testing purposes? Thanks Chris Wilson wrote: > Hi Tobias, > >> Yes I have enabled Keep alive on the clients. My config says: >> KeepAliveTime = 600 >> >> I used to have 60, but changed to 600 to see if it made a difference. >> It did not. > > Can you check that keepalives are actually working? Run tcpdump on one > of the machines to watch the traffic between the two, and make sure > that there is actually some traffic each way every 60 seconds in the > period between "Receiving stream, size uncertain" and "Connection > TLSReadFailed". If you're not sure, you can email the tcpdump output > to me. > > Ben and Nick, I was under the impression that keepalives involved a > command request by the client, so they should show up in the extended > log? I don't see any evidence of that here. > > Cheers, Chris. From boxbackup at fluffy.co.uk Tue Aug 8 10:34:08 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 8 Aug 2006 10:34:08 +0100 (BST) Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D8535A.6050708@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> <44D8535A.6050708@kontrapunkt.com> Message-ID: Hi Tobias, > The "Connection TLSReadFailed"only happens from time to time, so I would > have to log tcpdump and wait for the error to happen. What parameters > should I use for tcpdump? tcpdump -w large-log.pcap host and host and port 2201 > Maybe I should change the KeepAliveTime to 10 for testing purposes? Yes, try that too. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 8 10:41:14 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 8 Aug 2006 10:41:14 +0100 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <44D8535A.6050708@kontrapunkt.com> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> <44D8535A.6050708@kontrapunkt.com> Message-ID: <31EC3308-4DAA-4545-BB7A-1E14183006F3@fluffy.co.uk> I don't think you've answered my question about whether the Mac OS X machine running bbackupd ever sleeps. If it does, I think that's your answer. If it goes to sleep while connected to the server, the connection will time out. KeepAlive won't help as the CPU is not running the code. Ben On 8 Aug 2006, at 10:03, Tobias Balle-Petersen wrote: > Hello... > > The "Connection TLSReadFailed"only happens from time to time, so I > would have to log tcpdump and wait for the error to happen. What > parameters should I use for tcpdump? > > Maybe I should change the KeepAliveTime to 10 for testing purposes? > > Thanks > > > Chris Wilson wrote: >> Hi Tobias, >> >>> Yes I have enabled Keep alive on the clients. My config says: >>> KeepAliveTime = 600 >>> >>> I used to have 60, but changed to 600 to see if it made a >>> difference. It did not. >> >> Can you check that keepalives are actually working? Run tcpdump on >> one of the machines to watch the traffic between the two, and make >> sure that there is actually some traffic each way every 60 seconds >> in the period between "Receiving stream, size uncertain" and >> "Connection TLSReadFailed". If you're not sure, you can email the >> tcpdump output to me. >> >> Ben and Nick, I was under the impression that keepalives involved >> a command request by the client, so they should show up in the >> extended log? I don't see any evidence of that here. >> >> Cheers, Chris. > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Tue Aug 8 10:49:18 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 08 Aug 2006 11:49:18 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: <31EC3308-4DAA-4545-BB7A-1E14183006F3@fluffy.co.uk> References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> <44D8535A.6050708@kontrapunkt.com> <31EC3308-4DAA-4545-BB7A-1E14183006F3@fluffy.co.uk> Message-ID: <44D85E1E.4000901@kontrapunkt.com> Hello. bbackupd is running on a OS X server with an energy setting of never sleep. Tobias Ben Summers wrote: > > I don't think you've answered my question about whether the Mac OS X > machine running bbackupd ever sleeps. If it does, I think that's your > answer. If it goes to sleep while connected to the server, the > connection will time out. KeepAlive won't help as the CPU is not > running the code. > > Ben > > > On 8 Aug 2006, at 10:03, Tobias Balle-Petersen wrote: > >> Hello... >> >> The "Connection TLSReadFailed"only happens from time to time, so I >> would have to log tcpdump and wait for the error to happen. What >> parameters should I use for tcpdump? >> >> Maybe I should change the KeepAliveTime to 10 for testing purposes? >> >> Thanks >> >> >> Chris Wilson wrote: >>> Hi Tobias, >>> >>>> Yes I have enabled Keep alive on the clients. My config says: >>>> KeepAliveTime = 600 >>>> >>>> I used to have 60, but changed to 600 to see if it made a >>>> difference. It did not. >>> >>> Can you check that keepalives are actually working? Run tcpdump on >>> one of the machines to watch the traffic between the two, and make >>> sure that there is actually some traffic each way every 60 seconds >>> in the period between "Receiving stream, size uncertain" and >>> "Connection TLSReadFailed". If you're not sure, you can email the >>> tcpdump output to me. >>> >>> Ben and Nick, I was under the impression that keepalives involved a >>> command request by the client, so they should show up in the >>> extended log? I don't see any evidence of that here. >>> >>> Cheers, Chris. >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Tue Aug 8 10:55:59 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 08 Aug 2006 11:55:59 +0200 Subject: [Box Backup] Troubleshooting "Connection TLSWriteFailed 7/33" on OS X server/client setup In-Reply-To: References: <44D732F4.8060200@kontrapunkt.com> <05E56CC5-C1FF-4535-BAB8-F12AADA773BC@fluffy.co.uk> <44D73D7D.7090008@kontrapunkt.com> <44D73F37.4000404@kontrapunkt.com> <205AC0B5-7CBF-4744-9841-0EC05565FDA5@fluffy.co.uk> <44D744AB.207@kontrapunkt.com> <44D83CC4.30508@kontrapunkt.com> <44D8535A.6050708@kontrapunkt.com> Message-ID: <44D85FAF.40500@kontrapunkt.com> Hello.... Im running backups now and logging the output from tcpdump. Will post back tomorrow. Thank you! Tobias Chris Wilson wrote: > Hi Tobias, > >> The "Connection TLSReadFailed"only happens from time to time, so I >> would have to log tcpdump and wait for the error to happen. What >> parameters should I use for tcpdump? > > tcpdump -w large-log.pcap host and host > and port 2201 > >> Maybe I should change the KeepAliveTime to 10 for testing purposes? > > Yes, try that too. > > Cheers, Chris. From boxbackup at fluffy.co.uk Tue Aug 8 15:11:42 2006 From: boxbackup at fluffy.co.uk (Paul MacKenzie) Date: Tue, 08 Aug 2006 10:11:42 -0400 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> Message-ID: <7.0.1.0.2.20060808095417.047cc298@elehost.com> Hi Chris, Thanks so much for looking into this. I really appreciate it. I have tried the new client and can report I am still having issues. Right now I am only referencing the errors in the event viewer. I am now having problems with both the file and directory excludes: ExcludeFile = C:\pagefile.sys I have also tried the double slashes with the same error: ExcludeFile = C:\\pagefile.sys Here is the file error in the event viewer: Event Type: Warning Event Source: Box Backup Event Category: None Event ID: 1 Date: 8/8/2006 Time: 9:54:37 AM User: N/A Computer: MYSERVER Description: Failed to open 'C:\\pagefile.sys': error 32 Event Type: Error Event Source: Box Backup Event Category: None Event ID: 1 Date: 8/8/2006 Time: 9:54:37 AM User: N/A Computer: MYSERVER Description: Backup object failed, error when reading C:\\pagefile.sys And the same thing seems to be happening with the exclude directory now (now that I am looking closer at it). While I am not 100% it is giving an error for the regular folders with no spaces and special characters it is giving an error below and I am able to reproduce it quite quickly as it is at the start of the backup (along with the pagefile.sys): Here is what I have tried to see if it makes a difference ( i tried these separately and each time I stopped the service and restarted it). None of the 1-4 examples made a difference: 1) ExcludeDir = C:\\Documents/ and/ Settings\Administrator.MYSERVER\Cookies\ 2) ExcludeDir = C:\\Documents and Settings\Administrator.MYSERVER\Cookies\ 3) ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies\ 4) ExcludeDir = "C:\Documents and Settings\Administrator.MYSERVER\Cookies\" Is there a problem with the syntax above for the one that should work? The error reported is the same every time: Event Type: Warning Event Source: Box Backup Event Category: None Event ID: 1 Date: 8/8/2006 Time: 9:55:14 AM User: N/A Computer: MYSERVER Description: Failed to open file C:\\Documents and Settings\Administrator.MYSERVER\Cookies\index.dat: error 32 Event Type: Error Event Source: Box Backup Event Category: None Event ID: 1 Date: 8/8/2006 Time: 9:55:14 AM User: N/A Computer: MYSERVER Description: Backup object failed, error when reading C:\\Documents and Settings\Administrator.MYSERVER\Cookies\index.dat Any assistance would be greatly appreciated. Cheers, John From boxbackup at fluffy.co.uk Wed Aug 9 10:56:30 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Wed, 09 Aug 2006 02:56:30 -0700 Subject: [Box Backup] Problem with 'get' command on large files Message-ID: <44D9B14E.5030105@reedtz.com> This is a multi-part message in MIME format. --------------030309090806000407010407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have been awfully busy, and have only now started migrating my old accounts to my new server (Linux X86_64, FC5, 0.10), and I'm running into a problem when doing some manual testing. To wit: My client machine is a Mac OSX machine (10.4.7) with the 0.10 release builds of bbackupd, bbackupquery, etc. It appears that the backups work fine. I am able to (AFAICT) back up a 3.2GB file to the store. But when I try to restore it (for testing), the following happens in bbackupquery: ------------------------------- curie:/Users/pthomsen root# bbackupquery Box Backup Query Tool v0.10, (c) Ben Summers and contributors 2003-2006 Using configuration file /etc/box/bbackupd.conf Connecting to store... Handshake with store... Login to store... Login complete. Type "help" for a list of commands. query > cd users/pthomsen/Desktop/bordeaux-DVD-i386 query > ls -st 00032547 f----- 2006-04-01T00:35:58 3079421 FC-5-i386-DVD.iso 00033403 f----- 2006-06-06T00:29:09 00001 SHA1SUM 000375c3 f----- 2006-08-08T03:39:53 00001 .DS_Store 00037666 f----- 2006-08-08T07:26:15 3079421 p.iso query > get FC-5-i386-DVD.iso foo.iso Error occured fetching file. query > ls Exception: Connection TLSReadFailed (Probably a network issue between client and server.) (7/34) ------------------------------- Even with a debug build there is nothing in system.log on the client machine. On the server, I get the following in the (extended logging; release-build) logs: ------------------------------- Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size 256 Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile(0x31e85,0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile(0x31e85,0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size -1141640418 Aug 9 01:47:01 backup01 bbstored[19717]: Connection statistics for BACKUP-0005: IN=210 OUT=75545 TOTAL=75755 Aug 9 01:47:01 backup01 bbstored[19717]: in server child, exception RaidFile OSError (Error when accessing an underlying file. Check file permissions allow files to be read and written in the configured raid directories.) (2/8) -- terminating child ------------------------------- I noticed the negative number for stream size, and worry that it is there because something in my builds is not using 64-bit numbers for file size. The file I'm trying to restore (id 00032547) is 3,153,326,894 bytes in the store, which (when 16 is subtracted from it) is -1,141,640,418 as a signed 32-bit number. I am suspicious that I have not built the large-file support correctly. I vaguely remember that there was something special needed to get the large file support to build on Linux, but I thought it was taken care of with autoconf. Or this could be a bug in the GetFile command. In lib/server/Protocol.cpp:738: IOStream::pos_type is used. I can't find the definition of IOStream::pos_type, and I'm not sure if that's really the right place to be looking for this. I think I built the server with 64-bit support, and I'm attaching a gzipped config.log, so nothing (hopefully is missing)... Thanks for any help I can get, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen --------------030309090806000407010407 Content-Type: application/x-gzip; x-mac-type="0"; x-mac-creator="0"; name="config.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="config.log.gz" H4sICMmR2UQAA2NvbmZpZy5sb2cA7D1rc9s4kp/HvwKT7MV2Esl8k3A2uZMdJdFtYrtsJZNs XZWGomCJsUTqSMqP3Ox/vwaoB0E19JqtyaSGqTgxgQbY6G40usFGoz0IU3IdDhkJ4ijzwygl fvRARixN/T5LyTiJe5OA9Uj3ASBGY4BMUnI3gP/3kkkUhVGft7wO+5OEPSdZTPywR3qsO+n3 eV14vagmI/8GuvTJKEwz+LW+t9fKyJ2fkiBhfpa/5CS+Jyd+cDMZFxpqdY0+528NBhx+r88i lsxavD37SBqTLObgxKjbtE5IK7qNAz8L44hjPfKjHhmGERON9wj5G6kfLXrf23v8mNRmf8jj x/z5Yuhn13Eyqk+fpfq9QZxmkT9i5CXpCmQ1vZ4w1su+1eF9exNRVxtB9b3ndBxrVpJAiVF3 6rpd0+uGZludN6f2rDKFyvdhNLmfFdxCwWOdXH24IO0JIx/8hOgW0e1jyzs2NNK8ahND05y9 vaNJmhx1w+ho2nAMDSfRTRTfRXvF8s+E/1nU5ZV+AmSV/szRnncsYGo38/p57xwASHnL7o/6 LEsf0jC6jgsAnFKiqPwGCb+RHww4f1CAGQ5xOmS3bIj3MInCWxBNhvWwd9FovzsmoqMblnRZ Eqe8UbF8CPIyLBaW6guPg3jEjsYZ/JeySFTIEjSXodMYpCtjaZYuSdFUjuZCeKxbmn5MggEL bvi86U7CYY8AOTM2ItnDmEmgOj0mCUsnw+x4yqnadKy1IRegWj+aSA0Mt9A3Z4mya0vfsmuL FrrO/ASkQNm5Y27XuW0WO4fpSPrPnkkAtn0M5ROY33MxKYM49uKl5TpPL/V/+uzZXM8RLlCg QuQWlugFODmtJX8/6rHbo2gyHJJXT+w9Xnnw9vT0kFh1va6JGaqZmkUOLkFfvfOzvLxmHu6d xuOHJOwPMnIA4ByQvAEtQq7i6+zOB9l5w0cm1NhzUGlBfa/N1TXX2BwsnYK9ICk8ZQNeMkkC JgYSQN9T5dwLeQ8gg6Q9YNArtD8734OWiR9lDy9IFGcEJlYk2n1oXp6+a5y1Gyet9632FwJF b1rts+bVFXlzfkka5KJx2W6dfnzfuCQXHy8vzq+a9T2ZQiBrf/tPmH6aXEynhLstU+xjOpP4 rBZGJB2zIIWhClGay0nCegM/y8UECDftt0fuwmxwTOpFfV6rjRN2Hd6/5CIBT1z9h4l4OkoH QDBQNxGUc7VUqhCaqlZjkd8dspoo6y2eswGsU7305ThOw/tF8UyAXiZsyPyUI8CxquWzoPZt GHYXwJ1OcO93YO26DzMo7YWpKAaYSXQXRr0auw/YWDBs0Qhq+8HX2ghkOBSL9aLGj/oTvlK/ DJ4Hz549j7tfA/5PjT989W/958DUDBj93O/5i2a8pubfZS/72U0Bi16ahjPsBQhXdTl9AIWj r7ejI1Gs1626UeMoid/q2tHXZD7sYDx5KRboMIAirmxeYjxsC2KSUdxjw2MiSLrXD4LZpFs/ e4rCRQ1U5uhssn5CZukx2a992iexIDYZTUApDvxbRkDuJiMWZXJPM6HWi8WOoa3SHz127QPL SDzJxpMsN7P4Qix3YeY4wh9ezJeLOpBBYCnBOdgQHddYaDe/Dm+Sa4t6/27AQEkkQlNIeN7F yU0qtfMAqfrRcn8eioSrFfT6A5O6cnUNQeGOkxlsTliI0ykeUC23KwwsiuUqu0T1dHIN853E 14Tds2CScWEuYeFOJSGeU3kdxV3OXGSwVmE9kSrs8mKyQAtmJAtyCZDx4uwTeAUlbMrIuDaK DJfLGTISkTzJnCjRfSI0LpcDbjwXZUHqwrA3Q84zdQw5z4T2gtK1b2Tvp59+Ir/9lj//zI3d eYcskV9remhv3DLJeyu0lcdsWWhL21WKp8dNkiUy8UH7AdfDoIQlsfTm6z8ot/5qqlBUfjyu lHagCkWXVapp66hC+exEWuqWkirUdoqjrJ0bK0dKHVT9UsfZZaTUoWhvfKqsGSk6SWAJ0Tca zfT5GEwtcj2JArEu7IdRBo5rGB0c7h9LYDqQFVCPE1hI+Gq+L1xZbkz1WDAUlgNYMxm32FKw xpiMEraekGsf5mCPO939xB/x/o73fiNHTwW6sJqk9QFYcU+PoBD+PoYS7jRdNE7/0Xjb7Jw1 PjTJo4UD/QiBaTcuc7BufF/rKsE+NS+vWudn5BH3vDGAq/Zl6+xt8W1EBXry8e1l8+L8si1e +l/XQ9CKD+Am1yc3j/LRMTDf0REC7eFfTn1ycAi//R/8CMPpwDIOX8ADIfm/CcsmSUQ0/vSv SpKXpEzuRdd3GA00w7QrFLtrRmNo6EpqaFxdo9bJ3DJJJ+Mx2K8pWVjFUg+uuRU9XIwfhsat nR3ogRpDUEzX0gM1Vw2dm0q4RjZ0AzOjJFqFo/GQccM1FUZmOvaDUh8W3YZauo3KINjCu1BL R2cWFNvrqAVWJ9qSk19BLWPJQgT3JfGTh9kuJy+O/IjvKLGx1NKylw3FGbFWmYuGYWNGEBTv YgRBM3TQhoMYQTIAOklN0ypa06CdE/a/kxDWKAnKcktk477rp6lDBkq4NvwmwbuIVY0SCxqS JYqZHmaYQLG7C8VM1NyCYnM1xUyKTmNLo0rxsgwqbafd8X3vZBLNPatxwmANh+mXxhKOlqNN CdaU6CPD4PhQT910bpLYx4Y3t0r8oMNZfR+mGWiF+uCYnMWgUYNB7okCe3sgAUEWJw/FN9ma VdkmuW3yOOQjI51OMB5OUv4jDJCMga3x6PQRuY3DHkmz3vFxbpWAvXIIQpCARBwcvpi6WfN6 bpw8BlsnvC5g8q7xqdlpfj5tXrRhUFflGk6QK8C2uVTzvnXyT+DQCgPqcRgFw0mPkb+XJeGV xG/LlDZIQcKkasddK7O2i85kR7P/IJl1dL2S2b+QzDp2eYFn/UReyR1p3x8qS3LtuOW9u8bZ VYuckgHze2BOlfdqDIfa25hProbaA662kz3gaqg94OrrNkUABLUIPM3cZu0uDc7T0EXK41jm W/HlZdbTUXJ4htqK8+wyh9KH9Ih/VAKBkQCdbZw8w3NRU9Rzd3HyoBnqVHjeOicPQFAD26Pb kiTN/KyiyJwiWQ+s1ooeC3ok8GtFjxk9RmwE1kNFD1k+KpU6JwhYRNUiU1apYVQtMXN6TCKw Snt/UXqYJt++lI3vXpiJ+LrpNlsR2jL1bQzN2pB3Jqg1j+gZ9uB9fsQ/rYAv0ZvCwEuGQ3AF AZlhb/oFAJw9Pf9CwG2iSSojUn1z+ZF8xFnpVfv1aedds/Ea6CNVCPCrL1ed9peL5lXnHV55 1W600br2a3gVXsPpjNV8aH44v/yiboMi0TprqxFsv4ZqrObjWQsqpzWrvpFB3fktqIMQnGYe utsPAoMvYcBLf8jFOov5aiZCcwVf/SjfbFm43CuFochceNcvPHqAwfT3E9Jlgc8fxCdSEcc2 8rNgILZBp1/kxKvja+ILvMS3ujzSK4wIj8oF0IiEWTqPuilgfBdPeAxkFg6HxB+Phw8zjMXL efSQ0DkH4ksg9qmwBLLuY+GOqqo2BFKNAn9cKa1KaVVKq1JaP4bSCiZJytJKZ1U6q9JZlc76 MXRWVCmtSmlVSqtSWj+M0hIv2EBdcbhKZVUqq1JZlcr6M6isrTa1KuVVKa9KeVXK68+jvDb3 EyvdVemuSndVuuvPo7u22OSqlFelvCrlVSmvf7Pyci1F6g1Lt8uhXz050trSva3OBMpRcZaO HuKDYkNxrgCqsPg1y9AKZ2mtulk3qFRtlHN1IAdET1hyw4bsgbw+wbrwNj0pujj8eJSNxkcB SMvV53/q9VjONPAr59r+cSm9WOYnXX84TI9AgeVKs6bVde2o8IJjfrhzEuXThi8B1yxhUSBk /ddetzPNqLO/5UoBI/SwlWK2RPBW0wRM08abrCi57FcLS7Ww/CALy+JEGo+CjvlBtGIh13+v csWbpwnhv4AWD54L9fz0Kfx+O9PEhBxw1h9ygNsXC0F5fTKTzs6Hxn+fXwrQvMevcfJ8FEbw 75gvKrnqXkzqgyc5yJMc5okAmqr58JoccEzIK6IfTufdOIFurw8e/UevLv7+T/ToefntUkHr TC64aLRP3xVeUG5MXr7MsSZPnpByR6KSIwqVU4QIKXfOgfJhTEGKCxUhbJgyuULPJ8isHLT1 016Xp8DsdeMxiw605yT/C29617h6B7/PB3AAkIcAOK69CoZxysTzevLpddAMQLsCKG+4HcLT Gf2vXM6KmtfSne3ch163vJKKHJHL66LFFz58JbUM7KCgrduFSHD+pmKlxY/w5+qquFoucriV Vk3XsLz1C2+fZTxtXPehlCzNNVxvBV3KlAGiIDaGa3jYOF2x2m0dee8aFDvXCMXWyrQDAIDl ZnFNx12fqME1XWs9FdPBJOvx9KeFhpZm/X4CWjpmpEHxLomtoBlKCMtAElvJANiZc9ei5gYE tKUMDlxLpOnwCH7qAxBnvxsOw+xBamAtZ95ZcbwD4NFR2fYuqXegGSqytr0u9Y5rOyivbFeZ agbqLCVtxtCGm5YS/DwlWpOoMgS4NmrYu4465Y3rWOUz3hIuEqhtqLtxyhrn6up9R+SeFBlN oDMJnG6jYqAx321OHsZgaysnjKuh7BNnurcXBhc9Se26+hqN4+ITzTXVLHCdsrvX/HTROQ3H A5a0ojDrsPuciDkFpKbU2IKOUwrOKaoiJMVOwbueZuxCSE/DXEfXW7AFJyR+lN31DGVCPddz ygqbp7HgR+rA7Pd5xjhumabkdetSauZ5W2kdkVsQwYzuJGgUzWAAxYigyVqHoonHXKp7SgpR cwOPnCsAIJzUzlm106qQszViRh0cfXcn5U1dlCnURZS3BOBhKhOEVlu/wHm6V9Z6q7NbeKal lF7PtMvSy7MO3PnhXH7DlFycX7U+13WRj8zPwu6QSV14y8kzVkiyZ6JmFRTvkj0DmmF6wxMp 11dKsmehqtuzdFtJLcsqphTlCWl5VmmFYeFZ9naEsRyUMJazE2EsNLeaZ7nrCYNKtWd5ajGy JJksEAaxKjwp35XCqvBsnDu2WhN7tl1OKb9ARIJzlAdgSxyeZvr63Qye7eYB7bmTNk2INO99 s0xIBfmoPu9Uu3A/1C6cVPO6jPTJ0k6TpaoVW02movbiHHAhBi2/8PyiecY9A/6D4ANUhBpk bFghAJ9efrlonyPjal02l2ixnvm/NFooAZufm6etszfn6zYyFbuY10vixYvJAniRcOmVJP/F lrnsLTfM0xIttSsOttRomrnn1VIxDGbWU76b9pjMMZhKuChU9TV///IAptNg1ufPEi+ePJGn ROkls1QypZcUschz7yiIN5tOWCMlyRczTW62SFuiJJSYhcuECqNsPaFmU1V+6SwTRgnVWfV8 9XqlNBKiWG0jLJbW7U2E+ccx9/csp1UyzGo5rZbTajlVLqe4hpM8EFnDLTsg8y6U/kdJR8ru x12v8i3L64agyfd1KwUOu3mUCeuz+4qpJabOqPJ92TrFYjfGpmE/8lXfmP66nJ2T5fuydobG prwV14stBvGQDuO+ireOtpwdbhVvHR1LDwfFu6SHg2ZYMIDnGOvSwwEI9o3Ec0z1/qcjXdo4 JwvGW2d+I8UK3jroPRSe46pRkC8dm25YCzRkKOW9UCXeZuGIVZwtcXZKlO/L1xyJTbnqSjfO RCwDwy87CiMVb13k9qBVvHXRS06geCfeuuj1QZ679vogD78tznO9FaT1qIo0GIddugGH8Q+s nrhXToGG55Q5XERFhlTzWXzwLKqgo7EPfrqKzVTXtmIz1bHs5x5dhKxsw2aKBrJAsbOOzdRA BYSayqtLPCrbIwXKYFymtrmey9TGsXCVWFBxldTSB8UpJhKgoW/B5DQOblhWcRnh8pw035/N M1R25/Oq5fgvzeUVS/Ify+OlZXk1h70lUxy96MET8S1bdZIHKWzYB9Wssqjd+1mWKGSNas5W sgbwmKxRzd1F1qiGXroDxetkjeL34FFxc52KMrQsazPKIMIGc3C9sAEQioVuqLHQl8KoCphI gK5S2qi4OG5dpBG4+TyQpdjOWBmUvVOkETUMzGCE4l0MRmiGUtQwEYNRBsDsNGpqBTtNFWlE Tb1MzkknjDKvI73CtLabKqaFThXT3mmqmDY6VUx77VQxUY1ITXX8LDW9pXTxnCC6I1NkEYq9 GUXwqGu6W9Q1xaOuKRp1LVMEj7uGtUitVi2rPG0FRUyjRBFnq2hHiu87QfEu0Y7U8rDdNCp2 sdZQxMNpSZXRjtTWyuF5giKOJVPENo2tKGKjV2dT29olPhaaoWrBtpD4WJkiNnoXJrUdZZg2 FVfIyRRZ1iI2dbeih4NefQ3Fu9wwSR18Bjo6csOkTA8HNTKpYyhdWOqY5bs4J4gScZytjiUA PCqqzk6RrdAMnYAOFtlaIgga20odql62Xa0cIDxBdIhrbLWHTl306noo3mUPHZqh889de3U9 ddGr66lrK7dKqOuUz0dMEBUi9nW2IQh6npqK/Z7tCSIi85d78xaX4KkI4qEX3lFPV1uHnonc W9ON4+EsSpnDxsko5QejTymV2nrLN0mvIpPwNhD06C5XSVMPvYMWitddJU0pTmCqm0oy0aXL kTsnQCQJxNxQaKbP8kH2/flZ2MP9YwmMu17TQJx98dJ9HjpDeFaTHguGPpiW/DxJNghTkgbx mKlas/sxCzIRgROOwHSvQQEMVxw67DIYEyP7h/vA5xsWre3jV4CcNoomI5aEAR9rmvlRJrd1 dsF+RtL5YloFElWBRFUg0V8rkEiqu/gFpexl823zM8qm1tuzBjp4wOD9OSor7daHJlZ+1my3 4AfEQiWxF43LxgelOJ+f/qOJCzSfCYqXrp0lKiryus+NdvsSlVEu216nragBU1lVBUajqgrM J6xK+Sb1i9TvKb6mCtiuAra/f8A2ljWK57Q4EGYOeXpItDy3RTGzBQdIw28shv8F3OEyzLpc U5Q6tLjHKFUtHWH0o+kpxtrUkucVwlQrtNM1bbs4KmiABlLx8l28QN4O812gfG0sFYfBHEEo V3+7h0paNOnvBiwbsIR0HzIe2N5jXDr5Ec1u2Occ9yOpsW5stcnEG+DD081dtpl4O8zl5OXr NpoAxsJZpztbnrrb0IPh3c58ACDnVv5Loe3C93gx9z32c97sy+Nwq+N8ldtQuQ2V21C5DZXb gL8GxO3k/HzG6U08ipKTIFVMo7Be5UsHZhlyC/PkSxvm2CVIOPn5JTlpve00z163Gmfc2uPL IayNZGprFPTsBhahrpma6uQL1BnFj82ARxRHNX8Y9kUiSwdem5E7MHmIH/AjNSwVK6Xcxb8/ YQjvFLfaTB7xgaZb43XYFjKUK09HQp0UhlEav2lsMn7L2CbB0Ybjt9DPKLzcVI7fMrFNbyi3 deX4LSk8tDR+x9po/HRV3tZdx48mGNE1m6ehVYzfRj9OQnkxS05p/Lax9N047HUybnTiIVPQ xFZ+U4NKpxy8MYp7rFNClG4Vu8Eb4Jx1tF2iN3g7nFIi9H6Ng+CgUUZQbigjOKDSLOe9iq+v S1RxtosNhwZocDgv3yXYh7dTjGxtfDiHwV0ux1Med4FKWha+MRc+Ccbd1pl0Fc6ku6Mz6Sqc SXcDZ9JVOJOuOr0cVC7HpIXfylPI3S6RFzRAM3nx8l2CW3TNQ3N58fJ14S0cBgsagHJ1Oi+o RD7GJpMgzzNdT7PO9dDvl5rYG36D3farY+G7XQGJfTIQvjsZsVGXJYQnG+1xiBy1/RJutPLD Kz+88sMrP7zywys//N/kh1df9qQBVF/2/pAve1wYwqBoj4G73PH7/WT2WW/6ODfTeMttPuuB vbRppO7/t3dt3W3jSPrdv4KT9Fk5vYktXkSK2XXPcWy54x1fsrHTST9xKImytKFItUj50nP6 v28VSIoECOgWOZPElb7ERlWBIAACXxUKVf8GLOfO1UnCcoTlCMsRliMsR1iOsBxhuR8Ry+Uu Wl8O6VxD5aoFNGuJtW+MN8KTSdDjxexvxOI3b56AFG2y+hFSJKRISJGQIiFFQoqEFH9kpFiB iHM8tDZMRA/2bxnToVs5YTrCdITpCNMRpiNMR5iOMN0PjOnq1r8vgXam0gKos7SUUgtg3Pvs 9/tTbxTtAWDwwiDiBZ3HwYsY6UjEi2VTVLAxa6CAGNuEGAkxEmIkxEiIkRDjFyFGtsEqL+JV SdWw9/ldvNVAQLnHKe072Sa3/v6vrxpc79+2VesmXZenrZq2atqqaaumrfr73apFtX3jHbvl KDV23W5LggbB5wQTDKMFFRFteCH3cTx27Epk0KwJawTXxGaRow7t+7Tv075P+z7t+1s61JnE YbgsEE6Ea222YbGtuDf0p9rPE9iIdrMfX+RUbiFdae82DFO5dxuWLtm7ry69d53O+6P3nWPl Bm7Y64Wt0A1HGrYCyjcKWwFy0rAVutFeGrYCeKTBHXTDVYet0E0uQ1XRV3mqLB/mQCVz1th/ 0LpxOtS6QXEcw3efuWpk9LmANIkGlm8SUB/kWvLhMFvLQuojjzTWhm7ayqD6QHRcSfflEDYd 40Qros9kfSjLyqnrVnO9wCAgIG+spW8UGATk5ANh6UsDg+iWIY2eoVtmJTCI7KUtMalJ3m/9 0TSI0r2+hyoFL2KvleIEBKRpwLB8kyQnICdNzYHly9KcII808I/espTJgYDYstUTjOsonGu3 fjjiP8mWa2w9oBNUKp8tLAONPKCTzsIbSWRsXR26VbdNMagOns2O/FA70jADGSgwUy2eoPoE 2lAQwIKU5SzzpzeBNgCyUJ+zViILFJCvx3Z7k1QWKCefA3Z7WTIL4HHli5tjqtVYp/aNeSen Z4BsT06uAEy9Ob2+wkkzC1bpPcdZKykXCCi+FqdMG7VW7znSXFJQ7i5LzIU88pWg3VIGFNPb tjj9vLPD96BlYh+u0XFtd8190ZXmBsbyzfZFV5pWG8uX74uuLt9q3LYagbmubNU6O7sE7fL8 8JMKfxksD+YaHQUC0hlhNM1NcjahnDSyFJQvy9oEPJZ0thvNBTHmDL0l5puZTINXk2mMEfrY b/7N2NcyqC6IOiuCBkmIZdhAAMw1njcQnuQWIBVvI2tDQ+vHQWZzwkMmzdfE7Rla1CZDExma yNBEhiYyNJGhaQVDEz89O0dnXn7E0pQSqzacqjgblI+n12/nQyRdPz4cXRffwDEbrDrXb4dn p8cSpsUnYdmfeWs6VyDbOYFJqD3PN/AJ7Ca7+osKd4ULq6nuo0ZTCa0Mg4u+ipaFLJK0Ig03 CFgrovb5XSLntVEeOFWf8Fq7iLVk1hsyjIu2DNRAe2k8FR7ZahIOIBxAOIBwAOEAwgFPAgfQ dSe67vTVrjvxnlcFPPuFB2HOAhDpOCoQiZmCg6jHG3aMdnHu0uHBI28zMr8YOLp0mYiAIwFH Ao4EHAk4PjngqNzLTV29l5tW7Yy8Ug/P2mqtaFfyk/E+ZkhlCVK/3LRUNww1hfKNDoRBTn78 Z9hLD4SBR3ogzOMm8biOB05iL22AnerIp6keebE19aEXWqQefbEqyxTPIRF5zLw09rqBbfG8 9nreSiAgPUI2LGcjbyWQkx6PQ/lSbyXDaku9lQzLXdDRLUNMefVsvx/c7s+mftSPx8945qo/ hliTretCTTdBOo7SIEp5Pnv7iegMW54+Gco3yptk2Iq+tEv/jlJa4JB/uLardraT9B0qwIOE Om5Jxzmck2exReS5LAXOBdW0bXGNyCauUEe7vZ4TrdGWOzZB+UZOtEbblTptGW5zqROtofC8 MVxd7UQr6RjsX+ic1O9u2jmFUu24olJd1LuqUl12LynVpFSTUk1KNSnVpFT/EEo1x3R4de5h 5m2WeFv2Jm+uPh6+sy1+DcnLeG1H/D4OL44vz+Flfzs94h/MUwSlQKjl1871+cU1vIGsFw6v TxTfufKryCpbdmNrJ/M4kR5PZQS2JYqP2ykcVZT5zxmxcmerZsoocMovaiAl2CAUOCqeEcY0 3Fpy60pgOxjwgQf9HUfomsvLtR4nghx6f+egFG/hBzd+GmCAGmxMcTU/C04DkyIeT8IA6Oye Ct4q6/kROhJ3g9yzmXcDd206BiLESoiVECshVkKshFh/SMRaEzu//LAGnN0Gaq1z5lhzrUBF HOQRwwlWYNnaAYrMx8oW8YjYzaQMEoTdCLsRdiPsRtiNsBtht+8QuwnxJb8MwqmzQpgsMIDK pHertumZTYyr8VVx4e0WgOE89AkBQwKGBAwJGBIwJGBIwJCA4TcKDG8fyaoHUOj7Q2+6SeiN 0BuhN0JvhN4IvRF6I/T2/aG3bdr1dNtQ2vV0p3bdJmtXfl0G/vL6oykv47bXcmg0jab0ShKU b3QlyTR06ZUkKJdcSeIdGoFHeinJNBz1jUOT3YtU9BL6jWIvsbGfcGIsYP1aF2js1+g6ucEF mnXxtyHD39nDvhR+w7AS/Cb4TfCb4DfBb4LfBL+fHPyW9XgufX7BOn9FlK68ByS/u7M66uaR jmgyLeHc+mDbXDXgxI+F+WyKpk+YjzAfYT7CfIT5CPMR5vteMJ9gaP0i6OdaSjurZYgWxBvA grfBNEHQZmosIxdgBF4IU06uY2i1WnLDqFXmlFzL0GrJ80yalq0vNbRattzoaznqm+Nmq2VK knH1wjgJAPvmfZ8wDMXLtbefOhAqld59h3Jl6kCz5UqjBpp2Uz037FrIKwbTPT/1QvikeF6z tb0XXVOB0PVSg2hwTVwnxbtpWzrpCqQrkK5AugLpCqQrkK5AuoJcV+BrR/mrxToE5TWhvCZf La+JTOHkQLG223ypwb/PnuV/vVhNjbRtZdQxk+X4nqsKeR3MRg86bDK6ifxQG8LnHoJiyQk6 +oqO3KWANPu36RjNjVRJx5AGDYdye6kq6RjSAGamg1mMi56q6YQOF3G80CVD/GBBTZkGA/gv 6gWJ5mvJwxhG7HOWsX0wAjXkbpQOMW3wFLQSBrJDPxny1Tvu9lVOpy0N/WayLOQKlVORadxs N9tqRbttuJLOYX3j93rBJIVuibRgPEkftOxT5cVb1vZfvi2PkA/lrvLl27Y0YHChRaJaVIwm vtwsIaWTlE5SOknpJKWTlE5SOknpXFXpnL9s5xoWBNb5DHGWlDO22Zxcnp1dfoRP9ezw6m3n GJpxfnZ68Q9SXElx/YYV18plFC3pzgaZjprhP1a4i1rsfyDphfZ3Tddea80V1dm2o1Zn3aYk w9AkAMVM0OXc1pYy5eyn48l+r3d3dvN7+mEv5o++/omd0ni9P4zHwf4khb+SINpP/WnXD8Nk H8B0BuBfNff05n7lma91vfVam0XZStDX5sqlBs34Z/lOjdrzd/f6fur/Z/O++WK1CnpxGAa9 FLSesJ/3OvDr2VhlKg7fc/NjWFJ8SPEhxYcUH1J8SPEhxYcUn29B8QHCcVZJiXEQ8vgRwNQo 7s3iWaLd+tORH6Uv0aeo5yeAa8PReJQilC78jZKK/B4DpNoJ+lHd+3iP4aX29t2rD580XR+p ZNPROIgHff9hrpL1a+2at8iroFSGj+A1rh6SNBhrw8DvB1N8hVze85J01gW43ZvGCbtJMYwn wWAWhg/aILhDBJbGTDN4mbVbuxuOekO8b8H6KxwBLmf2697Qr+Jjhkm6QRjf5S+svWOosfqG 0Iz/9pMkmKIGgaqG57GtxdNGSXGP46UGuKYX5HVUhAHkJGmiBbdBpAE4HkwDALvwAoiC8H7I CA+ZqiCxgFfZI3hNZF4tr/wU5Hkjq6AKf2aQWJP09+VtMJ2O+ng55QF9KQ3UawDJ+WHZpWwm MVSHZxl4Nlcq3AuhYK4VzVsCz/sYAAAMskHoBj0ff2GecqObIfrLpTBm6TAQz+R81rasc7uz UZjCHMZJAKwwxfGUZXozGwdQUdnqu3gWIhAdhaHmTybhfE5KZkDWuGt48K8XH7QjDbTqqT99 yAc3yXzwULEqlJwkn18AcEf4beCzk3zwsbvCO/8hYepBNus6F5ewoEALrkApqtQCH47m99KZ jxMZ4xL080oS4IOnMqjsT1N2vIQVwaTLXxy0wOkYxgmlcCLC4PjhyE8qg1NMTm03+34qX9wL PHAUyV6VgfVU/DnQxkFltrHO2/0Z9NfdF6ANlfw8kJdNjL+EWSnToPNxH2h/E+teriK7bXXg 1bqKHMLL3UWPox7LNcemUL5Z1AbXkTsnu86SRLLAIT8Y5PpNPOGsd1wCwzKNYf6mYfCo1oXf J+YwvNimdcFWGweqb9WotWAl+wJfBVkYyMJAFgayMJCFgSwMZGEgC8N3YWHgF8Ojt5cfL1a1 PFTRz2a2h2oN27U+cG0r7Q8ckv3KFgiuSU/IBiHt8ydrhRBnwVOxQ1TfW2GJ4FhWskVUJbZv jRBr37Y9Aq0dj3Vc/+PYIyyWIJHruM9/zIJZwDPZW/Krzu0Any+c+/F4m5YIR21GyN6nUXv2 SjaIQnhN64PVdCjaJFkfyPpA1geyPpD1gawPZH34hqwPYg+9Oz1e1SqR4aHN7BGZ7HYtEXl7 ShtEjl6/svUhb8YTsjsI/fxkLQ7lyD8VW0P2xgorQ05cyb6Q8W7fslDWu9SmYDXdlsqmYOmG UVGN2eWUh6QHvbw3hMnnd0fhKH3gJcwVMyvMBSxpXC4otzYxHoCc1ARg6a3msuvswCO9Cm/p tqk2H+i2o+yjCQihIs0LoJGCdVGH7xueqy1vi9Fc0BbDbIuuFdX28LyWOq+GpeumUFFxY0Vg U99ktwxbrCNvCMfFklJs2SIFlUpjJFimuVGMBJCTD4ZpSmIkCBzSCAmWiQEBV+85WF0es+9y w9BD7+h/jaMtGqWwfSq70vyVGrXHr2SXqsiva5oqpweZpsg0RaYpMk2RaYpMU2SaItPUN2ya qn//v18dHZ5JZ6h6y8iFVjV2zUHWZvauufh2TV5lq0qrV4mQv7Lhq2zME7J91Xv7yZq/uPF/ Khaw+UsrjGAlfSU72Jx9+6Ywrurl1jBOLxesYRZq+/XQfPnow4sFn0H0j9kI16/+bDx+0FiG 2kBIH2BZ7S3Gii8rlaYEsCwMfC8P0gc0k4L0kcJMCjMpzKQwk8JMCjMpzKQwb6Aw51g7+0Mx Aylm4FeLGSibdoNelIZlgrbarKweCYtMDNyyRnjz7+WiA1/icefkguPVqqg3Hgy8tNS1dv+Y +X0oiGbjbjB9qe3t7eVBCedPkr3AIJo/PX+28MTixs/c9sAR88+2UMiqNgrJg3fkuiPHjAaF wRDUo9408NPdZ0zHQy0KMwfYzabwUsiOut9BkZhuThjsDoa/HDRfcKX/El4gEy26ED939ryX 0ASWqOCq0/mHd9W5fqm5rvBkLUvFBk8RCH9xv80ijKZffQ+BPVeMoSV/O3il/1fRH8u05lY1 or2gNbdMQ4yTAfP43k9TXilutbcftt9qudJMcVDubuQIYDelaQCgvLXEEcBuytVz22iqHQEk fUedt3nn3QTUdZvOO+q7jfsuoa7beNpR363Ydza6ttWM05n94eIy06uyQ6YsDygv3Foxn+2a iUkx726Rl5RvyjqJSS3bpsSkZH4m8zOZn8n8TOZnMj+T+flJmp+F5fjqmn3eEtICGjRQJaUm XamFONIqaXQekn0G6DPTo8IIV5gCeczIjFDMc+TnCWDB3ezHFwIXh2lWsl7ZbfUNKKdZTcc4 Gmh3gTb0bwMNMOtNoA0AgWrJbDKJpym8u98NBWTtmI+gqjiWXLVwLGUySqDJ70U5mKdRpVQ4 TlNQyAZh3PvM8bQNZ/tv2FZcuGmbzkbKWFtxy6xtmUuUsbYlv0rUbi24+tS2ZRlOLwHZnAEI UKphbXTHeQw1zC7VsKIRaylgbdclBYwUMFLASAEjBYwUMFLASAEjBewbVMDqH5ZwAFD7+k4Y IF1Reas4lixR3AqUqVLZCvr6ypprmEplzbV0Cew+we47U6Nu17bXC1nhOnL1y3XsjZQT15HH CHDbxtKQFW5bfmrlurZSPWkZqF0xlxbsp0xhHN3s5Tfld54/115J/2jPnyPx/SyKsjtHFbG9 nKiW3Llml19QY0bVAzEzzJW+1n3QKrCcq5SB9Jf5FRkQ2rkJomDqp5kUXrE5nKUximjGXsuF GXsa3cY9n+lDvXg8xisuIU52FN7RtKPLi5PTX72T07POFSqnB1pZWEAlrhBXnxrn0eX5Oaza V1nhT2IPajs78PhMW2nqe9Mg6Kd/ggYx3tnh+F7bLacyDqNoMPWzfK8wTPvQJ+9CPwWle7w3 GQuSjt2sSIaj7j6+bRyh1FHGORRE9CbqwHJW/DZAjRz60Q18HLJhzEf3yIfPK7v71w0D5aCz 4fZ7Xu/Ww0tW/YP7tu3Z1qtZ9DmK76JXMCSz+1c30azK5LFbR8tYe153dIMrhh8dwOdfFMK7 JukBTvS85P7eK+7EeSAtkIL7XjBhN6cEAl6CSiZ+L6gSgujWO3r37uTsENSUJEgPZOW3fjgL OMqnT0Cs8WelMm55/UW5TELCXOc7O5ZWXBTX+CuDIcpUSTW5YZykcrEKpSaVoh1NIcfReMn7 ANaP4jdcUzzPA+Tk5cjJq4weGkjKC2nlpGHlzG2uP5p6CEcEGrN1iRVBg8YRrFyphJDnlhKq ycIwS9iZHVQsz0I3CVVkmaVE1lBVx9xHrEZQUxJVXbh8QNfOg6/AKIV+Mgz60KNjdCcUJaph rYX3UD2EPSMYT9IHL/PIhZl2I8oCzyCpSeajWhajddbDjd7LN34pLdNGykeUFMBJF79654ef pHIFcJFJVpQYqSyPxSo1sBvKnp+Mve5DGsRT/G1YrSJjgGkK8674S8IAX0UPdpFYRitclmW0 zLdaSmFTXUaJAth64OMcRTJqPAmiJAk9/E9CxvkRJNgWsRMmd32ZwDS4Ce5lhGR0E/nSZyRp vxvHKlJPWjqSv2vm4C6nsNmqpEi7G+asl+1gkg5AIvR66ndVxHimaCUQ2X1TFTGB5SxQirJv UEXLvjIVGS/qK2mqSYfEO3+kfCZbKBTEMJb2ObZDXirjzvzpeQpsVMsASLmZLePEOZOdd3id 3955R6MJqCOnEbxycF95KLIx67wHA4BgtRx2JOEnhOZDAHt9QepP70/467dgmgCSqdDge+5m UxCw5HzZYEOh5Mq/9HG2wCxiw6mJbGwiTsrG8ow42fx+Hxce+EgjLwwiJSvOPOjUQejfJMuY xjicySToLWIcJN4A2xhHiOcWcd6qWOPu/yHCKH7FM44cux00suB9jSoJf0yR4QCIVQKCyptK d7LC4GYaTKAe+H+loiTwp70hIgOcY90H1qBGFEdBca28L7BGfhQnYYB1LWLD1RgHdSETLLEI mBczJcNZ2kcoouDKOjYdH+AogQqSF8PnzDBaPBgABAAEn1bGGansNJXxyAhM9uiopGTAcNn3 V4WPS3nh2/C8N7BhVJ6CZeO4H3hVsMdK2X0XsRBQXr0w26AOmLWLK/5TUu0Mt2ndVhBMQ0Gw LQWhLSmXNXKmeqzqqaqHVp55G84Xtz5AwXxdK0txPcNSpqbBtz2A5YRBZ6kVIVc0L2fpZJYu V0AzDbTQzQ4aWmMHv038ctlP3GdcqFgHjcz8U5aws6mjayB8ZIEGjzsnyHXMTGeF2aCx0zl6 e+kdHTTyny6AJcp/vmaleKJY+dw7nzqdT4xydnx4fOy9P/794vD8FGp4Ne3jZz/qIals+9np m8s3/4M/s43ipw97MSvExiiO1IF+XRcLQQ6K2NPhx9qZ50FDPPMsmfDc8aBRmmpKSnaCV6Ux w03JkB/jstrzY9ySmJ+hHTQKGbT2d9BmfX35/qDxurHDmcgPGlUTeWPn6m3n7AwKu6NoPxlm K1G2EmejDeVs7fvpXwiPYf2F5eT+L2QvaLAdT3w0RUEts2S6D2qfH+YMzHrRUC0eOUO+xDSK X3uTWSFTFMVArondwrIcQ9Pyehs7GPYyb2zRzmToT4PGTqXtFWpjhyGWBe2roJVG/hvXOlYi NI6V1dqWW4GF5uWlSB7ENdoA5hh867L+h2JGw0IFHX8HHhwN3KrFR8Mi0NhBCx9fDCWNnTjs V9vLhnXe1KIby8HGMubD4KUwrRK0uXnZ7pu8vId/GjuJYholbJqwQerLGtnDKYrwGc3qPClI 4e3ynWzBCHK7WGP+OzeKeZkwjnlpbSSFBTNfQquG/9qiypbTRYfmi47MFx6YLz5FW3I6pzib k535149GinMBGW1+WFknzb14ZET+HHOF4xjVMb7KF0R9Ti891lGeHsoPzVQnVWqnDPmhnPJc S+nQIHeLkHm3KA/h1EdwyhMzlYeK6pBUfryp8s5Z5Luw0EtE6nCx8DhZ4YuhOkRUeWhInFDk h8zKk3+Vi47Kf0jpCaRyK1rl6H+lw2rFKa/KRWXB6fiC8/Z1SBX3FLUn1sJDbbVPywKPlnVI c1eXNSilC4zcx0flkqJySFG5oyh8XlTH/KuVe6r2eKoGeaoWefImyf1SVvWKKPhWcl4UmesO mCKH0m1SZJT6aYpMgpfmSg4wKseRolxwcltSfN05f8f6+ugal/qsyRh9vnyQ1OMod1GQ+H5+ gedn1ZOWSTR3/h+hnJxqLA4CAA== --------------030309090806000407010407-- From boxbackup at fluffy.co.uk Wed Aug 9 11:08:35 2006 From: boxbackup at fluffy.co.uk (Nick Knight) Date: Wed, 9 Aug 2006 11:08:35 +0100 Subject: [Box Backup] Problem with 'get' command on large files In-Reply-To: <44D9B14E.5030105@reedtz.com> Message-ID: I had this, this is a large file issue (which is why I have put this in the testing part of the release). It took about a week to find the bug - which is below and waiting for me to put into svn: Bug 1.=20 In lib/backupclient/BackupStoreFileEncodeStream.cpp line 270: } while(rBlockSizeOut <=3D (BACKUP_FILE_MAX_BLOCK_SIZE/2) && rNumBlocksOut > BACKUP_FILE_INCREASE_BLOCK_SIZE_AFTER); //BUG - Nick Knight 24-07-2006 //Not sure whether this is the fix or the backupstorefile.cpp is the problem, they //certainly do not match... //added divide by 2. This on the client created blocks which the restore did not like the block size (this could also be fixed on the restore - but it appeared to be sensible to fix it here. Bug 2. In /lib/common/ReadGatherStream.cpp // Anything in the current block? if(mPositionInCurrentBlock < mBlocks[mCurrentBlock].mLength) { // Read! pos_type s =3D mBlocks[mCurrentBlock].mLength - mPositionInCurrentBlock; if(s > bytesToRead) s =3D bytesToRead; int r =3D mComponents[mBlocks[mCurrentBlock].mComponent]->Read(buffer, s, Timeout); The pos_type s =3D mBlocks[mCurrentBlock].mLength - mPositionInCurrentBlock; var s was an int, when the server upt a single large file together, it places the whole file (data) as a single block into the object, which means any read should be the same addressable space. -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Per Thomsen Sent: 09 August 2006 10:57 To: boxbackup at fluffy.co.uk Subject: [Box Backup] Problem with 'get' command on large files Hi, I have been awfully busy, and have only now started migrating my old=20 accounts to my new server (Linux X86_64, FC5, 0.10), and I'm running=20 into a problem when doing some manual testing. To wit: My client machine is a Mac OSX machine (10.4.7) with the 0.10=20 release builds of bbackupd, bbackupquery, etc. It appears that the=20 backups work fine. I am able to (AFAICT) back up a 3.2GB file to the=20 store. But when I try to restore it (for testing), the following happens in bbackupquery: ------------------------------- curie:/Users/pthomsen root# bbackupquery Box Backup Query Tool v0.10, (c) Ben Summers and contributors 2003-2006 Using configuration file /etc/box/bbackupd.conf Connecting to store... Handshake with store... Login to store... Login complete. Type "help" for a list of commands. query > cd users/pthomsen/Desktop/bordeaux-DVD-i386 query > ls -st 00032547 f----- 2006-04-01T00:35:58 3079421 FC-5-i386-DVD.iso 00033403 f----- 2006-06-06T00:29:09 00001 SHA1SUM 000375c3 f----- 2006-08-08T03:39:53 00001 .DS_Store 00037666 f----- 2006-08-08T07:26:15 3079421 p.iso query > get FC-5-i386-DVD.iso foo.iso =20 Error occured fetching file. query > ls Exception: Connection TLSReadFailed (Probably a network issue between=20 client and server.) (7/34) ------------------------------- Even with a debug build there is nothing in system.log on the client=20 machine. On the server, I get the following in the (extended logging;=20 release-build) logs: ------------------------------- Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size 256 Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile(0x31e85,0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile(0x31e85,0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size -1141640418 Aug 9 01:47:01 backup01 bbstored[19717]: Connection statistics for=20 BACKUP-0005: IN=3D210 OUT=3D75545 TOTAL=3D75755 Aug 9 01:47:01 backup01 bbstored[19717]: in server child, exception=20 RaidFile OSError (Error when accessing an underlying file. Check file=20 permissions allow files to be read and written in the configured raid=20 directories.) (2/8) -- terminating child=20 ------------------------------- I noticed the negative number for stream size, and worry that it is=20 there because something in my builds is not using 64-bit numbers for=20 file size. The file I'm trying to restore (id 00032547) is 3,153,326,894 bytes in the store, which (when 16 is subtracted from it) is=20 -1,141,640,418 as a signed 32-bit number. I am suspicious that I have not built the large-file support correctly.=20 I vaguely remember that there was something special needed to get the=20 large file support to build on Linux, but I thought it was taken care of with autoconf. Or this could be a bug in the GetFile command. In lib/server/Protocol.cpp:738: IOStream::pos_type is used. I can't find the definition of IOStream::pos_type, and I'm not sure if that's really=20 the right place to be looking for this. I think I built the server with 64-bit support, and I'm attaching a=20 gzipped config.log, so nothing (hopefully is missing)... Thanks for any help I can get, Per --=20 Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Wed Aug 9 11:13:59 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Wed, 09 Aug 2006 11:13:59 +0100 Subject: [Box Backup] Problem with 'get' command on large files In-Reply-To: <44D9B14E.5030105@reedtz.com> References: <44D9B14E.5030105@reedtz.com> Message-ID: <20060809111359.nj5ckd4tw8kokswg@ebourne.me.uk> Per Thomsen wrote: > I noticed the negative number for stream size, and worry that it is > there because something in my builds is not using 64-bit numbers for > file size. The file I'm trying to restore (id 00032547) is > 3,153,326,894 bytes in the store, which (when 16 is subtracted from it) > is -1,141,640,418 as a signed 32-bit number. > > I am suspicious that I have not built the large-file support correctly. > I vaguely remember that there was something special needed to get the > large file support to build on Linux, but I thought it was taken care > of with autoconf. There should be nothing special to configure large files. autoconf as =20 you say takes care of it. You're compiling on 64bit linux, I don't think it's possible to not =20 have large file support. Your config.log says it is enabled. > Or this could be a bug in the GetFile command. > > In lib/server/Protocol.cpp:738: IOStream::pos_type is used. I can't > find the definition of IOStream::pos_type, and I'm not sure if that's > really the right place to be looking for this. Sounds suspiciously like a bug Nick had found in the windows version. =20 He did say he thought large file support didn't work on any platform - =20 oops! I have no experience of it myself, unfortunately I can't afford to =20 back up my large files, too many small files that are more important. :) Still, I also use 64bit linux so I'll give it a go when I get chance. Cheers, Martin. From boxbackup at fluffy.co.uk Wed Aug 9 11:46:36 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Wed, 9 Aug 2006 11:46:36 +0100 Subject: [Box Backup] Problem with 'get' command on large files In-Reply-To: <44D9B14E.5030105@reedtz.com> References: <44D9B14E.5030105@reedtz.com> Message-ID: On 9 Aug 2006, at 10:56, Per Thomsen wrote: > > On the server, I get the following in the (extended logging; > release-build) logs: > ------------------------------- > Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size 256 > Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile > (0x31e85,0x37666) > Aug 9 01:47:01 backup01 bbstored[19717]: Receive GetFile > (0x31e85,0x37666) > Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) > Aug 9 01:47:01 backup01 bbstored[19717]: Send Success(0x37666) > Aug 9 01:47:01 backup01 bbstored[19717]: Sending stream, size > -1141640418 > Aug 9 01:47:01 backup01 bbstored[19717]: Connection statistics for > BACKUP-0005: IN=210 OUT=75545 TOTAL=75755 > Aug 9 01:47:01 backup01 bbstored[19717]: in server child, > exception RaidFile OSError (Error when accessing an underlying > file. Check file permissions allow files to be read and written in > the configured raid directories.) (2/8) -- terminating child > ------------------------------- > > I noticed the negative number for stream size, and worry that it is > there because something in my builds is not using 64-bit numbers > for file size. The file I'm trying to restore (id 00032547) is > 3,153,326,894 bytes in the store, which (when 16 is subtracted from > it) is -1,141,640,418 as a signed 32-bit number. Oooops, this is a very silly bug. To write a test to catch the bug... test/common/testcommon.cpp ... write stream class which gives > 0x7fffffff bytes of zeros. Then create a PartialReadStream from it, asking for > 0x7fffffff, and check to see if the results are as expected. With the current code, this should fail. So on to the fix: lib/common/PartialReadStream.* Change int mBytesLeft; to pos_type mBytesLeft; then all vars which are related (eg BytesToRead in constructor) to pos_type too. (Don't change the args to Read otherwise it won't implement the IOStream interface.) What a stupid mistake to make. Who wrote this code? :-( Ben PS: Sorry. From boxbackup at fluffy.co.uk Wed Aug 9 12:47:10 2006 From: boxbackup at fluffy.co.uk (Nick Knight) Date: Wed, 9 Aug 2006 12:47:10 +0100 Subject: [Box Backup] Problem with 'get' command on large files In-Reply-To: <20060809111359.nj5ckd4tw8kokswg@ebourne.me.uk> Message-ID: Yes I forgot to mention the bug I found was on the server - so in this instance generic to box not just to windows. -----Original Message----- From: boxbackup-admin at fluffy.co.uk [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Martin Ebourne Sent: 09 August 2006 11:14 To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] Problem with 'get' command on large files Per Thomsen wrote: > I noticed the negative number for stream size, and worry that it is > there because something in my builds is not using 64-bit numbers for > file size. The file I'm trying to restore (id 00032547) is > 3,153,326,894 bytes in the store, which (when 16 is subtracted from it) > is -1,141,640,418 as a signed 32-bit number. > > I am suspicious that I have not built the large-file support correctly. > I vaguely remember that there was something special needed to get the > large file support to build on Linux, but I thought it was taken care > of with autoconf. There should be nothing special to configure large files. autoconf as =20 you say takes care of it. You're compiling on 64bit linux, I don't think it's possible to not =20 have large file support. Your config.log says it is enabled. > Or this could be a bug in the GetFile command. > > In lib/server/Protocol.cpp:738: IOStream::pos_type is used. I can't > find the definition of IOStream::pos_type, and I'm not sure if that's > really the right place to be looking for this. Sounds suspiciously like a bug Nick had found in the windows version. =20 He did say he thought large file support didn't work on any platform - =20 oops! I have no experience of it myself, unfortunately I can't afford to =20 back up my large files, too many small files that are more important. :) Still, I also use 64bit linux so I'll give it a go when I get chance. Cheers, Martin. _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Wed Aug 9 13:17:58 2006 From: boxbackup at fluffy.co.uk (Felix E. Klee) Date: Wed, 09 Aug 2006 14:17:58 +0200 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec Message-ID: <87bqqunlvt.wl%felix.klee@inka.de> Some time ago, Chris Wilson recommended using BoxBackup as a fast alternative to rdiff-backup when backing up to a slow server, in this case a 400MHz Mipsel powered Linkstation. Well, this morning I got around to testing it, and I found that it is not much faster than rdiff-backup, if at all. A little benchmark: $ ssh root at linkstation # cd /mnt/hda/share/boxbackup/backup/00000001/ # date; du -sh . Wed Aug 9 09:17:11 CEST 2006 97M . # date; du -sh . Wed Aug 9 09:49:00 CEST 2006 313M . =3D> Transmission speed in that interval:=20 (313 MiB - 97 MiB) / (2940 s - 1031 s) =3D 216 MiB / 1909 s =3D 0.113 MiB/s Over a 1MiBit/s DSL line this speed would be acceptable, but not over a 100Mibit/s LAN: I plan to back up ca. 40GiB of data, and the initial backup would then - according to the above benchmark - take more than four days. The problem seems to be the CPU of the Linkstation, which - according to top - is permanently utilized more than 90% by BoxBackup. On the client machine, a 1.6GHz Pentium M powered ThinkPad T41, the CPU utilization by BoxBackup is low. Now, some questions:=20 * Is the transmission speed I measured the speed which one would expect given the hardware of the Linkstation (see below for details)? Perhaps my benchmark is flawed considerably. * Is there any way to increase the transmission speed, other than replacing the Linkstation with something having a more powerful CPU? For example, Chris Wilson told me some time ago that the communication channel is encrypted, and turning it off would - I assume - increase performance considerably. * Also, why is the CPU utilized that much? Is the reason only decryption of data sent through the secure channel? If BoxBackup fails for me, then I guess I'll just use J=F6rg Schilling's star which is incredibly fast and which I've extensively tested in the past (I even wrote a little test suite for my purpose): I may just encrypt the Tar archives this tool generates, and transfer them to the Linkstation, e.g. via Samba. The disadvantage of the tool is that restoration of individual files is cumbersome: One always has to replay the entire backup. That's why I wanted to supplement the star backups of my important data with easily browseable backups of the entire system, created by BoxBackup, rdiff-backup, or whatever. =20 Some details: * Version of BoxBackup being used: BoxBackup 0.10 * Hardware of the Linkstation: Mipsel CPU at 400MHz, ca. 64MiB RAM, 160GB HD at 7200RPM, 100MBit/s LAN. * Hardware of the client: Thinkpad T41 with 1.6GHz Pentium-M, 1GiB RAM, 100GB HD at 5400RPM, 10/100/1000MBit/s LAN. --=20 Felix E. Klee From boxbackup at fluffy.co.uk Wed Aug 9 16:23:33 2006 From: boxbackup at fluffy.co.uk (Baltasar Cevc) Date: Wed, 9 Aug 2006 17:23:33 +0200 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec In-Reply-To: <87bqqunlvt.wl%felix.klee@inka.de> References: <87bqqunlvt.wl%felix.klee@inka.de> Message-ID: <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> Try to check whether the IO on the machine is the problem. My old backup server (which is a machine with about 2 GHz) had serious trouble with the whole bunch of tiny files bbstored writes. I had loads of > 8 (in contrast to an average of 0.10 without bbstored or any other heavy IO app) and usually over 95% CPU time in the waiting for IO state. Now I moved everything to a dedicated machine, which is some years olther and has less RAM, CPU and older drives, however it's much faster and the load hasn't been over 1 till now (although the backed up data doubled). I'm not sure what the reason for that trouble was (HD, HDC, kernel), but maybe you've got the same problem. Just a hint: comparing the data takes quite some time, thus the first backup should give a higher troughput than later ones. At least that's what I've experienced... Hope you will be able to solve your problem. Baltasar ((( Baltasar Cevc ) World wide web: * http://www.openairkino.net/ (a project for the local youth; German only) * http://technik.juz-kirchheim.de/ (programming and admin projects) * http://baltasar.cevc-topp.de/ (private homepage) ) Phone: +49 176 232 20 822 ) From boxbackup at fluffy.co.uk Wed Aug 9 18:13:41 2006 From: boxbackup at fluffy.co.uk (Felix E. Klee) Date: Wed, 09 Aug 2006 19:13:41 +0200 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec In-Reply-To: <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> References: <87bqqunlvt.wl%felix.klee@inka.de> <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> Message-ID: <87ac6domre.wl%felix.klee@inka.de> At Wed, 9 Aug 2006 17:23:33 +0200, Baltasar Cevc wrote: > Try to check whether the IO on the machine is the problem. My old > backup server (which is a machine with about 2 GHz) had serious > trouble with the whole bunch of tiny files bbstored writes. Thanks for the hint. I may indeed try that out. However, first I'd like to know whether it's possible to disable encryption of the transmission channel and, if so, how. Also, I'd like to know why the transmission channel is encrypted: After all, the backups themselves are encrypted. So, additional encryption seems to be superfluous, something for the paranoid. > Just a hint: comparing the data takes quite some time, thus the first > backup should give a higher troughput than later ones. At least that's > what I've experienced... This comparison thingy is probably one of the reasons why many modern backup tools (rdiff-backup, etc.) are so extremely slow. Star, for example just records the time stamp associated with the last backup. So, when doing an incremental dump, it simply checks which files have been modified since the date in the time stamp and backs those up. It also doesn't compute deltas of files and it has the classical system of multiple dump levels, so a set of incremental backups is larger than it would be with the new fancy tools. However, the extreme speed make up for all those little disadvantages. Just to give you an example: If not many files have changed, an incremental dump of a file system with 7GB of files may take just about a minute. I don't expect backups to be that fast with BoxBackup. I'd very well be happy to wait a bit longer, in exchange for all those nice advantages offered by BoxBackup, but there are limits. Going back to the example I just mentioned: BoxBackup should not take much longer than 10 minutes to do an incremental dump of a file system with 7GB of files, if not many have changed. -- Felix E. Klee From boxbackup at fluffy.co.uk Thu Aug 10 09:41:27 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 10 Aug 2006 09:41:27 +0100 (BST) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <7.0.1.0.2.20060808095417.047cc298@elehost.com> References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> <7.0.1.0.2.20060808095417.047cc298@elehost.com> Message-ID: Hi Paul, > Thanks so much for looking into this. I really appreciate it. I have > tried the new client and can report I am still having issues. Right now > I am only referencing the errors in the event viewer. > > I am now having problems with both the file and directory excludes: > > ExcludeFile = C:\pagefile.sys Please could you try this new build: [http://bbdev.fluffy.co.uk/svn/box/chris/win32/releases/boxbackup-chris_general_767M-backup-client-mingw32.zip] I've tested directory excludes and they do now work, at least for me. I think that file excludes should work as well. > Here is the file error in the event viewer: > > Event Type: Warning > Event Source: Box Backup > Event Category: None > Event ID: 1 > Date: 8/8/2006 > Time: 9:54:37 AM > User: N/A > Computer: MYSERVER > Description: > Failed to open 'C:\\pagefile.sys': error 32 The warning will not be stopped by this build. Windows does not allow us to determine (as far as I can tell) whether pagefile.sys is a file or a directory, and therefore we can't decide which exclude list to use to exclude it. I'm still working on fixing this. In any case, it won't be backed up :-) This will happen with any file that is open exclusively, unless you exclude one of its parent directories (not the file itself, for the same reason as above). > Here is what I have tried to see if it makes a difference ( i tried these > separately and each time I stopped the service and restarted it). None of the > 1-4 examples made a difference: > > 1) ExcludeDir = C:\\Documents/ and/ Settings\Administrator.MYSERVER\Cookies\ > 2) ExcludeDir = C:\\Documents and Settings\Administrator.MYSERVER\Cookies\ > 3) ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies\ > 4) ExcludeDir = "C:\Documents and Settings\Administrator.MYSERVER\Cookies\" > > Is there a problem with the syntax above for the one that should work? The third one should work, without the backslash at the end of the directory name. Quotes are not necessary, and backslashes do not need to be doubled. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Thu Aug 10 13:25:26 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 10 Aug 2006 13:25:26 +0100 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec In-Reply-To: <87ac6domre.wl%felix.klee@inka.de> References: <87bqqunlvt.wl%felix.klee@inka.de> <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> <87ac6domre.wl%felix.klee@inka.de> Message-ID: On 9 Aug 2006, at 18:13, Felix E. Klee wrote: > At Wed, 9 Aug 2006 17:23:33 +0200, > Baltasar Cevc wrote: >> Try to check whether the IO on the machine is the problem. My old >> backup server (which is a machine with about 2 GHz) had serious >> trouble with the whole bunch of tiny files bbstored writes. > > Thanks for the hint. I may indeed try that out. However, first I'd > like to know whether it's possible to disable encryption of the > transmission channel and, if so, how. It's not possible. > Also, I'd like to know why the > transmission channel is encrypted: After all, the backups > themselves are > encrypted. So, additional encryption seems to be superfluous, > something > for the paranoid. The protocol around the backups isn't encrypted. Using SSL gives you * Strong authentication * Protection from man-in-the-middle attacks * And obscures the stuff being transmitted, reducing the information available to an eavesdropper to just quantity and timing. The cost is a bit of public key crypto at the beginning of each session, which would need to be done anyway for authentication, and symmetric crypto for all data during the session. The latter is not very processor intensive, and certainly shouldn't take up 95% of CPU time. When doing a new backup, bbstored is mostly doing symmetric decryption and writing stuff to disc, and bbackupd is reading stuff from disc, encrypting it, then encrypting it again for transmission. Both should be limited by I/O not CPU. When diffs are transmitted later, bbackupd will do the heavy lifting on the CPU, and bbstored will be doing a load of I/O to reassemble the file. When doing lots of small files, the protocol is a bit inefficient as it has to wait for a round-trip after each file is sent, but I can't see this resulting in such a low transfer rate. Ben From boxbackup at fluffy.co.uk Thu Aug 10 14:31:25 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Thu, 10 Aug 2006 06:31:25 -0700 (PDT) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: Message-ID: <20060810133125.21089.qmail@web60624.mail.yahoo.com> I don't know if my BackupLocations section below helps, or hurts, or irrelevant, as it's been months since I've tested it, but here is how my template bbackupd.conf file uses regex on Windows clients. The ntuser.dat and pagefile.sys sections in my second ExcludeFilesRegex are inspired by recent personal experience and this thread, but are completely untested as of yet. I hope to install Chris' new client (THANKS, Chris! Amazing work!) soon; I'll report back what I find. Directory backslashes in regex (and maybe many other characters, maybe including ":", do need to be escaped with a "\". Good luck, Pete BackupLocations { DocsSettings { Path = C:\Documents and Settings ExcludeFilesRegex = .+\.([aA][vV][iI]|[bB][mM][pP]|[iI][sS][oO]|[mM][pP][eE]?[3gG]|[tT][iI][fF]*|[tT][mM ][pP]|[bB][aAcC][kK]|[dD][bB][kK]|[bB][kK][~!1-9]|[mMtT][bB][kK]|[oO][lL][dD]|[sS][aA][vV]|[sS][wW][pP]|[wW][mM][aA]|[xX ][lL][kK]|[cC][sS][mM]|[dD][sS][kK]|[oO][bB][jJ]|[pP][aA][rR]|[dD][bB][xX]|[dD][lL][lL])$ ExcludeFilesRegex = .*\\thumbs\.db$|.*\\history\.dat$|.*\\cookies\.txt$|.*\\~.*|.*\\ntuser\.dat$|.*\\pag efile\.sys$ } } --- Chris Wilson wrote: > > I am now having problems with both the file and directory excludes: > > > > ExcludeFile = C:\pagefile.sys > > Please could you try this new build: [http://bbdev.fluffy.co.uk/svn/box/chris/win32/releases/boxbackup-chris_general_767M-backup-client-mingw32.zip] > > I've tested directory excludes and they do now work, at least for me. > I think that file excludes should work as well. > > > Failed to open 'C:\\pagefile.sys': error 32 > > > 4) ExcludeDir = "C:\Documents and > Settings\Administrator.MYSERVER\Cookies\" > > > The third one should work, without the backslash at the end of the > directory name. Quotes are not necessary, and backslashes do not need > to > be doubled. > From boxbackup at fluffy.co.uk Thu Aug 10 20:45:59 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 10 Aug 2006 20:45:59 +0100 (BST) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <20060810133125.21089.qmail@web60624.mail.yahoo.com> References: <20060810133125.21089.qmail@web60624.mail.yahoo.com> Message-ID: Hi Pete, > I hope to install Chris' new client soon; I'll report back what I find. The newest versions of the client are case insensitive, so you can simplify your regex a bit: > Directory backslashes in regex (and maybe many other characters, maybe > including ":", do need to be escaped with a "\". ':' does not need to be escaped. > ExcludeFilesRegex = > .+\.([aA][vV][iI]|[bB][mM][pP]|[iI][sS][oO]|[mM][pP][eE]?[3gG]|[tT][iI][fF]*|[tT][mM > ][pP]|[bB][aAcC][kK]|[dD][bB][kK]|[bB][kK][~!1-9]|[mMtT][bB][kK]|[oO][lL][dD]|[sS][aA][vV]|[sS][wW][pP]|[wW][mM][aA]|[xX > ][lL][kK]|[cC][sS][mM]|[dD][sS][kK]|[oO][bB][jJ]|[pP][aA][rR]|[dD][bB][xX]|[dD][lL][lL])$ This could now be written as: ExcludeFilesRegex = .+\.avi ExcludeFilesRegex = .+\.bmp ExcludeFilesRegex = .+\.iso ExcludeFilesRegex = .+\.mpe?[3g] ExcludeFilesRegex = .+\.tif ExcludeFilesRegex = .+\.tmp ExcludeFilesRegex = .+\.bak ExcludeFilesRegex = .+\.bck ExcludeFilesRegex = .+\.dbk ExcludeFilesRegex = .+\.bk[~!1-9] ExcludeFilesRegex = .+\.mbk ExcludeFilesRegex = .+\.tbk ExcludeFilesRegex = .+\.old [...] which is easier to read, although somewhat longer and a bit less efficient :-) Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Thu Aug 10 21:04:53 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Thu, 10 Aug 2006 13:04:53 -0700 (PDT) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: Message-ID: <20060810200453.29699.qmail@web60617.mail.yahoo.com> Great, Chris, thanks. Shall I start a wiki page documenting bbackupd.conf, with a section for Windows clients (with annotations re which version), and a subsection for BackupLocations? Pete From boxbackup at fluffy.co.uk Thu Aug 10 21:20:40 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 10 Aug 2006 21:20:40 +0100 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <20060810200453.29699.qmail@web60617.mail.yahoo.com> References: <20060810200453.29699.qmail@web60617.mail.yahoo.com> Message-ID: <1155241240.31087.22.camel@avenin.ebourne.me.uk> On Thu, 2006-08-10 at 13:04 -0700, E.W. Peter Jalajas wrote: > Great, Chris, thanks. > > Shall I start a wiki page documenting bbackupd.conf, with a section for > Windows clients (with annotations re which version), and a subsection > for BackupLocations? Join in the Box documentation project! Currently it's just Per Thomsen, but he's done a fine job and would be glad of help, I'm sure. Per described on the list (maybe the -dev list) how to go about using his doc stuff and you can send patches so you don't need commit access. Cheers, Martin. From boxbackup at fluffy.co.uk Thu Aug 10 21:57:20 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Thu, 10 Aug 2006 13:57:20 -0700 (PDT) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <1155241240.31087.22.camel@avenin.ebourne.me.uk> Message-ID: <20060810205720.13822.qmail@web60612.mail.yahoo.com> Yes, Per has done wonderful work! A few months ago though, I tried, I swear, but I was too lazy and not smart enough to install and learn the couple of different development and xml related tools needed to contribute (I think I recall that I had package dependency conflicts), so I just stuck with the wiki. Per, could you please point me to the instructions on how to get started (again) and I'll give a second try? What dev (svn?) and xml tools to use, how to checkout/checkin the pages, coding and character set goals/standards, etc. Thanks, Pete --- Martin Ebourne wrote: > On Thu, 2006-08-10 at 13:04 -0700, E.W. Peter Jalajas wrote: > > Great, Chris, thanks. > > > > Shall I start a wiki page documenting bbackupd.conf, with a section > for > > Windows clients (with annotations re which version), and a > subsection > > for BackupLocations? > > Join in the Box documentation project! > > Currently it's just Per Thomsen, but he's done a fine job and would > be > glad of help, I'm sure. Per described on the list (maybe the -dev > list) > how to go about using his doc stuff and you can send patches so you > don't need commit access. > > Cheers, > > Martin. > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Fri Aug 11 01:20:28 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Thu, 10 Aug 2006 17:20:28 -0700 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <20060810205720.13822.qmail@web60612.mail.yahoo.com> References: <20060810205720.13822.qmail@web60612.mail.yahoo.com> Message-ID: <44DBCD4C.5060805@reedtz.com> On 8/10/06 1:57 PM, E.W. Peter Jalajas wrote: > Yes, Per has done wonderful work! A few months ago though, I tried, I > swear, but I was too lazy and not smart enough to install and learn the > couple of different development and xml related tools needed to > contribute (I think I recall that I had package dependency conflicts), > so I just stuck with the wiki. > > Per, could you please point me to the instructions on how to get > started (again) and I'll give a second try? What dev (svn?) and xml > tools to use, how to checkout/checkin the pages, coding and character > set goals/standards, etc. > The instructions are on the Wiki: http://boxbackup.hostworks.ca/index.php/DocProject Briefly: Documents are created in DocBook, using XMLMinds free (beer) version of XXE, and checked into SVN. A baseline of docs (mostly gathered from the Wiki) have been created, but some of the books could do with some TLC. To make the documents from the DocBook sources, xsltproc is needed. Currently, there are no plans to translate the docs to other languages, but if anyone is interested in doing that, I would be happy to help with the infrastructure for that. If you have questions about any of this, please feel free to contact me. Thanks, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Fri Aug 11 09:46:52 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Fri, 11 Aug 2006 09:46:52 +0100 Subject: [Box Backup] Documentation writing tools (was: ExcludeFile command being ignored with Win32 client.) In-Reply-To: <44DBCD4C.5060805@reedtz.com> References: <20060810205720.13822.qmail@web60612.mail.yahoo.com> <44DBCD4C.5060805@reedtz.com> Message-ID: <34C0E9D8-8DB4-402C-A70F-44FFDACBD50E@fluffy.co.uk> On 11 Aug 2006, at 01:20, Per Thomsen wrote: > On 8/10/06 1:57 PM, E.W. Peter Jalajas wrote: >> Yes, Per has done wonderful work! A few months ago though, I >> tried, I >> swear, but I was too lazy and not smart enough to install and >> learn the >> couple of different development and xml related tools needed to >> contribute (I think I recall that I had package dependency >> conflicts), >> so I just stuck with the wiki. >> Per, could you please point me to the instructions on how to get >> started (again) and I'll give a second try? What dev (svn?) and xml >> tools to use, how to checkout/checkin the pages, coding and character >> set goals/standards, etc. >> > The instructions are on the Wiki: http://boxbackup.hostworks.ca/ > index.php/DocProject > > Briefly: Documents are created in DocBook, using XMLMinds free > (beer) version of XXE, and checked into SVN. A baseline of docs > (mostly gathered from the Wiki) have been created, but some of the > books could do with some TLC. > > To make the documents from the DocBook sources, xsltproc is needed. XML isn't too difficult to write by hand. Is it sensible to try editing them by hand and getting someone else to check they validate properly? I'm just wondering how the barrier to participation can be reduced. Ben From boxbackup at fluffy.co.uk Sun Aug 13 17:58:44 2006 From: boxbackup at fluffy.co.uk (Magnus Homann) Date: Sun, 13 Aug 2006 18:58:44 +0200 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec In-Reply-To: References: <87bqqunlvt.wl%felix.klee@inka.de> <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> <87ac6domre.wl%felix.klee@inka.de> Message-ID: <44DF5A44.3010108@homann.se> Ben Summers wrote: > > On 9 Aug 2006, at 18:13, Felix E. Klee wrote: > >> At Wed, 9 Aug 2006 17:23:33 +0200, >> Baltasar Cevc wrote: >>> Try to check whether the IO on the machine is the problem. My old >>> backup server (which is a machine with about 2 GHz) had serious >>> trouble with the whole bunch of tiny files bbstored writes. >> >> Thanks for the hint. I may indeed try that out. However, first I'd >> like to know whether it's possible to disable encryption of the >> transmission channel and, if so, how. > > It's not possible. > >> Also, I'd like to know why the >> transmission channel is encrypted: After all, the backups themselves are >> encrypted. So, additional encryption seems to be superfluous, something >> for the paranoid. > > The protocol around the backups isn't encrypted. Using SSL gives you > > * Strong authentication > > * Protection from man-in-the-middle attacks > > * And obscures the stuff being transmitted, reducing the information > available to an eavesdropper to just quantity and timing. > > The cost is a bit of public key crypto at the beginning of each session, > which would need to be done anyway for authentication, and symmetric > crypto for all data during the session. The latter is not very processor > intensive, and certainly shouldn't take up 95% of CPU time. How about optionally being able to turn SSL off, and let the user have the possibility to use SSH tunneling instead? That is often more available at the remote end (at least for me :-). Now I do the backup to a local disk, and then do a rsync over ssh to the far end. Probably more I/O efficient, but NOT disk efficient! :-) I looked at the code, but didn't see an obvious way to modify it. Magnus From boxbackup at fluffy.co.uk Mon Aug 14 04:38:09 2006 From: boxbackup at fluffy.co.uk (John MacKenzie) Date: Sun, 13 Aug 2006 23:38:09 -0400 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> <7.0.1.0.2.20060808095417.047cc298@elehost.com> Message-ID: <7.0.1.0.2.20060813233245.04557b88@elehost.com> Hi Chris, I tried the latest version and all seems great for the windows version with regards to the exclude directives. Thanks for your help and responsiveness! I did notice that for the ExcludeDir the following did not seem to work: ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies\ But it did work when I removed the trailing slash: ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies So it all looks good to me as I have adjusted my config files. A big thanks for clearing up the pagefile.sys issue. Have you or anyone else done any testing on restoring a Windows box from scratch via Box Backup? (sorry if this has already be addressed) John From boxbackup at fluffy.co.uk Mon Aug 14 09:41:37 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 14 Aug 2006 09:41:37 +0100 (BST) Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: <7.0.1.0.2.20060813233245.04557b88@elehost.com> References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> <7.0.1.0.2.20060808095417.047cc298@elehost.com> <7.0.1.0.2.20060813233245.04557b88@elehost.com> Message-ID: Hi John, > I tried the latest version and all seems great for the windows version with > regards to the exclude directives. Thanks for your help and responsiveness! No problem, thanks for testing it. > I did notice that for the ExcludeDir the following did not seem to work: > > ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies\ > > But it did work when I removed the trailing slash: > > ExcludeDir = C:\Documents and Settings\Administrator.MYSERVER\Cookies I thought I mentioned that in my email, sorry if I omitted it. Perhaps I should add a warning in the code as well. > Have you or anyone else done any testing on restoring a Windows box from > scratch via Box Backup? (sorry if this has already be addressed) It's currently impossible, since Windows locks several critical files like the SAM, and we have no way to back them up. There is some discussion of adding support for Volume Shadow Services to Box, which should fix this, and then it might be possible. Also, we don't currently have support for backing up or restoring NTFS permissions, so an NTFS volume would be hopelessly insecure after it was restored. Ben has always said that it makes more sense to reinstall the OS and restore the data than to back up the whole OS, but I'm not sure whether I agree - the fastest recovery from a disaster would be a total restore, as far as I can tell. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Mon Aug 14 09:48:22 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 14 Aug 2006 09:48:22 +0100 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> <7.0.1.0.2.20060808095417.047cc298@elehost.com> <7.0.1.0.2.20060813233245.04557b88@elehost.com> Message-ID: On 14 Aug 2006, at 09:41, Chris Wilson wrote: > > Ben has always said that it makes more sense to reinstall the OS > and restore the data than to back up the whole OS, but I'm not sure > whether I agree - the fastest recovery from a disaster would be a > total restore, as far as I can tell. On Windows, use something like Ghost to backup the basic OS install, and use Box Backup for the data. This way of working might be more applicable to people supporting lots of desktops, though. Ben From boxbackup at fluffy.co.uk Mon Aug 14 10:00:23 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 14 Aug 2006 10:00:23 +0100 Subject: [Box Backup] Box-Backup slow: 0.1 MiB/sec In-Reply-To: <44DF5A44.3010108@homann.se> References: <87bqqunlvt.wl%felix.klee@inka.de> <84deb816a2bd58d7f72a3201087458a4@cevc-topp.de> <87ac6domre.wl%felix.klee@inka.de> <44DF5A44.3010108@homann.se> Message-ID: <02462999-7DA8-4B3C-BA8F-BD3E87EA9377@fluffy.co.uk> On 13 Aug 2006, at 17:58, Magnus Homann wrote: > Ben Summers wrote: >> On 9 Aug 2006, at 18:13, Felix E. Klee wrote: >>> At Wed, 9 Aug 2006 17:23:33 +0200, >>> Baltasar Cevc wrote: >>>> Try to check whether the IO on the machine is the problem. My old >>>> backup server (which is a machine with about 2 GHz) had serious >>>> trouble with the whole bunch of tiny files bbstored writes. >>> >>> Thanks for the hint. I may indeed try that out. However, first I'd >>> like to know whether it's possible to disable encryption of the >>> transmission channel and, if so, how. >> It's not possible. >>> Also, I'd like to know why the >>> transmission channel is encrypted: After all, the backups >>> themselves are >>> encrypted. So, additional encryption seems to be superfluous, >>> something >>> for the paranoid. >> The protocol around the backups isn't encrypted. Using SSL gives you >> * Strong authentication >> * Protection from man-in-the-middle attacks >> * And obscures the stuff being transmitted, reducing the >> information available to an eavesdropper to just quantity and timing. >> The cost is a bit of public key crypto at the beginning of each >> session, which would need to be done anyway for authentication, >> and symmetric crypto for all data during the session. The latter >> is not very processor intensive, and certainly shouldn't take up >> 95% of CPU time. > > How about optionally being able to turn SSL off, and let the user > have the possibility to use SSH tunneling instead? The reason I used SSL was to avoid the necessity for everyone to have a UNIX account at the remote end. This makes handling backups for many users much more manageable. > That is often more available at the remote end (at least for > me :-). Now I do the backup to a local disk, and then do a rsync > over ssh to the far end. Probably more I/O efficient, but NOT disk > efficient! :-) > > I looked at the code, but didn't see an obvious way to modify it. Write an ssh tunneling IOStream derived class -- see lib/common/ IOStream.h and the documentation in the notes directory. bin/bbackupd/BackupClientContext.cpp, BackupClientContext::GetConnection(). Modify to check the daemon configuration (via the mrDaemon member variable), and if ssh is required create one of your new classes instead of the SSL socket. No other modifications are necessary for the client. The server is slightly more complex. I suggest getting the daemon to listen on a local UNIX socket (with appropriate permissions) and a helper exe which simply redirects stdin/stdout to this socket. In bin/ bbstored/BackupStoreDaemon.cpp check the configuration again, if using the ssh option, get the UID of the connecting process, choose the account based on that UID (account number == UID?), and just use a normal non-SSL socket. The templating of the class is a problem, you may need to have some sort of compile time option to choose which option. Or move everything to a lib/ directory, and have BackupStoreDaemon be templated itself, and have two exes, bbstored and bbstored-ssh to select which option you want. Not too much work, I suppose. :-) Ben From boxbackup at fluffy.co.uk Mon Aug 14 10:02:21 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Mon, 14 Aug 2006 02:02:21 -0700 Subject: [Box Backup] ExcludeFile command being ignored with Win32 client. In-Reply-To: References: <20060719110001.8135.56527.Mailman@love.warhead.org.uk> <7.0.1.0.2.20060719095550.04bf4178@elehost.com> <7.0.1.0.2.20060808095417.047cc298@elehost.com> <7.0.1.0.2.20060813233245.04557b88@elehost.com> Message-ID: <44E03C1D.5080209@reedtz.com> On 8/14/06 1:41 AM, Chris Wilson wrote: > Ben has always said that it makes more sense to reinstall the OS and > restore the data than to back up the whole OS, but I'm not sure > whether I agree - the fastest recovery from a disaster would be a > total restore, as far as I can tell. Not to rehash old discussions, but the problem with trying to restore full systems, is that in order to restore a complete system, you need to have a system from which to restore; a chicken-and-egg thing; you can't restore a system with Box, unless you have Box installed... There would be a lot of work involved in getting Box to work like that. It's not what it's designed for. If you want to restore a system, you should have two things: 1. A way to restore the system (OS, etc.). There are many packages out there for this (ghosting for Win, Kick-start for Linux, and many others I'm sure). They do a great job restoring the OS to a given state. 2. A way to restore the data on the system. This is where Box shines. It keeps data up-to-date, and makes it easy to restore. Philosophically, the Unix adage of 'do one thing and do it well' works well for me. It's hard to make Box a strong multi-platform system-restore product, while also keeping the data backup features working well. My $0.02, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Tue Aug 15 12:56:02 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 15 Aug 2006 13:56:02 +0200 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] Message-ID: <44E1B652.3010704@kontrapunkt.com> Hello..... My boxbackup 0.10 client never seems to retry after an error har occured as seen below. Any ideas? Tobias Aug 15 00:24:38 yoiko bbackupd[27200]: TRACE: Initiated timer for file diff control\n Aug 15 00:24:38 yoiko bbackupd[27200]: TRACE: Diff: 8192 new bytes found, 245 old blocks used\n Aug 15 00:24:38 yoiko bbackupd[27200]: TRACE: Suspended timer for file diff control\n Aug 15 00:24:38 yoiko bbackupd[27200]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 15 00:24:38 yoiko bbackupd[27200]: TRACE: Reallocating EncodingBuffer from 3244 to 5022\n Aug 15 00:53:50 yoiko bbackupd[27200]: TRACE: Exception thrown: ConnectionException(Conn_TLSReadFailed) at SocketStreamTLS.cpp(361)\n Aug 15 00:53:50 yoiko bbackupd[27200]: TRACE: Exception thrown: ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n Aug 15 00:53:51 yoiko bbackupd[27200]: Exception caught (Connection TLSReadFailed 7/34), reset state and waiting to retry... Aug 15 00:54:01 yoiko bbackupd[27200]: File statistics: total file size uploaded 1618579183, bytes already on server 34367041, encoded size 1074365947 Aug 15 00:54:01 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 01:11:05 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 01:28:09 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 01:45:13 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 02:02:17 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 02:19:21 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 02:36:25 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 02:53:29 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 03:10:33 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 03:27:37 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 03:44:41 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 04:01:45 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 04:18:49 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 04:35:52 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 04:52:56 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 05:10:00 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 05:27:04 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 05:44:08 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 06:01:12 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 06:18:16 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 06:35:20 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 06:52:24 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 07:09:28 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 07:26:32 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 07:43:36 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 08:00:40 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 08:17:44 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 08:34:48 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 08:51:52 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 09:08:55 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 09:25:59 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 09:43:03 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 10:00:07 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 10:17:11 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 10:34:15 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 10:51:19 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 11:08:23 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 11:25:27 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 11:42:31 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 11:59:35 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 12:16:39 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 12:33:43 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 12:50:47 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n Aug 15 13:07:51 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = 1024000000\n From boxbackup at fluffy.co.uk Tue Aug 15 18:50:38 2006 From: boxbackup at fluffy.co.uk (W. Chris Shank) Date: Tue, 15 Aug 2006 13:50:38 -0400 (EDT) Subject: [Box Backup] RegEx for Linux? Message-ID: <9907894.14281155664238659.JavaMail.root@banshee> Is there a seperate RegEx format for Linux? The hints in the conf file don't seem to work. Is that a BSD specific Regex format? -- W. Chris Shank ACE Technology Group, LLC www.myremoteITdept.com (610) 640-4223 -------------------------------- Security Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. From boxbackup at fluffy.co.uk Tue Aug 15 21:32:44 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Tue, 15 Aug 2006 21:32:44 +0100 Subject: [Box Backup] RegEx for Linux? In-Reply-To: <9907894.14281155664238659.JavaMail.root@banshee> References: <9907894.14281155664238659.JavaMail.root@banshee> Message-ID: <1155673964.22667.0.camel@avenin.ebourne.me.uk> On Tue, 2006-08-15 at 13:50 -0400, W. Chris Shank wrote: > Is there a seperate RegEx format for Linux? The hints in the conf file > don't seem to work. Is that a BSD specific Regex format? man 7 regex Martin. From boxbackup at fluffy.co.uk Tue Aug 15 22:20:00 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Tue, 15 Aug 2006 14:20:00 -0700 (PDT) Subject: [Box Backup] How to use NotifyScript, SyncAllowScript on Windows Message-ID: <20060815212000.82191.qmail@web60624.mail.yahoo.com> Hi all, Could anyone please help me use NotifyScript, SyncAllowScript on Windows? For NotifyScript, we need a Windows command line mailer, I think. I found these: http://support.microsoft.com/?kbid=192341 (mailto:) http://www.ss64.com/nt/mapisend.html (mapisend) The first (mailto:) will open the message, filled out with the info, but won't send it silently. The second (mapisend) requires the Back Office/Exchange Resource kit which I'm not able to install at the moment. Any other suggestions? Re SyncAllowScript, that should be easier, I suspect. But I'm lazy, and only got this far for a simple untested batch file: ::SyncAllowScript.bat ::pjalajas at tebuco.com 2006-08-15 ::License: http://www.gnu.org/licenses/gpl.txt ::For use with Box Backup on Windows, :: http://boxbackup.hostworks.ca/index.php/Main_Page :: See bbackupd.conf file for usage. :: ::This batch file is a draft work in progress. ::It probably doesn't work. ::Suggestions welcome. :: ::To only backup while on your primary network :: (e.g. not while traveling or at home), :: set MINE to a server on your primary network :: with a private IP address, like 192.168.1.1, :: or one not ping-able from the internet. :: @echo off set MINE="bb1.myboxbackupserver.com" ::Known good server, bad server, for testing set GOODONE="www.yahoo.com" set BADONE="junk" :: ::How long to wait before retry, in seconds set RETRYSECS=14400 :: ::Turn on the following lines for testing (remove ::) ::ping -n 1 %GOODONE%| find "Received = 1" > junk ::if %ERRORLEVEL% == 1 echo %RETRYSECS% ::ping -n 1 %GOODONE% | find "Received = 1" > junk ::if %ERRORLEVEL% == 0 echo now ::ping -n 1 %BADONE% | find "Received = 1" > junk ::if %ERRORLEVEL% == 1 echo %RETRYSECS% ::ping -n 1 %BADONE% | find "Received = 1" > junk ::if %ERRORLEVEL% == 0 echo now :: :: ping -n 1 %MINE% | find "Received = 1" > junk if %ERRORLEVEL% == 1 echo %RETRYSECS% ping -n 1 %MINE% | find "Received = 1" > junk if %ERRORLEVEL% == 0 echo now So, does anyone out there have anything better (please say yes)? This would be for using Box Backup 0.10 for Windows on laptops. Thanks, Pete From boxbackup at fluffy.co.uk Tue Aug 15 22:26:03 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 15 Aug 2006 22:26:03 +0100 (BST) Subject: [Box Backup] How to use NotifyScript, SyncAllowScript on Windows In-Reply-To: <20060815212000.82191.qmail@web60624.mail.yahoo.com> References: <20060815212000.82191.qmail@web60624.mail.yahoo.com> Message-ID: Hi Pete, On Tue, 15 Aug 2006, E.W. Peter Jalajas wrote: > Could anyone please help me use NotifyScript, SyncAllowScript on > Windows? How about a Perl script with Net::SMTP? > Re SyncAllowScript, that should be easier, I suspect. But I'm lazy, > and only got this far for a simple untested batch file: [...] > So, does anyone out there have anything better (please say yes)? This > would be for using Box Backup 0.10 for Windows on laptops. Your approach would probably work, but you might also try to check the output of "ipconfig" to check that the interface has media connected. Alternatively, a Perl script using Net::Ping could check the reachability of hosts. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Wed Aug 16 00:25:49 2006 From: boxbackup at fluffy.co.uk (Pierre-Yves) Date: 16 Aug 2006 01:25:49 +0200 Subject: [Box Backup] How to use NotifyScript, SyncAllowScript on Windows In-Reply-To: <20060815212000.82191.qmail@web60624.mail.yahoo.com> References: <20060815212000.82191.qmail@web60624.mail.yahoo.com> Message-ID: <1155684349.18979.6.camel@Knoppix> Le mar 15/08/2006 ? 23:20, E.W. Peter Jalajas a ?crit : > Hi all, > > Could anyone please help me use NotifyScript, SyncAllowScript on > Windows? > > For NotifyScript, we need a Windows command line mailer, I think. I > found these: > http://support.microsoft.com/?kbid=192341 (mailto:) > http://www.ss64.com/nt/mapisend.html (mapisend) > > The first (mailto:) will open the message, filled out with the info, > but won't send it silently. > > The second (mapisend) requires the Back Office/Exchange Resource kit > which I'm not able to install at the moment. > > Any other suggestions? > Hello I use bmail or mailsend (google 'em) in various scripts. bmail is sortof 'self-contained', while mailsend need to know about your external SMTP server. -- Pierre-Yves From boxbackup at fluffy.co.uk Wed Aug 16 07:04:46 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Tue, 15 Aug 2006 23:04:46 -0700 (PDT) Subject: [Box Backup] How to use NotifyScript, SyncAllowScript on Windows In-Reply-To: <1155684349.18979.6.camel@Knoppix> Message-ID: <20060816060446.74601.qmail@web60624.mail.yahoo.com> Thanks, Pierre-Yves and Chris, I've decided to use cygwin (instead of Perl or the other tools), because installing that gives me the email tool, but also great command line tools for grepping and schlepping (sp?) "bbackupquery quit" output, among lots of other functionality. It's also quite ubiquitous, and I trust it. So, for the How To and google, I installed cygwin, added the email and ssmtp packages (not sure if I needed ssmtp), then ran ssmtp-config (again, not sure if I needed this), and email-config. I then created C:\Program Files\Box Backup\NotifySysadmin2.sh shell script file, listing below. Then in a Windows cmd window, I ran: C:\>c:\cygwin\bin\sh "C:\Program Files\Box Backup\NotifySysadmin2.sh" store-full (or read-error or other) and then I get appropriate emails in my other mailbox. I haven't tested this script being launched by the Box Backup client yet, but I hope to do so in a few days. It probably won't work, but I'll resolve the problems as they come up. Thanks again, Pete #!/bin/sh #NotifySysadmin2.sh #Based on original NotifySysadmin.sh from Box Backup 0.10. #Modified by pjalajas @ tebuco.com 2006-08-16. #For use on Box Backup clients on Windows with Cygwin. #Draft, under development. Please submit improvements. #Use at your own risk. #Uses cygwin, with package "email" (and maybe ssmtp) installed. #After installing package email, run email-config. # #I comment out these variables because they are instead set in email-config (/etc/email/email.conf). #SENDFROM="bbclient at xxx.com" #SMTPSERVER="mail.www.com" #SMTPUSER="user" #SMTPPASSWD="123" #SENDMAIL="/usr/sbin/sendmail" #Setup an underprivileged user account on the mail server for this... #SENDMAILOPTIONS="-m login -r $SMTPSERVER -u $SMTPUSER -i $SMTPPASSWD -n 'Backup SysAdmin' -f $SENDFROM " #I think the box backup account number is all you need, not the "server" or client host name, but I'm not sure. #BBSERVER="rocio" #BBCLIENT="bbclient" SENDMAIL="/usr/bin/email" SENDTO="bbsysadmin at tebuco.com" BBACCOUNT="10001001" MDATE=$(/usr/bin/date) SUBJECT="BACKUP PROBLEM at Account ${BBACCOUNT} ${MDATE}" if [ $1 = store-full ] then $SENDMAIL -s "${SUBJECT} store-full" $SENDTO < wrote: > Le mar 15/08/2006 ??? 23:20, E.W. Peter Jalajas a ???crit : > > Hi all, > > > > Could anyone please help me use NotifyScript, SyncAllowScript on > > Windows? > > > > For NotifyScript, we need a Windows command line mailer, I think. > I > > found these: > > http://support.microsoft.com/?kbid=192341 (mailto:) > > http://www.ss64.com/nt/mapisend.html (mapisend) > > > > The first (mailto:) will open the message, filled out with the > info, > > but won't send it silently. > > > > The second (mapisend) requires the Back Office/Exchange Resource > kit > > which I'm not able to install at the moment. > > > > Any other suggestions? > > > > Hello > > I use bmail or mailsend (google 'em) in various scripts. bmail is > sortof > 'self-contained', while mailsend need to know about your external > SMTP > server. > > -- > Pierre-Yves > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Thu Aug 17 16:42:20 2006 From: boxbackup at fluffy.co.uk (Jesus Climent) Date: Thu, 17 Aug 2006 17:42:20 +0200 Subject: [Box Backup] LLONG_MAX configure mistake with gcc 4.1.1 (Linux) In-Reply-To: <4491ED33.6080104@hickinbottom.demon.co.uk> References: <448A6BD1.2050103@hickinbottom.demon.co.uk> <1149935851.2858.3.camel@avenin.ebourne.me.uk> <4491BC66.7030503@hickinbottom.demon.co.uk> <1150409169.19910.36.camel@avenin.ebourne.me.uk> <4491ED33.6080104@hickinbottom.demon.co.uk> Message-ID: <20060817154220.GF22353@erconde.hispalinux.es> On Fri, Jun 16, 2006 at 12:28:51AM +0100, Stuart Hickinbottom wrote: > > Whilst it might not hit as many people as I first thought, I'm still > pretty convinced it won't compile for people with GCC 4.1.1 if they > don't have the definitions for LLONG_MAX and LLONG_MIN (as seems to be > the case on my Gentoo Linux). Same here with debian unstable: gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10) And the error is the same: BackupQueries.cpp:1697: error: 'LLONG_MIN' was not declared in this scope BackupQueries.cpp:1697: error: 'LLONG_MAX' was not declared in this scope make[1]: *** [../../release/bin/bbackupquery/BackupQueries.o] Error 1 -- Jesus Climent info:www.pumuki.org dj:triplestereo.com Unix SysAdm|Linux User #66350|Debian Developer|2.6.17|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Don't "Sir" me young man, you have no idea who you're dealing with. --Kay (Men in Black) From boxbackup at fluffy.co.uk Thu Aug 17 17:06:22 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Thu, 17 Aug 2006 17:06:22 +0100 Subject: [Box Backup] LLONG_MAX configure mistake with gcc 4.1.1 (Linux) In-Reply-To: <20060817154220.GF22353@erconde.hispalinux.es> References: <448A6BD1.2050103@hickinbottom.demon.co.uk> <1149935851.2858.3.camel@avenin.ebourne.me.uk> <4491BC66.7030503@hickinbottom.demon.co.uk> <1150409169.19910.36.camel@avenin.ebourne.me.uk> <4491ED33.6080104@hickinbottom.demon.co.uk> <20060817154220.GF22353@erconde.hispalinux.es> Message-ID: <20060817170622.qwr9sc1280c8o004@ebourne.me.uk> Jesus Climent wrote: > And the error is the same: > BackupQueries.cpp:1697: error: 'LLONG_MIN' was not declared in this scope > BackupQueries.cpp:1697: error: 'LLONG_MAX' was not declared in this scope > make[1]: *** [../../release/bin/bbackupquery/BackupQueries.o] Error 1 Fixed in svn. Please check out trunk and try again. Cheers, Martin. From boxbackup at fluffy.co.uk Fri Aug 18 05:24:24 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Thu, 17 Aug 2006 21:24:24 -0700 (PDT) Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client Message-ID: <20060818042424.9544.qmail@web60625.mail.yahoo.com> Hi all, especially Chris, We are installing Chris' new client on a Win2k server for a new client. And we are getting this error. Our BackupLocations below. We are using a mapped drive T. (We are trying a trick of using my new SyncAllowScript.bat to ping the mapped computer (instead of the more traditional, I guess, backup store) before running the backup, to avoid having everything marked as deleted and reuploaded if the mapped computer goes away temporarily for any reason; keep your fingers crossed.) Any ideas on the error: vfork not implemented - LocalProcessStream.cpp ? Thanks, Pete D:\Program Files\Box Backup>bbackupd -c "D:\Program Files\Box Backup\bbackupd.conf" -i No random device -- additional seeding of random number generator not performed. Box Backup Client vchris_general_777M, (c) Ben Summers and contributors 2003-2006 ============================================================================== SECURITY WARNING: This platform cannot check the credentials of connections to the command socket. This is a potential DoS security problem. Remove the CommandSocket directive from the bbackupd.conf file if bbackupctl is not used. ============================================================================== Starting daemon (config: D:\Program Files\Box Backup\bbackupd.conf) (version chris_general_777M) vfork not implemented - LocalProcessStream.cpp D:\Program Files\Box Backup> ======================== Should the Path T: be T:\? BackupLocations { T { Path = T: ExcludeFilesRegex = T:\Program Files\Box Backup\.*-FileEncKeys.raw ExcludeFile = T:\pagefile.sys ExcludeDir = T:\windows\Temp\ ExcludeDir = T:\Temp\ ExcludeDir = T:\windows\system32\LogFiles\ ExcludeDir = T:\Documents and Settings\Default User.WINNT\Local Settings\Temporary Internet Files\ } } BackupLocations { T { Path = T: ExcludeFilesRegex = T:\Program Files\Box Backup\.*-FileEncKeys.raw ExcludeFile = T:\pagefile.sys ExcludeDir = T:\windows\Temp\ ExcludeDir = T:\Temp\ ExcludeDir = T:\windows\system32\LogFiles\ ExcludeDir = T:\Documents and Settings\Default User.WINNT\Local Settings\Temporary Internet Files\ } } From boxbackup at fluffy.co.uk Fri Aug 18 09:42:14 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 18 Aug 2006 09:42:14 +0100 (BST) Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client In-Reply-To: <20060818042424.9544.qmail@web60625.mail.yahoo.com> References: <20060818042424.9544.qmail@web60625.mail.yahoo.com> Message-ID: Hi Pete, > We are installing Chris' new client on a Win2k server for a new client. [...] > (We are trying a trick of using my new SyncAllowScript.bat [...] > Any ideas on the error: vfork not implemented - LocalProcessStream.cpp Yes, sorry, SyncAllowScript is not implemented on Windows. I didn't realise this because there are no unit tests for it. There is a dummy stub which generates this error message. It is possible to do, I will look into it. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Fri Aug 18 09:48:58 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Fri, 18 Aug 2006 09:48:58 +0100 Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client In-Reply-To: References: <20060818042424.9544.qmail@web60625.mail.yahoo.com> Message-ID: <03427E74-4F1C-4E5C-A4C6-468BEB4CA916@fluffy.co.uk> On 18 Aug 2006, at 09:42, Chris Wilson wrote: > Hi Pete, > >> We are installing Chris' new client on a Win2k server for a new >> client. > [...] >> (We are trying a trick of using my new SyncAllowScript.bat > [...] >> Any ideas on the error: vfork not implemented - >> LocalProcessStream.cpp > > Yes, sorry, SyncAllowScript is not implemented on Windows. I didn't > realise this because there are no unit tests for it. There is a > dummy stub which generates this error message. > > It is possible to do, I will look into it. Just in case you haven't seen this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dllproc/base/ creating_a_child_process_with_redirected_input_and_output.asp Ben From boxbackup at fluffy.co.uk Fri Aug 18 13:48:40 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Fri, 18 Aug 2006 05:48:40 -0700 (PDT) Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client In-Reply-To: <03427E74-4F1C-4E5C-A4C6-468BEB4CA916@fluffy.co.uk> Message-ID: <20060818124840.23901.qmail@web60618.mail.yahoo.com> Thanks, guys. Here's tinyurl of the msdn link: http://tinyurl.com/guro . I am also trying to use the NotifyScript and cygwin email--is there anything I should know about that? Thanks again, Pete --- Ben Summers wrote: > > On 18 Aug 2006, at 09:42, Chris Wilson wrote: > > > Hi Pete, > > > >> We are installing Chris' new client on a Win2k server for a new > >> client. > > [...] > >> (We are trying a trick of using my new SyncAllowScript.bat > > [...] > >> Any ideas on the error: vfork not implemented - > >> LocalProcessStream.cpp > > > > Yes, sorry, SyncAllowScript is not implemented on Windows. I didn't > > > realise this because there are no unit tests for it. There is a > > dummy stub which generates this error message. > > > > It is possible to do, I will look into it. > > Just in case you haven't seen this: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ > dllproc/base/ > creating_a_child_process_with_redirected_input_and_output.asp > > Ben > > > > > > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Sat Aug 19 17:00:41 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sat, 19 Aug 2006 17:00:41 +0100 (BST) Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client In-Reply-To: <20060818124840.23901.qmail@web60618.mail.yahoo.com> References: <20060818124840.23901.qmail@web60618.mail.yahoo.com> Message-ID: Hi Pete, SyncAllowScript should be fixed in the latest build, 784, just released. Please test it and let me know if you find any problems. > I am also trying to use the NotifyScript and cygwin email--is there > anything I should know about that? Please be aware that you may not be able to run a Cygwin program (such as perl, bash or mail) from Box Backup. I don't know for sure whether or not it works. Also, you must use a Windows path in bbackupd.conf, not a Unix path. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Sat Aug 19 17:05:02 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Sat, 19 Aug 2006 09:05:02 -0700 (PDT) Subject: [Box Backup] vfork not implemented - LocalProcessStream.cpp on chris_general_777M Windows client In-Reply-To: Message-ID: <20060819160503.5178.qmail@web60625.mail.yahoo.com> Wow, great, Chris, thanks for jumping on it so quickly! We'll try it out and report back our results. Probably middle of next week sometime. Caveats duly noted. Thanks again! Pete --- Chris Wilson wrote: > Hi Pete, > > SyncAllowScript should be fixed in the latest build, 784, just > released. > Please test it and let me know if you find any problems. > > > I am also trying to use the NotifyScript and cygwin email--is there > > > anything I should know about that? > > Please be aware that you may not be able to run a Cygwin program > (such as > perl, bash or mail) from Box Backup. I don't know for sure whether or > not > it works. Also, you must use a Windows path in bbackupd.conf, not a > Unix > path. > > Cheers, Chris. > -- > _ ___ __ _ > / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | > / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | > \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Tue Aug 22 14:28:54 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Tue, 22 Aug 2006 15:28:54 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? Message-ID: <44EB0696.6010100@kontrapunkt.com> Hello.... I have just discovered af very wierd pattern in my problems with boxbackup. When I start bbackupctl manually on the client with the command "/usr/local/bin/bbackupctl -c /etc/box_minimoni/bbackupd.conf sync" the backup always completes successfully. When run from my crontab as seen below, it always fails with the message: exception Connection Protocol_Timeout (Probably a network issue between client and server.) (7/41) From my crontab: 0 10 * * * /usr/local/bin/bbackupctl -c /etc/box_minimoni/bbackupd.conf sync Client OS X 10.4 Server Debian Any thoughts ? Tobias From boxbackup at fluffy.co.uk Tue Aug 22 14:53:25 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Tue, 22 Aug 2006 14:53:25 +0100 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB0696.6010100@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> Message-ID: <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> Tobias Balle-Petersen wrote: > From my crontab: > 0 10 * * * /usr/local/bin/bbackupctl -c /etc/box_minimoni/bbackupd.conf sync What happens if you start it at a different time of day? Cheers, Martin. From boxbackup at fluffy.co.uk Tue Aug 22 16:38:58 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Tue, 22 Aug 2006 17:38:58 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> Message-ID: <44EB2512.7010207@kontrapunkt.com> I have been running the cronjob at different times a day. I used to run the cronjob at night. I then had successfull manual runs during the day. I decided to move the cronjob to the same time as the sucessfull manual runs. Tobias Martin Ebourne wrote: > Tobias Balle-Petersen wrote: >> From my crontab: >> 0 10 * * * /usr/local/bin/bbackupctl -c >> /etc/box_minimoni/bbackupd.conf sync > > What happens if you start it at a different time of day? > > Cheers, > > Martin. > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Tue Aug 22 18:32:44 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Tue, 22 Aug 2006 10:32:44 -0700 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB2512.7010207@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> Message-ID: <44EB3FBC.9030603@reedtz.com> On 8/22/06 8:38 AM, tbp wrote: > I have been running the cronjob at different times a day. I used to > run the cronjob at night. I then had successfull manual runs during > the day. I decided to move the cronjob to the same time as the > sucessfull manual runs. This is a bit odd... Just trying to cover all the bases.. Couple of questions: * Does this happen when backing up a specific file? Or a specific time during the run (e.g.: always 20 minutes into the run)? * What happens when you run manually at the time that the cron job was failing? * Is the user the same on the cron job, as on the manual run? * Is the cron problem related to a particular file? (Debug build should tell you the file being backed up) Thanks, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Tue Aug 22 19:37:00 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Tue, 22 Aug 2006 20:37:00 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB3FBC.9030603@reedtz.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> Message-ID: <44EB4ECC.2020007@kontrapunkt.com> Hello... The cronjob seems to fail within the 1st hour. A successful run is about 6 hours. I don't think I have done a manual run at the exact same time as the cronjob. The user is the same ion the manual and crontab runs (root) Should the debug build tell me what file is being backed up? I have never noticed. I will run again with the debug build and report back. Tobias Per Thomsen wrote: > On 8/22/06 8:38 AM, tbp wrote: > >> I have been running the cronjob at different times a day. I used to >> run the cronjob at night. I then had successfull manual runs during >> the day. I decided to move the cronjob to the same time as the >> sucessfull manual runs. >> > This is a bit odd... > > Just trying to cover all the bases.. Couple of questions: > > * Does this happen when backing up a specific file? Or a specific > time during the run (e.g.: always 20 minutes into the run)? > * What happens when you run manually at the time that the cron job > was failing? > * Is the user the same on the cron job, as on the manual run? > * Is the cron problem related to a particular file? (Debug build > should tell you the file being backed up) > > Thanks, > Per > > From boxbackup at fluffy.co.uk Tue Aug 22 20:14:31 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Tue, 22 Aug 2006 12:14:31 -0700 (PDT) Subject: [Box Backup] Generating private key, certificate request on Windows, bbackupd-config Message-ID: <20060822191431.20316.qmail@web60621.mail.yahoo.com> Hi all, I'd like to try to start generating keys on windows (win32) to give my clients a little more independence. http://boxbackup.hostworks.ca/index.php/Configuring_a_client and http://www.reedtz.com/boxdoc/adminguide/ch01.html#id2966650 say: Run the bbackupd-config script to generate the configuration files and generate a private key and certificate request. /usr/local/bin/bbackupd-config /etc/box lazy 999 hostname /var/bbackupd /home Google reports openssl for windows here: http://gnuwin32.sourceforge.net/packages/openssl.htm and here: http://www.openssl.org/related/binaries.html (I don't know anything about either of them.) (Cygwin also comes with openssl.) Am I delusional to think that I could try to port all or most of bbackupd-config to Windows? Or is there some new easier way todo this these days? Thanks, Pete From boxbackup at fluffy.co.uk Tue Aug 22 20:20:28 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 22 Aug 2006 20:20:28 +0100 Subject: [Box Backup] Generating private key, certificate request on Windows, bbackupd-config In-Reply-To: <20060822191431.20316.qmail@web60621.mail.yahoo.com> References: <20060822191431.20316.qmail@web60621.mail.yahoo.com> Message-ID: <99A28989-53B5-4DF6-8C56-2730470497EE@fluffy.co.uk> On 22 Aug 2006, at 20:14, E.W. Peter Jalajas wrote: > Hi all, > > I'd like to try to start generating keys on windows (win32) to give my > clients a little more independence. > > http://boxbackup.hostworks.ca/index.php/Configuring_a_client > and > http://www.reedtz.com/boxdoc/adminguide/ch01.html#id2966650 > say: > > Run the bbackupd-config script to generate the configuration > files > and generate a private key and certificate request. > > /usr/local/bin/bbackupd-config /etc/box lazy 999 hostname > /var/bbackupd /home > > Google reports openssl for windows here: > http://gnuwin32.sourceforge.net/packages/openssl.htm > and here: > http://www.openssl.org/related/binaries.html > (I don't know anything about either of them.) > (Cygwin also comes with openssl.) > > Am I delusional to think that I could try to port all or most of > bbackupd-config to Windows? Or is there some new easier way todo this > these days? perl scripts using openssl are purely because I'm lazy. What really needs to be done is to rewrite bbackupd-config in C++ so it can do the certificate generation itself. Using the openssl API isn't too tricky. Ben From boxbackup at fluffy.co.uk Tue Aug 22 20:57:22 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 22 Aug 2006 20:57:22 +0100 (BST) Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: <44E1B652.3010704@kontrapunkt.com> References: <44E1B652.3010704@kontrapunkt.com> Message-ID: Hi Tobias, Sorry for the delay in getting back to you. On Tue, 15 Aug 2006, Tobias Balle-Petersen wrote: > My boxbackup 0.10 client never seems to retry after an error har occured > as seen below. [...] > Aug 15 00:53:50 yoiko bbackupd[27200]: TRACE: Exception thrown: > ConnectionException(Conn_TLSReadFailed) at SocketStreamTLS.cpp(361)\n > Aug 15 00:53:50 yoiko bbackupd[27200]: TRACE: Exception thrown: > ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n > Aug 15 00:53:51 yoiko bbackupd[27200]: Exception caught (Connection > TLSReadFailed 7/34), reset state and waiting to retry... > Aug 15 00:54:01 yoiko bbackupd[27200]: File statistics: total file size > uploaded 1618579183, bytes already on server 34367041, encoded size > 1074365947 > Aug 15 00:54:01 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = > 1024000000\n > Aug 15 01:11:05 yoiko bbackupd[27200]: TRACE: Wait on command socket, delay = > 1024000000\n [...] I will look into this now. I assume that since you're running a debug version of bbackupd, you don't mind compiling it yourself? Therefore, if I create a new Subversion branch with some debugging code added, would you be able to check it out from Subversion, compile it and try it instead of your current version? Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 22 21:09:41 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 22 Aug 2006 21:09:41 +0100 (BST) Subject: [Box Backup] Generating private key, certificate request on Windows, bbackupd-config In-Reply-To: <20060822191431.20316.qmail@web60621.mail.yahoo.com> References: <20060822191431.20316.qmail@web60621.mail.yahoo.com> Message-ID: Hi Pete, On Tue, 22 Aug 2006, E.W. Peter Jalajas wrote: > I'd like to try to start generating keys on windows (win32) to give my > clients a little more independence. [...] > Google reports openssl for windows here: [...] > (Cygwin also comes with openssl.) > > Am I delusional to think that I could try to port all or most of > bbackupd-config to Windows? Or is there some new easier way todo this > these days? You are quite possibly delusional :-) I have serious doubts that you could run bbackupd-config on a non-Unixish system. Cygwin on Windows might be a good bet, but is of course very heavyweight for the task. MinGW + MSYS might also work, but I've never tried MSYS so I can't say. Boxi has a GUI wizard for generating certificates in the new version, that links directly to the relevant OpenSSL code, so it doesn't require any Unix shell or openssl.exe. I haven't compiled it on Windows yet, but it's one of my next priorities, and I intend to give you a pre-pre-prerelease for testing as soon as I have done so, which I hope will be in the next two weeks. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 22 21:10:38 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Tue, 22 Aug 2006 13:10:38 -0700 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB4ECC.2020007@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> Message-ID: <44EB64BE.9090306@reedtz.com> On 8/22/06 11:37 AM, tbp wrote: > Hello... > > The cronjob seems to fail within the 1st hour. A successful run is > about 6 hours. Why does the backup take 6 hours? A lot of data, or a slow connection? > > I don't think I have done a manual run at the exact same time as the > cronjob. As I said, I'm just trying to cover all the bases. I don't know if the problem is related to the timing of the runs. > > The user is the same ion the manual and crontab runs (root) OK. > > Should the debug build tell me what file is being backed up? I have > never noticed. > I will run again with the debug build and report back. Actually, AFAICT, turning on ExtendedLogging gives you the filenames in the logs on the client. No need to run debug builds, near as I can tell. If the same file (or type/size/location) is the culprit every time, you'll have to figure out what's different about this file. Finally, I just want to make sure you're using the 'KeepAliveTime" parameter in the bbackupd.conf file. You're receiving a timeout error, so I just want to eliminate the lack of that parameter as the reason. Thanks, Per > > Tobias > > Per Thomsen wrote: >> On 8/22/06 8:38 AM, tbp wrote: >> >>> I have been running the cronjob at different times a day. I used to >>> run the cronjob at night. I then had successfull manual runs during >>> the day. I decided to move the cronjob to the same time as the >>> sucessfull manual runs. >>> >> This is a bit odd... >> >> Just trying to cover all the bases.. Couple of questions: >> >> * Does this happen when backing up a specific file? Or a specific >> time during the run (e.g.: always 20 minutes into the run)? >> * What happens when you run manually at the time that the cron job >> was failing? >> * Is the user the same on the cron job, as on the manual run? >> * Is the cron problem related to a particular file? (Debug build >> should tell you the file being backed up) >> >> Thanks, >> Per >> >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Tue Aug 22 21:15:46 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 22 Aug 2006 21:15:46 +0100 (BST) Subject: [Box Backup] Generating private key, certificate request on Windows, bbackupd-config In-Reply-To: <99A28989-53B5-4DF6-8C56-2730470497EE@fluffy.co.uk> References: <20060822191431.20316.qmail@web60621.mail.yahoo.com> <99A28989-53B5-4DF6-8C56-2730470497EE@fluffy.co.uk> Message-ID: Hi Ben and Pete, On Tue, 22 Aug 2006, Ben Summers wrote: > perl scripts using openssl are purely because I'm lazy. What really > needs to be done is to rewrite bbackupd-config in C++ so it can do the > certificate generation itself. Using the openssl API isn't too tricky. You're welcome to rip that code out of Boxi. I'll happy relicense it under the Boxi license or BSD or whatever, since those files in Boxi are actually under the OpenSSL license anyway, due to my having stolen a lot of code directly from OpenSSL. Look in src/SetupWizard.cc. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 22 21:18:46 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Tue, 22 Aug 2006 22:18:46 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB64BE.9090306@reedtz.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> Message-ID: <44EB66A6.2060405@kontrapunkt.com> Hello.... Per Thomsen wrote: > On 8/22/06 11:37 AM, tbp wrote: > >> Hello... >> >> The cronjob seems to fail within the 1st hour. A successful run is >> about 6 hours. >> > Why does the backup take 6 hours? A lot of data, or a slow connection? > There is a lot of data. >> I don't think I have done a manual run at the exact same time as the >> cronjob. >> > As I said, I'm just trying to cover all the bases. I don't know if the > problem is related to the timing of the runs. > I am now running cron at 10 in the morning. It fails, but when I do manual runs during the day they always complete. >> The user is the same ion the manual and crontab runs (root) >> > OK. > >> Should the debug build tell me what file is being backed up? I have >> never noticed. >> I will run again with the debug build and report back. >> > Actually, AFAICT, turning on ExtendedLogging gives you the filenames in > the logs on the client. > I don't remember ever having seen the filenames of files being backed up even with extended logging on. Would all files be listed as the are evaluated, or just the new files that are to be added to the store? > No need to run debug builds, near as I can tell. > > If the same file (or type/size/location) is the culprit every time, > you'll have to figure out what's different about this file. > > Finally, I just want to make sure you're using the 'KeepAliveTime" > parameter in the bbackupd.conf file. You're receiving a timeout error, > so I just want to eliminate the lack of that parameter as the reason. > KeepAliveTime is 10 > Thanks, > Per > >> Tobias >> >> Per Thomsen wrote: >> >>> On 8/22/06 8:38 AM, tbp wrote: >>> >>> >>>> I have been running the cronjob at different times a day. I used to >>>> run the cronjob at night. I then had successfull manual runs during >>>> the day. I decided to move the cronjob to the same time as the >>>> sucessfull manual runs. >>>> >>>> >>> This is a bit odd... >>> >>> Just trying to cover all the bases.. Couple of questions: >>> >>> * Does this happen when backing up a specific file? Or a specific >>> time during the run (e.g.: always 20 minutes into the run)? >>> * What happens when you run manually at the time that the cron job >>> was failing? >>> * Is the user the same on the cron job, as on the manual run? >>> * Is the cron problem related to a particular file? (Debug build >>> should tell you the file being backed up) >>> >>> Thanks, >>> Per >>> >>> >>> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > > From boxbackup at fluffy.co.uk Tue Aug 22 21:27:48 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Tue, 22 Aug 2006 13:27:48 -0700 (PDT) Subject: [Box Backup] Generating private key, certificate request on Windows, bbackupd-config In-Reply-To: Message-ID: <20060822202748.79303.qmail@web60618.mail.yahoo.com> Hi Chris, :^) Yeah, no, I would just take the meaty command lines out (no environment or error checking, no directory or config file or notifyscript creation, no instructions to the user, etc.). Maybe just install one of the openssl binaries and then run these in a windows batch file: openssl genrsa -out $private_key 2048 openssl req -new -key $private_key -sha1 -out $certificate_request openssl rand -out $enc_key_file 1024 Does that make sense? Great to hear about boxi! I can't wait to test it. Thanks Chris, Pete --- Chris Wilson wrote: > Hi Pete, > > On Tue, 22 Aug 2006, E.W. Peter Jalajas wrote: > > > I'd like to try to start generating keys on windows (win32) to give > my > > clients a little more independence. > [...] > > Google reports openssl for windows here: > [...] > > (Cygwin also comes with openssl.) > > > > Am I delusional to think that I could try to port all or most of > > bbackupd-config to Windows? Or is there some new easier way todo > this > > these days? > > You are quite possibly delusional :-) I have serious doubts that you > could > run bbackupd-config on a non-Unixish system. Cygwin on Windows might > be > a good bet, but is of course very heavyweight for the task. MinGW + > MSYS > might also work, but I've never tried MSYS so I can't say. > > Boxi has a GUI wizard for generating certificates in the new version, > that > links directly to the relevant OpenSSL code, so it doesn't require > any > Unix shell or openssl.exe. > > I haven't compiled it on Windows yet, but it's one of my next > priorities, > and I intend to give you a pre-pre-prerelease for testing as soon as > I > have done so, which I hope will be in the next two weeks. From boxbackup at fluffy.co.uk Tue Aug 22 22:42:17 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 22 Aug 2006 22:42:17 +0100 (BST) Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: References: <44E1B652.3010704@kontrapunkt.com> Message-ID: Hi Tobias, On Tue, 22 Aug 2006, Chris Wilson wrote: > I will look into this now. I assume that since you're running a debug > version of bbackupd, you don't mind compiling it yourself? Therefore, if > I create a new Subversion branch with some debugging code added, would > you be able to check it out from Subversion, compile it and try it > instead of your current version? Assuming that you don't mind getting checking code out of Subversion, please could you check out and build from this URL, and let me know what the debugging log messages say after an exception? [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] If you don't want to use Subversion, I can send you a tarball of that code. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Wed Aug 23 06:08:17 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Tue, 22 Aug 2006 22:08:17 -0700 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EB66A6.2060405@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> Message-ID: <44EBE2C1.3000706@reedtz.com> On 8/22/06 1:18 PM, tbp wrote: > Hello.... > > I don't remember ever having seen the filenames of files being backed > up even with extended logging on. > Would all files be listed as the are evaluated, or just the new files > that are to be added to the store? Only files that are sent to the store. Here's an example of what I'm seeing with 'ExtendedLogging = yes': Aug 20 04:35:07 mostro bbackupd[2125]: Send StoreFile(0x2f16,0x41b70ed5684c0,0x57a46e0d1741a059,0xce6c,"index.html") Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced0) Aug 20 04:35:07 mostro bbackupd[2125]: Send StoreFile(0x2f16,0x41b70ed5684c0,0x974c3454965ac769,0x0,"usage.png") Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced1) You are not seeing anything like that on the client machine? These logs are from a 0.09 installation, but I think this should log the same on 0.10. >> >> Finally, I just want to make sure you're using the 'KeepAliveTime" >> parameter in the bbackupd.conf file. You're receiving a timeout error, >> so I just want to eliminate the lack of that parameter as the reason. >> > > KeepAliveTime is 10 OK. I guess there is no harm in using the 10 second number. I believe the SSL timeout is 180 seconds, so I set my KeepAliveTime to 90. Don't know that it would have any impact. Thanks, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Wed Aug 23 07:25:38 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Wed, 23 Aug 2006 08:25:38 +0200 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: References: <44E1B652.3010704@kontrapunkt.com> Message-ID: <44EBF4E2.6040308@kontrapunkt.com> Hello... As I'm not fammiliar with Subversion, a tarball would probably be easier for me. Thank you, Tobias Chris Wilson wrote: > Hi Tobias, > > On Tue, 22 Aug 2006, Chris Wilson wrote: > >> I will look into this now. I assume that since you're running a debug >> version of bbackupd, you don't mind compiling it yourself? Therefore, >> if I create a new Subversion branch with some debugging code added, >> would you be able to check it out from Subversion, compile it and try >> it instead of your current version? > > Assuming that you don't mind getting checking code out of Subversion, > please could you check out and build from this URL, and let me know > what the debugging log messages say after an exception? > > [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] > > If you don't want to use Subversion, I can send you a tarball of that > code. > > Cheers, Chris. From boxbackup at fluffy.co.uk Wed Aug 23 10:58:48 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Wed, 23 Aug 2006 11:58:48 +0200 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: References: <44E1B652.3010704@kontrapunkt.com> Message-ID: <44EC26D8.5090905@kontrapunkt.com> Hello.... I checked out the code using svn. How should I compile? Tobias Chris Wilson wrote: > Hi Tobias, > > On Tue, 22 Aug 2006, Chris Wilson wrote: > >> I will look into this now. I assume that since you're running a debug >> version of bbackupd, you don't mind compiling it yourself? Therefore, >> if I create a new Subversion branch with some debugging code added, >> would you be able to check it out from Subversion, compile it and try >> it instead of your current version? > > Assuming that you don't mind getting checking code out of Subversion, > please could you check out and build from this URL, and let me know > what the debugging log messages say after an exception? > > [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] > > If you don't want to use Subversion, I can send you a tarball of that > code. > > Cheers, Chris. From boxbackup at fluffy.co.uk Wed Aug 23 11:05:21 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Wed, 23 Aug 2006 12:05:21 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EBE2C1.3000706@reedtz.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> Message-ID: <44EC2861.2030701@kontrapunkt.com> I am now running the debug version with extended logging. Actually, I think the 1st time the cronjob (bbackupctl) runs after a restart of bbackupd, the run completes. Following cronjobs do not. Starting bbackupctl manually does complete. I will let my cronjob run for two days and repport back with resulat and logs. Thanks, Tobias Per Thomsen wrote: > On 8/22/06 1:18 PM, tbp wrote: > >> Hello.... >> >> I don't remember ever having seen the filenames of files being backed >> up even with extended logging on. >> Would all files be listed as the are evaluated, or just the new files >> that are to be added to the store? >> > Only files that are sent to the store. Here's an example of what I'm > seeing with 'ExtendedLogging = yes': > > Aug 20 04:35:07 mostro bbackupd[2125]: Send > StoreFile(0x2f16,0x41b70ed5684c0,0x57a46e0d1741a059,0xce6c,"index.html") > Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain > Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced0) > Aug 20 04:35:07 mostro bbackupd[2125]: Send > StoreFile(0x2f16,0x41b70ed5684c0,0x974c3454965ac769,0x0,"usage.png") > Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain > Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced1) > > You are not seeing anything like that on the client machine? These logs > are from a 0.09 installation, but I think this should log the same on > 0.10. > >>> Finally, I just want to make sure you're using the 'KeepAliveTime" >>> parameter in the bbackupd.conf file. You're receiving a timeout error, >>> so I just want to eliminate the lack of that parameter as the reason. >>> >>> >> KeepAliveTime is 10 >> > OK. I guess there is no harm in using the 10 second number. I believe > the SSL timeout is 180 seconds, so I set my KeepAliveTime to 90. Don't > know that it would have any impact. > > Thanks, > Per > > From boxbackup at fluffy.co.uk Wed Aug 23 15:44:02 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Wed, 23 Aug 2006 16:44:02 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EC2861.2030701@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> Message-ID: <44EC69B2.2050101@kontrapunkt.com> Hello.... After having restarted bbackupd, bbackupctl has run with succes as a cronjob as seen below (from the server log). I expect the cronjob to fail on following runs. Will report back. Aug 23 10:00:00 localhost bbstored[3502]: Incoming connection from 192.168.0.51 port 61680 (handling in child 31602) Aug 23 10:00:00 localhost bbstored[31602]: Certificate CN: BACKUP-A Aug 23 10:00:00 localhost bbstored[31602]: Login: Client ID 0000000A, Read/Write Aug 23 10:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 10:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 11:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 11:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 12:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 12:19:26 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 13:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 13:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 14:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 14:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 15:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 15:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 16:19:25 localhost bbstored/hk[3503]: Starting housekeeping Aug 23 16:19:25 localhost bbstored/hk[3503]: Finished housekeeping Aug 23 16:28:01 localhost bbstored[31602]: Session finished Aug 23 16:28:01 localhost bbstored[31602]: Connection statistics for BACKUP-A: IN=3473254520 OUT=808297300 TOTAL=4281551820 Thanks, Tobias Tobias Balle-Petersen wrote: > > I am now running the debug version with extended logging. > > Actually, I think the 1st time the cronjob (bbackupctl) runs after a > restart of bbackupd, the run completes. > Following cronjobs do not. Starting bbackupctl manually does complete. > > I will let my cronjob run for two days and repport back with resulat > and logs. > > Thanks, > Tobias > > > > Per Thomsen wrote: >> On 8/22/06 1:18 PM, tbp wrote: >> >>> Hello.... >>> >>> I don't remember ever having seen the filenames of files being backed >>> up even with extended logging on. >>> Would all files be listed as the are evaluated, or just the new files >>> that are to be added to the store? >>> >> Only files that are sent to the store. Here's an example of what I'm >> seeing with 'ExtendedLogging = yes': >> >> Aug 20 04:35:07 mostro bbackupd[2125]: Send >> StoreFile(0x2f16,0x41b70ed5684c0,0x57a46e0d1741a059,0xce6c,"index.html") >> Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain >> Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced0) >> Aug 20 04:35:07 mostro bbackupd[2125]: Send >> StoreFile(0x2f16,0x41b70ed5684c0,0x974c3454965ac769,0x0,"usage.png") >> Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain >> Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced1) >> You are not seeing anything like that on the client machine? These logs >> are from a 0.09 installation, but I think this should log the same on >> 0.10. >>>> Finally, I just want to make sure you're using the 'KeepAliveTime" >>>> parameter in the bbackupd.conf file. You're receiving a timeout error, >>>> so I just want to eliminate the lack of that parameter as the reason. >>>> >>> KeepAliveTime is 10 >>> >> OK. I guess there is no harm in using the 10 second number. I believe >> the SSL timeout is 180 seconds, so I set my KeepAliveTime to 90. Don't >> know that it would have any impact. >> >> Thanks, >> Per >> >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Wed Aug 23 17:30:15 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Wed, 23 Aug 2006 09:30:15 -0700 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: <44EC26D8.5090905@kontrapunkt.com> References: <44E1B652.3010704@kontrapunkt.com> <44EC26D8.5090905@kontrapunkt.com> Message-ID: <44EC8297.6040202@reedtz.com> On 8/23/06 2:58 AM, Tobias Balle-Petersen wrote: > Hello.... > > I checked out the code using svn. How should I compile? The instructions for building from an SVN pull are here: http://boxbackup.hostworks.ca/index.php/Source_code_repository* Thanks, Per * -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Thu Aug 24 11:14:00 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Thu, 24 Aug 2006 12:14:00 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EC69B2.2050101@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> <44EC69B2.2050101@kontrapunkt.com> Message-ID: <44ED7BE8.4070003@kontrapunkt.com> Hello... As expected, the scond time bbackupctl was run as a cronjob it failed. Log from the client seen below. I have just performed a "/usr/local/bin/bbackupctl -c /etc/box_minimoni/bbackupd.conf reload" I expect this to allow the next run started from the crontab to be run without errors. Will report back. Thanks, Tobias Log from client: Aug 24 10:00:00 yoiko bbackupd[11514]: Incoming connection from local (UNIX socket) Aug 24 10:00:00 yoiko bbackupd[11514]: Connection from command socket Aug 24 10:00:00 yoiko bbackupd[11514]: TRACE: Receiving command 'sync' over command socket\n Aug 24 10:00:00 yoiko bbackupd[11514]: TRACE: Receiving command 'quit' over command socket\n Aug 24 10:00:00 yoiko bbackupd[11514]: TRACE: Closing command connection\n Aug 24 10:00:00 yoiko bbackupd[11514]: Beginning scan of local files Aug 24 10:00:00 yoiko bbackupd[11514]: Opening connection to server minimoni.local.kontrapunkt.dk... Aug 24 10:00:00 yoiko bbackupd[11514]: TRACE: Send block allocation size is 4\n Aug 24 10:00:01 yoiko bbackupd[11514]: Connection made, login successful Aug 24 10:00:01 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:00:01 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5420\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2674\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Diff: 3170 new bytes found, 22 old blocks used\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 16 old blocks used\n Aug 24 10:00:05 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:00:09 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:00:13 yoiko bbackupd[11514]: TRACE: Diff: 3629 new bytes found, 234 old blocks used\n Aug 24 10:00:13 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:01:37 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Billund Airport/1773 Oversigtskort og P-skilte\n Aug 24 10:01:37 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Billund Airport/Billund Airport 02.01.06\n Aug 24 10:01:37 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Billund Airport/untitled folder\n Aug 24 10:02:38 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2240\n Aug 24 10:02:38 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2240 to 2985\n ............ Aug 24 10:13:01 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2907 to 5044\n Aug 24 10:13:02 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:03 yoiko bbackupd[11514]: TRACE: Diff: 1067257 new bytes found, 2 old blocks used\n Aug 24 10:13:03 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:03 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:03 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5173\n Aug 24 10:13:04 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2862\n Aug 24 10:13:04 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2862 to 5038\n Aug 24 10:13:05 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:08 yoiko bbackupd[11514]: TRACE: Diff: 1248547 new bytes found, 2104 old blocks used\n Aug 24 10:13:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2092 to 4268\n Aug 24 10:13:09 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2342\n Aug 24 10:13:09 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2342 to 4418\n Aug 24 10:13:10 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Diff: 438272 new bytes found, 1446 old blocks used\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2870\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2870 to 3834\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3834 to 5741\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5276\n Aug 24 10:13:22 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:24 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 1919 old blocks used\n Aug 24 10:13:24 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:24 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:26 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 1920 old blocks used\n Aug 24 10:13:26 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:30 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:30 yoiko bbackupd[11514]: TRACE: Diff: 8192 new bytes found, 1 old blocks used\n Aug 24 10:13:30 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:30 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:30 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5182\n Aug 24 10:13:32 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:32 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5173\n Aug 24 10:13:36 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:36 yoiko bbackupd[11514]: TRACE: Diff: 2746 new bytes found, 8 old blocks used\n Aug 24 10:13:36 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:36 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2909\n ....... Aug 24 10:13:39 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:40 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:13:40 yoiko bbackupd[11514]: TRACE: Diff: 4302 new bytes found, 6 old blocks used\n Aug 24 10:13:40 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:13:40 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:13:40 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5292\n ...... Aug 24 10:13:47 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2902 to 5078\n Aug 24 10:13:51 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:14:13 yoiko bbackupd[11514]: TRACE: Diff: 1419698 new bytes found, 952 old blocks used\n Aug 24 10:14:13 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:14:13 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1085 to 3015\n .......... Aug 24 10:14:37 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:14:37 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5390\n Aug 24 10:14:44 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:14:44 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 5 old blocks used\n Aug 24 10:14:44 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:01 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:01 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 311 old blocks used\n Aug 24 10:16:01 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:01 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:02 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 372 old blocks used\n Aug 24 10:16:02 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 15 old blocks used\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 37 old blocks used\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:16:03 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5155\n Aug 24 10:16:04 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:07 yoiko bbackupd[11514]: TRACE: Diff: 88 new bytes found, 815 old blocks used\n Aug 24 10:16:07 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Diff: 1253376 new bytes found, 1547 old blocks used\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2972\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2972 to 3969\n Aug 24 10:16:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3969 to 6039\n Aug 24 10:16:10 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:16:11 yoiko bbackupd[11514]: TRACE: Diff: 309001 new bytes found, 40 old blocks used\n Aug 24 10:16:11 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:16:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2594\n Aug 24 10:16:11 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2594 to 3255\n ............. Aug 24 10:16:42 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2889 to 5065\n Aug 24 10:16:43 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Cyncron/LR skitser\n Aug 24 10:16:43 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Cyncron/Rentegnet logo\n Aug 24 10:16:43 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Cyncron/Web og powerpoint\n Aug 24 10:18:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3013\n Aug 24 10:18:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3013 to 5129\n Aug 24 10:18:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:18:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5269\n Aug 24 10:18:11 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:18:22 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 2223 old blocks used\n Aug 24 10:18:22 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:18:28 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 10:18:29 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 3388\n Aug 24 10:18:29 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3388 to 4715\n Aug 24 10:18:44 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:18:45 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 158 old blocks used\n Aug 24 10:18:45 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:18:54 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: MaximumDiffingTime reached - suspending file diff\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: Diff: 112380809 new bytes found, 15 old blocks used\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1069 to 2669\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2669 to 3497\n Aug 24 10:20:17 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3497 to 3641\n Aug 24 10:20:57 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:20:57 yoiko bbackupd[11514]: TRACE: KeepAliveTime reached - initiating keep-alive\n Aug 24 10:20:57 yoiko bbackupd[11514]: TRACE: Diff: 5712 new bytes found, 175 old blocks used\n Aug 24 10:20:57 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:20:57 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2587\n Aug 24 10:20:58 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:20:59 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 180 old blocks used\n Aug 24 10:20:59 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 8 old blocks used\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes found, 83 old blocks used\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2440\n Aug 24 10:21:02 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Diff: 286720 new bytes found, 2426 old blocks used\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2528\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2528 to 2672\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes found, 85 old blocks used\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:07 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2591\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes found, 27 old blocks used\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2381\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes found, 37 old blocks used\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2559\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes found, 20 old blocks used\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2333\n Aug 24 10:23:29 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n .......... Aug 24 11:06:37 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2950 to 4406\n Aug 24 11:07:09 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Diff: 117248 new bytes found, 3833 old blocks used\n Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2617\n Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2617 to 3596\n Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3596 to 5415\n Aug 24 11:07:30 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 11:07:37 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, 1440 old blocks used\n Aug 24 11:07:37 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 11:08:03 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Diff: 14336 new bytes found, 725 old blocks used\n Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 4998\n Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Diff: 11776 new bytes found, 894 old blocks used\n Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5133\n Aug 24 11:11:23 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2849\n Aug 24 11:11:23 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2849 to 5025\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Initiated timer for file diff control\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Diff: 880838 new bytes found, 152 old blocks used\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Suspended timer for file diff control\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2601\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 2601 to 4777\n Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 2606\n ................... Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 1068 to 3244\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Reallocating EncodingBuffer from 3244 to 5413\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/recruitment_ms\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/recruitment_tos\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/recruitment2_ms\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/re.kmo\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/recruitment transport fredag\n Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/re.transp.mandag\n Aug 24 11:20:28 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/Medicon\n Aug 24 11:20:28 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/clients/MOUNT\n Aug 24 11:20:44 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/guests/Bergen Bybane\n Aug 24 11:20:44 yoiko bbackupd[11514]: TRACE: Deleted directory record for /Volumes/raidA/files/guests/Library1\n Aug 24 11:41:58 yoiko bbackupd[11514]: TRACE: Exception thrown: ConnectionException(Conn_TLSReadFailed) at SocketStreamTLS.cpp(361)\n Aug 24 11:41:58 yoiko bbackupd[11514]: TRACE: Exception thrown: ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n Aug 24 11:41:59 yoiko bbackupd[11514]: Exception caught (Connection TLSReadFailed 7/34), reset state and waiting to retry... Aug 24 11:42:09 yoiko bbackupd[11514]: File statistics: total file size uploaded 13410118455, bytes already on server 341406646, encoded size 9996343505 Aug 24 11:42:09 yoiko bbackupd[11514]: TRACE: Wait on command socket, delay = 1024000000\n Aug 24 11:59:13 yoiko bbackupd[11514]: TRACE: Wait on command socket, delay = 1024000000\n Tobias Balle-Petersen wrote: > Hello.... > > After having restarted bbackupd, bbackupctl has run with succes as a > cronjob as seen below (from the server log). > > I expect the cronjob to fail on following runs. Will report back. > > > Aug 23 10:00:00 localhost bbstored[3502]: Incoming connection from > 192.168.0.51 port 61680 (handling in child 31602) > Aug 23 10:00:00 localhost bbstored[31602]: Certificate CN: BACKUP-A > Aug 23 10:00:00 localhost bbstored[31602]: Login: Client ID 0000000A, > Read/Write > Aug 23 10:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 10:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 11:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 11:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 12:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 12:19:26 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 13:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 13:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 14:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 14:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 15:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 15:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 16:19:25 localhost bbstored/hk[3503]: Starting housekeeping > Aug 23 16:19:25 localhost bbstored/hk[3503]: Finished housekeeping > Aug 23 16:28:01 localhost bbstored[31602]: Session finished > Aug 23 16:28:01 localhost bbstored[31602]: Connection statistics for > BACKUP-A: IN=3473254520 OUT=808297300 TOTAL=4281551820 > > > Thanks, > Tobias > > > > Tobias Balle-Petersen wrote: >> >> I am now running the debug version with extended logging. >> >> Actually, I think the 1st time the cronjob (bbackupctl) runs after a >> restart of bbackupd, the run completes. >> Following cronjobs do not. Starting bbackupctl manually does complete. >> >> I will let my cronjob run for two days and repport back with resulat >> and logs. >> >> Thanks, >> Tobias >> >> >> >> Per Thomsen wrote: >>> On 8/22/06 1:18 PM, tbp wrote: >>> >>>> Hello.... >>>> >>>> I don't remember ever having seen the filenames of files being backed >>>> up even with extended logging on. >>>> Would all files be listed as the are evaluated, or just the new files >>>> that are to be added to the store? >>>> >>> Only files that are sent to the store. Here's an example of what I'm >>> seeing with 'ExtendedLogging = yes': >>> >>> Aug 20 04:35:07 mostro bbackupd[2125]: Send >>> StoreFile(0x2f16,0x41b70ed5684c0,0x57a46e0d1741a059,0xce6c,"index.html") >>> >>> Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain >>> Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced0) >>> Aug 20 04:35:07 mostro bbackupd[2125]: Send >>> StoreFile(0x2f16,0x41b70ed5684c0,0x974c3454965ac769,0x0,"usage.png") >>> Aug 20 04:35:07 mostro bbackupd[2125]: Sending stream, size uncertain >>> Aug 20 04:35:07 mostro bbackupd[2125]: Receive Success(0xced1) You >>> are not seeing anything like that on the client machine? These logs >>> are from a 0.09 installation, but I think this should log the same on >>> 0.10. >>>>> Finally, I just want to make sure you're using the 'KeepAliveTime" >>>>> parameter in the bbackupd.conf file. You're receiving a timeout >>>>> error, >>>>> so I just want to eliminate the lack of that parameter as the reason. >>>>> >>>> KeepAliveTime is 10 >>>> >>> OK. I guess there is no harm in using the 10 second number. I believe >>> the SSL timeout is 180 seconds, so I set my KeepAliveTime to 90. Don't >>> know that it would have any impact. >>> >>> Thanks, >>> Per >>> >>> >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Thu Aug 24 12:18:26 2006 From: boxbackup at fluffy.co.uk (Tobias Balle-Petersen) Date: Thu, 24 Aug 2006 13:18:26 +0200 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: References: <44E1B652.3010704@kontrapunkt.com> Message-ID: <44ED8B02.4030009@kontrapunkt.com> Hello... I have checked out your code: svn checkout http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug box_retry_debug Compiled: ./bootstrap && ./configure && make Tested: ./runtest.pl bbackupd IMPLICIT TEST FAILED: Something left files open FAILED: 1 tests failed Should I ignore the test results? Should I replace my bbackupd on the client with the one in the bin directory? Thanks, Tobias Chris Wilson wrote: > Hi Tobias, > > On Tue, 22 Aug 2006, Chris Wilson wrote: > >> I will look into this now. I assume that since you're running a debug >> version of bbackupd, you don't mind compiling it yourself? Therefore, >> if I create a new Subversion branch with some debugging code added, >> would you be able to check it out from Subversion, compile it and try >> it instead of your current version? > > Assuming that you don't mind getting checking code out of Subversion, > please could you check out and build from this URL, and let me know > what the debugging log messages say after an exception? > > [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] > > If you don't want to use Subversion, I can send you a tarball of that > code. > > Cheers, Chris. From boxbackup at fluffy.co.uk Thu Aug 24 12:24:57 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 24 Aug 2006 12:24:57 +0100 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: <44ED8B02.4030009@kontrapunkt.com> References: <44E1B652.3010704@kontrapunkt.com> <44ED8B02.4030009@kontrapunkt.com> Message-ID: On 24 Aug 2006, at 12:18, Tobias Balle-Petersen wrote: > Hello... > > I have checked out your code: > svn checkout http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug > box_retry_debug > > Compiled: > ./bootstrap && ./configure && make > > Tested: > ./runtest.pl bbackupd > > IMPLICIT TEST FAILED: Something left files open > FAILED: 1 tests failed > > > > Should I ignore the test results? That particular error is OK, a result of the syslog socket not being closed. Ben > > Should I replace my bbackupd on the client with the one in the bin > directory? > > > Thanks, > Tobias > > > Chris Wilson wrote: >> Hi Tobias, >> >> On Tue, 22 Aug 2006, Chris Wilson wrote: >> >>> I will look into this now. I assume that since you're running a >>> debug version of bbackupd, you don't mind compiling it yourself? >>> Therefore, if I create a new Subversion branch with some >>> debugging code added, would you be able to check it out from >>> Subversion, compile it and try it instead of your current version? >> >> Assuming that you don't mind getting checking code out of >> Subversion, please could you check out and build from this URL, >> and let me know what the debugging log messages say after an >> exception? >> >> [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] >> >> If you don't want to use Subversion, I can send you a tarball of >> that code. >> >> Cheers, Chris. > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup From boxbackup at fluffy.co.uk Thu Aug 24 12:41:33 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Thu, 24 Aug 2006 13:41:33 +0200 Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: References: <44E1B652.3010704@kontrapunkt.com> <44ED8B02.4030009@kontrapunkt.com> Message-ID: <44ED906D.3060506@kontrapunkt.com> Hello.... OK, I'll ignore the error. Should I use the bbackupd in the bin directory ? Tobias Ben Summers wrote: > > On 24 Aug 2006, at 12:18, Tobias Balle-Petersen wrote: > >> Hello... >> >> I have checked out your code: >> svn checkout http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug >> box_retry_debug >> >> Compiled: >> ./bootstrap && ./configure && make >> >> Tested: >> ./runtest.pl bbackupd >> >> IMPLICIT TEST FAILED: Something left files open >> FAILED: 1 tests failed >> >> >> >> Should I ignore the test results? > > That particular error is OK, a result of the syslog socket not being > closed. > > Ben > > > > > >> >> Should I replace my bbackupd on the client with the one in the bin >> directory? >> >> >> Thanks, >> Tobias >> >> >> Chris Wilson wrote: >>> Hi Tobias, >>> >>> On Tue, 22 Aug 2006, Chris Wilson wrote: >>> >>>> I will look into this now. I assume that since you're running a >>>> debug version of bbackupd, you don't mind compiling it yourself? >>>> Therefore, if I create a new Subversion branch with some debugging >>>> code added, would you be able to check it out from Subversion, >>>> compile it and try it instead of your current version? >>> >>> Assuming that you don't mind getting checking code out of >>> Subversion, please could you check out and build from this URL, and >>> let me know what the debugging log messages say after an exception? >>> >>> [http://bbdev.fluffy.co.uk/svn/box/chris/retry-debug] >>> >>> If you don't want to use Subversion, I can send you a tarball of >>> that code. >>> >>> Cheers, Chris. >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Thu Aug 24 13:08:44 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 24 Aug 2006 13:08:44 +0100 (BST) Subject: [Box Backup] TLSReadFailed - Retry never occurs?? [boxbackup 0.10 - OS X 10.4 client - Debian server] In-Reply-To: <44ED906D.3060506@kontrapunkt.com> References: <44E1B652.3010704@kontrapunkt.com> <44ED8B02.4030009@kontrapunkt.com> <44ED906D.3060506@kontrapunkt.com> Message-ID: Hi Tobias, > OK, I'll ignore the error. Should I use the bbackupd in the bin > directory ? Yes, debug/bin/bbackupd. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Thu Aug 24 15:02:54 2006 From: boxbackup at fluffy.co.uk (Per Thomsen) Date: Thu, 24 Aug 2006 07:02:54 -0700 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44ED7BE8.4070003@kontrapunkt.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> <44EC69B2.2050101@kontrapunkt.com> <44ED7BE8.4070003@kontrapunkt.com> Message-ID: <44EDB18E.8020808@reedtz.com> On 8/24/06 3:14 AM, Tobias Balle-Petersen wrote: > Hello... > > As expected, the scond time bbackupctl was run as a cronjob it > failed. Log from the client seen below. > > I have just performed a "/usr/local/bin/bbackupctl -c > /etc/box_minimoni/bbackupd.conf reload" > I expect this to allow the next run started from the crontab to be run > without errors. Will report back. > > Thanks, > Tobias > > Log from client: > [snip] > Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Diff: 12288 new bytes > found, 20 old blocks used\n > Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 10:21:08 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 2333\n > Aug 24 10:23:29 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 3244\n > .......... > Aug 24 11:06:37 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 2950 to 4406\n > Aug 24 11:07:09 yoiko bbackupd[11514]: TRACE: Initiated timer for file > diff control\n > Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Diff: 117248 new bytes > found, 3833 old blocks used\n > Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 2617\n > Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 2617 to 3596\n > Aug 24 11:07:13 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 3596 to 5415\n > Aug 24 11:07:30 yoiko bbackupd[11514]: TRACE: Initiated timer for file > diff control\n > Aug 24 11:07:37 yoiko bbackupd[11514]: TRACE: Diff: 0 new bytes found, > 1440 old blocks used\n > Aug 24 11:07:37 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 11:08:03 yoiko bbackupd[11514]: TRACE: Initiated timer for file > diff control\n > Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Diff: 14336 new bytes > found, 725 old blocks used\n > Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 3244\n > Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 3244 to 4998\n > Aug 24 11:08:04 yoiko bbackupd[11514]: TRACE: Initiated timer for file > diff control\n > Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Diff: 11776 new bytes > found, 894 old blocks used\n > Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 3244\n > Aug 24 11:08:05 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 3244 to 5133\n > Aug 24 11:11:23 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 2849\n > Aug 24 11:11:23 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 2849 to 5025\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Initiated timer for file > diff control\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Diff: 880838 new bytes > found, 152 old blocks used\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Suspended timer for file > diff control\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 2601\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 2601 to 4777\n > Aug 24 11:11:27 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 2606\n > ................... > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 1068 to 3244\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Reallocating > EncodingBuffer from 3244 to 5413\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo > Nordisk/Recruitment/recruitment_ms\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo > Nordisk/Recruitment/recruitment_tos\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo > Nordisk/Recruitment/recruitment2_ms\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/re.kmo\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo Nordisk/Recruitment/recruitment > transport fredag\n > Aug 24 11:16:19 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Novo > Nordisk/Recruitment/re.transp.mandag\n > Aug 24 11:20:28 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/Medicon\n > Aug 24 11:20:28 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/clients/MOUNT\n > Aug 24 11:20:44 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/guests/Bergen Bybane\n > Aug 24 11:20:44 yoiko bbackupd[11514]: TRACE: Deleted directory record > for /Volumes/raidA/files/guests/Library1\n Seems like the problem occurs here... More than 20 minutes with no logging. Just looking at directories, I guess... > Aug 24 11:41:58 yoiko bbackupd[11514]: TRACE: Exception thrown: > ConnectionException(Conn_TLSReadFailed) at SocketStreamTLS.cpp(361)\n > Aug 24 11:41:58 yoiko bbackupd[11514]: TRACE: Exception thrown: > ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(426)\n > Aug 24 11:41:59 yoiko bbackupd[11514]: Exception caught (Connection > TLSReadFailed 7/34), reset state and waiting to retry... > Aug 24 11:42:09 yoiko bbackupd[11514]: File statistics: total file > size uploaded 13410118455, bytes already on server 341406646, encoded > size 9996343505 > Aug 24 11:42:09 yoiko bbackupd[11514]: TRACE: Wait on command socket, > delay = 1024000000\n > Aug 24 11:59:13 yoiko bbackupd[11514]: TRACE: Wait on command socket, > delay = 1024000000\n > It seems from the logs that the error occurs while scanning the client directories. I don't know if the directory-scanning code has been changed to use the keep-alives. Does anyone know if the keep-alives are only implemented in file-diffing, or if they are also used in the overall directory scanning? Gary? Are you using the (I forget what the feature is called) Berkeley DB local cache of file state? I don't know if this could have anything to do with what's going on... As for why the manual works, and the cron fails, I have no idea... Thanks, Per -- Per Reedtz Thomsen | Reedtz Consulting, LLC | F: 209 883 4119 V: 209 883 4102 | pthomsen at reedtz.com | C: 209 996 9561 GPG ID: 1209784F | Yahoo! Chat: pthomsen | AIM: pthomsen From boxbackup at fluffy.co.uk Thu Aug 24 15:18:44 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 24 Aug 2006 15:18:44 +0100 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EDB18E.8020808@reedtz.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> <44EC69B2.2050101@kontrapunkt.com> <44ED7BE8.4070003@kontrapunkt.com> <44EDB18E.8020808@reedtz.com> Message-ID: On 24 Aug 2006, at 15:02, Per Thomsen wrote: >> > It seems from the logs that the error occurs while scanning the client > directories. I don't know if the directory-scanning code has been > changed to use the keep-alives. Does anyone know if the keep-alives > are > only implemented in file-diffing, or if they are also used in the > overall directory scanning? Gary? > > Are you using the (I forget what the feature is called) Berkeley DB > local cache of file state? I don't know if this could have anything to > do with what's going on... Stop daemon, delete the contents of /var/bbackupd, start daemon. That will wipe any directory tracking. This is different to saving the state. > > As for why the manual works, and the cron fails, I have no idea... Yes, very strange. Ben From boxbackup at fluffy.co.uk Thu Aug 24 17:05:27 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Thu, 24 Aug 2006 18:05:27 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: <44EDB18E.8020808@reedtz.com> References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> <44EC69B2.2050101@kontrapunkt.com> <44ED7BE8.4070003@kontrapunkt.com> <44EDB18E.8020808@reedtz.com> Message-ID: <44EDCE47.30501@kontrapunkt.com> Per Thomsen wrote: > Are you using the (I forget what the feature is called) Berkeley DB > local cache of file state? I don't know if this could have anything to > do with what's going on... > How do I tell? Something I need to decide on at compile time? Thanks, Tobias From boxbackup at fluffy.co.uk Thu Aug 24 17:07:44 2006 From: boxbackup at fluffy.co.uk (tbp) Date: Thu, 24 Aug 2006 18:07:44 +0200 Subject: [Box Backup] bbackupctl always fails when run from crontab. Manual always OK? In-Reply-To: References: <44EB0696.6010100@kontrapunkt.com> <20060822145325.4kq6a0g6osw8g04s@ebourne.me.uk> <44EB2512.7010207@kontrapunkt.com> <44EB3FBC.9030603@reedtz.com> <44EB4ECC.2020007@kontrapunkt.com> <44EB64BE.9090306@reedtz.com> <44EB66A6.2060405@kontrapunkt.com> <44EBE2C1.3000706@reedtz.com> <44EC2861.2030701@kontrapunkt.com> <44EC69B2.2050101@kontrapunkt.com> <44ED7BE8.4070003@kontrapunkt.com> <44EDB18E.8020808@reedtz.com> Message-ID: <44EDCED0.4010307@kontrapunkt.com> Ben Summers wrote: > Stop daemon, delete the contents of /var/bbackupd, start daemon. That > will wipe any directory tracking. This is different to saving the state. I will give it at try when I get back to work next week. Thanks, Tobias From boxbackup at fluffy.co.uk Fri Aug 25 00:34:52 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Thu, 24 Aug 2006 16:34:52 -0700 (PDT) Subject: [Box Backup] Results of Testing 784 version on Win2K Message-ID: <20060824233452.60534.qmail@web60620.mail.yahoo.com> Hi all, We installed Chris' 784 version on Windows 2K SP4 today. In summary, it's working and backing up 100MB's of files from a mapped drive (protected by SyncAllowScript), as we e-speak. A few items to note below. Thanks, Pete ----- We are backing up from a mapped drive. Yeah! We shared out that drive with fairly secure permissions, including full access to the backup user on the box backup client system. (I think we need a naming convention...) (I wonder if we can lock it down further by sharing it out to only those two users from only that one box backup client. ) Trying to backup from the hidden/admin c$ share did NOT work; we just reshared out that same directory under a new name and with special permissions. Some errors that we saw before we shared out the mapped system correctly: Failed to open T:\ error 5. Trying UNC: Failed to open '\\voyager\c$': error 123 Flailing: Failed to open '\\voyager\c': error 123 Exception 1/9, Check Permissions. ---Don't know what error 5 or error 123 are. SyncAllowScript.bat seems to work fine in this experimental special case of testing for the presence of the mapped system (not for testing for access to the backup store; see my other thread). We should probably not rely on ping to prove that the mapped system is ready, so I tried a simple dir T: > junk, and that seemed to work, the meat of which is: set RETRYSECS=14400 ::ping -n 1 %MINE% | find "Received = 1" > junk dir T: > junk if %ERRORLEVEL% == 1 echo %RETRYSECS% ::ping -n 1 %MINE% | find "Received = 1" > junk dir T: > junk if %ERRORLEVEL% == 0 echo now (Testing to an unmapped Z: drive caused box backup to correctly report that it was waiting for 14400 seconds to retry.) POSSIBLE BUG: When stopping the service, we sometimes get "the instruction at...referenced memory at... The memory could not be read." Could very well be bad memory on the computer, it has a history of problems, but it could be that it gives that error when we stop the service when it is trying to deal with, or recently dealt with, a file it can't backup for whatever reason. (Remember, we're backing up from a mapped drive.) After we got it working, when we saw the warnings and errors on various odd files in the Event Viewer, sometimes box backup would continue on backing up other files, but other times, it would essentially finish the session and appear to wait for the next go-round. To avoid these, we simply excluded those problem files in ExcludeFile and ExcludeDir; for some, we put the "file" under both ExcludeFile and ExcludeDir (like a problematic .zip file, e.g.). See BackupLocations section below. We are also using KeepAliveTime for the first time. Not sure how to evaluate it. FEATURE REQUEST: We are also using NotifyAdmin.sh with cygwin. It works from the cmd window, but doesn't seem to be working when we saw an "error 5" file: "Failed to open 'T:\NTDETECT.COM': error 5" seems to stop further scanning, and doesn't seem to send mail. NotifySysadmin.sh needed [[ ]] instead of [ ] around if statements on this box for some reason. The working BackupLocations: BackupLocations { T { Path = T: #ExcludeFilesRegex = T:\\Program Files\\Box Backup\\.*-FileEncKeys\.raw$ ExcludeFile = T:\pagefile.sys ExcludeDir = T:\pagefile.sys ExcludeFile = T:\boot.ini ExcludeFile = T:\NTDETECT.COM ExcludeDir = T:\WUTemp ExcludeDir = T:\System Volume Information ExcludeFile = T:\N1 server.zip ExcludeDir = T:\N1 server.zip ExcludeFile = T:\ntldr ExcludeDir = T:\license ExcludeDir = T:\windows\Temp\ ExcludeDir = T:\Temp\ ExcludeDir = T:\windows\system32\LogFiles\ ExcludeDir = T:\Documents and Settings\Default User.WINNT\Local Settings\Temporary Internet Files\ } } Oops, I see my inconsistent use of trailing slashes in ExcludeDir. I'll check that next time we go in. BUG: Directories show up with 1969 Dec 31, 19:00:00 dates under bbackupquery list. BUG: Last and least, event log shows this version as 777M. ***PLEASE NOTE***: I will be on vacation in Maine from Friday Aug 25 through Sunday Sep 3, 2006. ASK ME about the EXCITING new TebucoSafe(TM) web-based automated secure off-site backup service! Never think about backups again! As low as $19/mo. http://tebuco.com/bu/ E.W. Peter Jalajas Tebuco, Inc. | Technical Business Consulting pjalajas at tebuco.com | http://tebuco.com/ cell: 978-495-2062 | (secondary phone: 978-465-7047 x27) PO Box 1223, Newburyport, MA 01950-8223 Automated, secure, off-site, on-line backup service. On-site and remote technical support. From boxbackup at fluffy.co.uk Sat Aug 26 06:19:57 2006 From: boxbackup at fluffy.co.uk (E.W. Peter Jalajas) Date: Fri, 25 Aug 2006 22:19:57 -0700 (PDT) Subject: [Box Backup] Backing up the backup store with rsync, write.lock files Message-ID: <20060826051957.93124.qmail@web60615.mail.yahoo.com> Hi all, I'm starting to build a geographically remote machine to which to rsync my primary box backup store. My intent is to design that remote server so that "The server is trusted only to make files available when they are required", to cop a phrase. I've setup rsync with ssh keys (inspired by Troy Johnson at http://www.jdmz.net/ssh/ "Using Rsync and SSH") to automatically push from the store server to the remote server every few hours. I set this up to run as a user to be used only for this purpose, username "rsync1" on both machines. The command that I'll run on the server store machine will be something like: rsync -azvu --delete --stats -e "ssh -p 8023 -i $KEY" /home/rsync1/rsyncbu rsync1 at mainstore:/backupstore where $KEY is the path/filename of the private key. I'm comfortable that I can get all my store files backed up this way, except for all of the write.lock files because they have 600 permissions with user _bbstored (see a related thread here: http://lists.warhead.org.uk/pipermail/boxbackup/2006-May/002550.html ) I don't care if I'm missing the write.lock files for this purpose, do I? Thanks, Pete P.S. I'm on the US East Coast, and I have a buddy in Oregon on the West Coast, several thousand miles away, who is willing to plug an rsync server box like the one described above into his network for me so that I can get real geographically distant redundancy. But I wonder if maybe I should instead find another Box Backup devotee on the Left Coast to trade rsync boxes with... ;^) From boxbackup at fluffy.co.uk Sun Aug 27 22:27:00 2006 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sun, 27 Aug 2006 22:27:00 +0100 (BST) Subject: [Box Backup] Results of Testing 784 version on Win2K In-Reply-To: <20060824233452.60534.qmail@web60620.mail.yahoo.com> References: <20060824233452.60534.qmail@web60620.mail.yahoo.com> Message-ID: Hi Pete, > Some errors that we saw before we shared out the mapped system > correctly: > Failed to open T:\ error 5. > Trying UNC: Failed to open '\\voyager\c$': error 123 > Flailing: Failed to open '\\voyager\c': error 123 > Exception 1/9, Check Permissions. > ---Don't know what error 5 or error 123 are. Error 5 is Access Denied, error 123 is Invalid Name. I've added better error messages for these cases in Subversion, next build should have them. > POSSIBLE BUG: When stopping the service, we sometimes get "the > instruction at...referenced memory at... The memory could not be read." Please give me the address values from the error message when this happens. Box always stops cleanly for me. > After we got it working, when we saw the warnings and errors on various > odd files in the Event Viewer, sometimes box backup would continue on > backing up other files, but other times, it would essentially finish > the session and appear to wait for the next go-round. If you see this, please report any details that you can, and I'll try to debug it. > We are also using KeepAliveTime for the first time. Not sure how to > evaluate it. SSL sessions don't crash when diffing large files :-) > FEATURE REQUEST: We are also using NotifyAdmin.sh with cygwin. It > works from the cmd window, but doesn't seem to be working when we saw > an "error 5" file: "Failed to open 'T:\NTDETECT.COM': error 5" seems > to stop further scanning, and doesn't seem to send mail. OK, will investigate when I have a chance. > ExcludeDir = T:\windows\Temp\ > ExcludeDir = T:\Temp\ > ExcludeDir = T:\windows\system32\LogFiles\ > ExcludeDir = T:\Documents and Settings\Default > User.WINNT\Local Settings\Temporary Internet Files\ These will not work, trailing backslashes will mean that they never match. > BUG: Directories show up with 1969 Dec 31, 19:00:00 dates under > bbackupquery list. I think Box Backup always does this? > BUG: Last and least, event log shows this version as 777M. Sorry, I obviously forgot to do a clean rebuild :-( Thanks for testing! Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From boxbackup at fluffy.co.uk Tue Aug 29 00:45:20 2006 From: boxbackup at fluffy.co.uk (Alex Howansky) Date: Mon, 28 Aug 2006 18:45:20 -0500 (CDT) Subject: [Box Backup] Suggestion Message-ID: I just accidentally ran bbackupd-config a second time on an established server, and it overwrite my bbackupd.conf file. Not a big deal in this case, there were only two locations to put back -- but it could have been a real pain had I made the same mistake on another larger server. I wonder if anybody has a problem with modding bbackupd-config such that it will abort if bbackupd.conf already exists. I'll submit a patch if you like, but it's pretty trivial and I'm not sure if aborting with an error or making a backup copy is preferable. -- Alex Howansky Wankwood Associates http://wankwood.com/ From boxbackup at fluffy.co.uk Tue Aug 29 08:41:47 2006 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Tue, 29 Aug 2006 08:41:47 +0100 Subject: [Box Backup] Suggestion In-Reply-To: References: Message-ID: <1156837308.2429.6.camel@avenin.ebourne.me.uk> On Mon, 2006-08-28 at 18:45 -0500, Alex Howansky wrote: > I just accidentally ran bbackupd-config a second time on an established server, > and it overwrite my bbackupd.conf file. Not a big deal in this case, there were > only two locations to put back -- but it could have been a real pain had I made > the same mistake on another larger server. I wonder if anybody has a problem > with modding bbackupd-config such that it will abort if bbackupd.conf already > exists. I'll submit a patch if you like, but it's pretty trivial and I'm not > sure if aborting with an error or making a backup copy is preferable. Aborting with an error and then allowing -f or similar to override would be my preference. Cheers, Martin. From boxbackup at fluffy.co.uk Tue Aug 29 09:34:30 2006 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 29 Aug 2006 09:34:30 +0100 Subject: [Box Backup] Backing up the backup store with rsync, write.lock files In-Reply-To: <20060826051957.93124.qmail@web60615.mail.yahoo.com> References: <20060826051957.93124.qmail@web60615.mail.yahoo.com> Message-ID: <6A0C132B-0D02-499B-BD41-97A0CC86ACC9@fluffy.co.uk> On 26 Aug 2006, at 06:19, E.W. Peter Jalajas wrote: > Hi all, > > I'm starting to build a geographically remote machine to which to > rsync > my primary box backup store. My intent is to design that remote > server > so that "The server is trusted only to make files available when they > are required", to cop a phrase. > > I've setup rsync with ssh keys (inspired by Troy Johnson at > http://www.jdmz.net/ssh/ "Using Rsync and SSH") to automatically push > from the store server to the remote server every few hours. I set > this > up to run as a user to be used only for this purpose, username > "rsync1" > on both machines. The command that I'll run on the server store > machine will be something like: > > rsync -azvu --delete --stats -e "ssh -p 8023 -i $KEY" > /home/rsync1/rsyncbu rsync1 at mainstore:/backupstore > > where $KEY is the path/filename of the private key. > > I'm comfortable that I can get all my store files backed up this way, > except for all of the write.lock files because they have 600 > permissions with user _bbstored (see a related thread here: > http://lists.warhead.org.uk/pipermail/boxbackup/2006-May/002550.html ) > > I don't care if I'm missing the write.lock files for this purpose, do > I? You do not need to copy the write.lock file. It's only used as something to gain a flock() on to ensure only one process is writing to the store at any one time. It is created if it's not present. Remember to do a bbstoreaccounts check fix on the rsynced store before using it. > > P.S. I'm on the US East Coast, and I have a buddy in Oregon on the > West > Coast, several thousand miles away, who is willing to plug an rsync > server box like the one described above into his network for me so > that > I can get real geographically distant redundancy. But I wonder if > maybe I should instead find another Box Backup devotee on the Left > Coast to trade rsync boxes with... ;^) There is some interest in writing the code to do proper backup bbstored servers. This would involve keeping a list of dirty objects during a write session, then copying them over when done, and similarly for housekeeping. This is obviously a better way than rysnc. Ben