From boxbackup at fluffy.co.uk Tue Apr 3 09:18:01 2007 From: boxbackup at fluffy.co.uk (David Bamford) Date: Tue, 3 Apr 2007 09:18:01 +0100 (BST) Subject: [Box Backup] Compile errors with Debian Etch AMD64 Message-ID: <61642.82.43.155.147.1175588281.squirrel@webmail.officenetworksystems.co.uk> ------=_20070403091801_40561 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi I just moved to Debian and following the instructions in the wiki http://www.boxbackup.hostworks.ca/index.php/Compiling_and_Installing_on_Debian_GNU/Linux I get compile problems in bbackupquery BackupQueries.cpp:818: error: ?LLONG_MIN? was not declared in this scope BackupQueries.cpp:818: error: ?LLONG_MAX? was not declared in this scope in the config.log I get this configure:12051: result: no configure:12058: checking for max value of long long configure:12112: g++ -o conftest -g -O2 conftest.cc -lcrypto -lssl -ldb -lz -ledit >&5 configure:12115: $? = 0 configure:12117: ./conftest Using system header for LLONG_MIN and LLONG_MAX configure:12120: $? = 2 configure: program exited with status 2 configure: failed program was: | /* confdefs.h. */ Checking limits.h LLONG_MIN and MAX are declared conditional on ISOC99 I have attached the config.log (zipped) Thanks Dave Bamford ------=_20070403091801_40561 Content-Type: application/zip; name="config.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="config.zip" UEsDBBQAAAAIAGqHgzaqrDWWXDIAACEUAgAKABUAY29uZmlnLmxvZ1VUCQAD13kSRkh8EkZVeAQA AAAAAOxd/3faSJL/efgrepK92E4C6HurnU3usE0SbhPbzybZ5N69xwghg9YgcZLwl9zs/37VQoBa VAMiN5N5O/KLHeiublVXVXd/qlRqdUd+TG78sUfcMEgcP4iJEzySiRfHztCLyTQKBzPXG5D+I1BM pkAZxeR+BP/XolkQ+MGQt7zxh7PIe0mSkDj+gAy8/mw45HX+zaqaTJxb6NIhEz9O4GOjVusk5N6J iRt5TjK/yEn4QE4c93Y2zTVUGgp7ya/qjjh9begFXrRo8e78E2nNkpCTE61hsgYhneAudJ3EDwPO 9cQJBmTsB17auEbIX0ijueq9Vnv6lNQXP+TpU/79cuwkN2E0aWTfhfraKIyTwJl45DXpp8zqtVn6 vT6Bogfb6lnGoiSCEq1hNVS7btSdyWBVE0PNBz+YPSwK7qDgqUquP16Sj8D6RycimkVU9Vi3jk2d nLavu0RTFFqrNWdx1Oz7QTNrOYWWs+A2CO+DWr78C+E/q7p5pROBIIWfJdPLjlOa+u2yftk7JwDh 3XkPzaGXxI+xH9yEOQIum7SoeAWBv4njjrhGUIIFD2E89u68Md7DLPDvwBg9rIfaZav7/pikHY3B EsbNGJqslxYKi0S5r/mqdarmF1WtiXa0tKTTEGws8eIkXrOlzJqWpnisGop6TNyR597y2dOf+eMB AREn3oQkj1NPIFXZMYm8eDZOjjPt1bPx18fcqurDYCY00Giub64madeGWrJrg+W6TpwILEPauaWX 69zU853DpCTDFy8EAtM8hvIZzPKlQooklrm6aLHOVgv9n754sVztCDcyWEjEFkbaC2gyqyV/bQ68 u2YwG4/Jm2dmjVcevjs9PSJGQ21ofNZaqqqa5HAaeZE39pzYOyKHZ17fd4KURq1r6lHtNJw+Rv5w lJBDaMtbkbeR55Hr8Ca5d8CQ3vJhpivbS1jl3Eaty1dwvohzsjgje0Vi+JaMeMkscr10VC70na3X A5/3AAZJuiNgh7c/v6hBy8gJksdXJAgTAjMvSNt9bF+dvm+dd1snnQ+d7lcCRW873fP29TV5e3FF WuSyddXtnH760Loil5+uLi+u242aKC4wvL/8O8xPRSxmmRTviuL7FC/MP6n7AYmnnhvDUFO7WhrN ylhOF50OyL2fjI5Jo9GMIze3xsMl6nUvcPpjrz52guGM726v3ZfuixcvYYwJjPtl2P+Hy//UeWEC 4uSE0Aw0duM/vOamteokHjn8cvU6v2B9bur1b2O/D0Xw13vw3IEfvZ6vNWkpJwxnfDzueDbwBnUY S+I9JKs+kxHsg4P49TSM/YdVcTCOUy7CYeRM6vHshnNTB5tZkfR67oPTgx3xwc/156aLnPcaRJQb vd+Pk4H78FBPd+lVxWR6kxvfYj68zox1XejdlFsyCQfe+JikPNeGrruYLyUNP28XTEPNhS0m3Wdk th2Tg/rnAxJO001/MoPFbeTceQRMZjbxgkTsaWGPar7Y0pRN68DAu3Fg+SCgw+ksmYMmvsmKXehz HuGHF/NlvwEySbkU6CxsiBbVVquU04AribX59ft+5MH8jtJJLvB5H0a3sdDOBqYazfX+bJQJquTW 50dP6IqqCsLCPRczIMgojOOMD6gW2+UGFoRilVmQ+tzCSXhD+CyaJdweC1zQzBLCpZS3SZxy5SKD NXL7glBhFjeFFVuwRnju3AJEvrj6Ur7cAjdFZqiJMsPtcsGMICRbgAUFuc/SxZLbAYfCeVsQutDM 3ZizdRVjztahfSrp+jdS++mnn8ivv86//8yR7LJDLxIvq9tobxxhzHvLtRXHbBhoS5NKzdPm0GJN THzQjut60wTWUcEs7eU+7kLNZqkw1H5svijtIRWG7ohMUbZJhfHZibRUDalUmGnlR1m/0DaOlFno 8sssa5+RMouhvfGpsmWk6CSB/UTdaTTZ92NASeRmFrjpvnDgBwm4oX5weHRwLJCpIFZgPYxgI+G7 6EHqmHIcNPDccbrXAxBJONiKAUh5IkvYfkJuHJiDA5Jt3Ly/49qvpPk8ZRd2k7gxAgD2vAmF8O8p lHCH6LJ1+rfWu3bvvPWxTZ6s3OEnCE23dTUn64cP9b6U7HP76rpzcU6ecD8aI7juXnXO3+WvRmSk J5/eXbUvL6666UX/42YMq+Jjww0bs9sn89F5AMPREYLs4S+XPjk8gk//C78pYDk0tKNX8IWQ+d/I S2ZRQBT+7Z+VJa9ZmdiLqu4xGmiGra5QTLeMRlPQnVRT+HKNopMlMoln0ylg7Ri0zldj7oEIPVC9 lDwopg9N4WhnD3mgYAiK2VZ5oHBVUzlUwldkTdUwGCXIyp9Mxx4HrnEKMuOp4xb6MFgZaakmaoOA hfeRlorOLCg2t0kLUCfakotfIi1tDSGCDxM50eMiZsmLAyfg0SJvKrQ0zHWguBDWJrioaSYGgqB4 HxAEzdBBaxYCgkQCdJLqupFH07A6R97/zHzYowQqgxbExt3Tz5l3BotwffxNoKcIqkaFBQ3JmsR0 GwMmUEz3kZiOwi0o1jdLTGfoNDYUJjUvQ2NCWOyeR7GjWbD0rMBxhT0cpl8cCjwalpIJrC3IR6TB +WG2vOkSkpjHmr1EJY7b46p+8OMEVoXG6Jich7CiuqO5JwrqHYAFuEkYPeavZCpGhU3m2OSpz0dG ej13Op7F/DcFIIkHWOPJ6RNyF/oDEieD4+M5KgG8cgRGEIFFHB69ytysZT0HJ08B6/g3OU7etz63 e+0vp+3LLgzquljDBXIN3LbXaj50Tv4LNLQBQD3N4kbkr0VLeCPo29CFQCdYmFBt0a02a1J0JluK +TvZrKWqlc3+iWzWMosbvDeMxJ3cEuL3UFmwa4sWY3et8+sOOSUjzxkAnCrGajSLmWXgE1VQPECV vfAAVVA8QNVtQREgQRGBrehl9u7C4GwF3aRszuX8Rmlxm7VVVBy2JkdxtlnUUPwYN/nNITAYgdAq 4+RpNkWhqE33cfKgGepU2PY2Jw9IUIBts7IiiRMnqSSylEgyANRayWMljwg+VvJYyGPiTQA9VPIQ 7aNaUpcCAURUbTLFJdUPqi1mKY9ZAKh08CeVh67z8KUIvgd+kmbLZWG2PLWhq2WAZn3MOytICzrB Itm6YewTyYZmGCSGYiSSLRCYWIhJN2guuDbnX6hm+VuMC1E1eSoE/9AYgc/l9P2xnwhyM5Uy7oZu ovgaivdxN6AZ5m7oprbN3QASVLamLr3bCHX2FgFNoaUXuJ7QytgQEFvQmDgzVM6MpRRTxxCGhAaq fKZYwsgWUfvlbFne3RjBciJGNHTLsr9/2lgUHb9F7X2MwrJRE7NsY/O0sdBkLt1i0girnrq7ZbRA VWkKiqGaxfVqILoHhmqXCmSjwjZUNAANxZrEJ4YqbO01NCV3H8hoGA1NrNaKeSbIzY0TL7r1xt4j OTvBurB3vcuRH2864GYymTZd95p+u535jVC8Wf4Lv1V7cFxrjsKJ1xw4d17zzItvk3DaPAvvg3Ho DOJmP3yYB8rqSkNVmrmrHfPpMgvmEaMBiODGi/i05+H1Xwb9XpYndgBDGY89NwHBjgfZvV+gV+f3 hrk3PIvF4S5WMyE6uAgL8lZZHmDWeJcoYnrfmVTBxB8fTFyUXnfPTnvv260zkI9QkZJff73udb9e tq977/HK626ri9Z1z+BSeA2XM1bzsf3x4uqrvA3KROe8K2ewewbVWM2n8w5UYjXts073Q+e83bsC maQfECIY2qJ6zx5WdcAIjHpzgFeI8XK/IuSh3XwhX5zfzJM/5ok3/IMTDd2X7siJyPPn8PlukQ1C yCG3wSNOcPdqZbFnJ4tp0vvY+s+Lq5R03uM/wujlxA/g79RJ3NE8gWS1uhw+m5M8m9M8S4myZBP/ hhxyTsgboh5lC8AUvOfk5vDJvw0a6b//Dp68LF5dKOiciwWXre7p+9wFio3J69dzrsmzZ6TYUVrJ GYXKjCFCip1zovkwMpJ8ugwh3jj2xAp1PlMX5bCHPB/0+QMjg3449YJD5SWZ/4MrvW9dv4fPywEc AuUREE7rb9xxGHvp9+3iUxuwRIHscqS8YTmGs6Xln3M7y28BhmrtsePVx4N+cZtPH6JY37QNvivj 27yBQmJA5lbebRj085UGvzc+Xz7zW/kqU7qwpVPNKCImBBUMAYCGcdJ/LGQhU41uQptFAYFQ5DiI ajY2XJpuwqVBJ9UYBjqheDPoBAIMdFLdotsTIahOje3CjEezZMAfHco1NBTj/02OhorhSSjeJ38U mqHyMDQkf1QkwG7t0tSp3SpHU0iU4EtHHI+b8CtxeqlprCe4bfB6gR4dlWnuExeguLsIxdsy3Khp oboyqTSji5qCjYmyQfxdunqCqE1kDi81UR+EWvLMMmoZxVupAi8CqanJu7GK68/19Yde+rxHmjgE nQnkrMyCA43hrxs9TsET2DZvqIJqMXUpy9sEReMqlKpb1h+KzzeqyzVBraKf2v582Tv1pyMv6gR+ 0vMe5rKcC0JoyrQS4swEuRTsFnkyLBZEbUXbR562gvm81F5pB5cnfv+Y2po0lENtq7iK89wRHscG F8XhadocxMbkrHMlNLPtUmtQmtCPcMb2sjeGpg1AMWJv4hrE0GxfyngoTyIhpu8QSuDLAQhOaGdt iulKzG03a2MWPgq614rO0AAYFG+O9ILJY+so2K6yfdezVbu4FG7OLLF1Q2rEtm4WjZjf8b93/KUZ +zG5vLjufGmoaS6wk/j9sSd0Ya9HkjcYtK2jkAuK9wklQzNs+bDTx5Y3GrRtoAu5baimVFqGIcTa HzyXP1cuQRu2YZYTjGGhgjGsvQRjoHnNtkG3Cwa1atuw5WZkCDaZEwwCNWwh11QCNWwT144pX5Bt 01yLrS8ZEegsaUi9oOEsy/a7FbwIQFLzmPtxWTLisvfdshBz9lFlIVaBwypwuE/gUKA4K0rvZC04 Zshq0+iYrPbyAoRCNKV4wYvL9jn3W/gvPmaoQYSMFQLx6dXXy+4FMq7OVXtNKdut8O+tDqrJ9pf2 aef87UVWt0NyrRB4vVmzc15MVsSrrMs3wkTMt5xPgvWG89zEtXb5wRYaZel7b9aKYTCLnuYBwKdk yUE21dJCWV/L668PIJuPiz5/FnTx7Jk4NwsXWeSTFS6S52KegCcR3mJeY42kIl9NebHZKndJKqh0 OVgXlB8k2wW1WDPEiy7SYQqsLqqX2+gbKVoJQjlYWe3x5bHKYl831O/Z16snYqp9vdrXq339j7+v 40ut4JOJS+26S7bsQuqRFRZr0SG7H1TednEDS2XyYx3tlIf9fOzIG3oPlVILSl1I5ceqNeNiP8XG /jBwZLfi/ryaXYrlx6p2wcauuk0PO1sN4jEeh0OZbi1lPVd9k24tFUtWt9PU1/K6tdAMCtvStiWr Awl288i2dHlE2BKOglyKBdOttTwfY4NuLfRUDNuichbEI9CyEH7KhkglPaWqoNvEn8iyxv+8ms2E 8mP1OmdiV61S4fybwEsA+CVNP5DpliJnGW3SLUWPXIHivXRL0cOMbLr1MCMbP7vOpvYG0dpMJhpM w5TtoGH8zrOdnnInYcO2ihrOsyJSyvWc3gnOL0HNqRM5E5mamaqUUjNTsWexbbbK7CmjZobm+0Cx tU3NTEMNhOnSNH+biXgkJxlMy8zUt2uZmTgXVMoFSw+2WrvFmnEiEGpqCSXHoXvrJZWWES0vRfPj 1bxgZX89b9qO/9Ra3rAl/746XtuWN2vYXoPi6LETdpr4U6qTedrGjn0wxSia2oOTJJHE1philbI1 oMdsjSl0H1tjCnoEEBRvszWGn8rH0nP0ZJJhRVtbSAYxNpiD240NiFAuVE3OhbqWX5bjRCCkUmtj 6TF221KwwM3nqT35dtrGhPbvScFimobhRijeBzdCM1Swmo7gRpEAg2tMV3JwTZaCxXS1KNVZzw8S uydcQjfKzRjdQGeMbu41Y3QTnTG6uXXG6OjCyHR5tjHT7bVn2LlAVEuUyCp/fTeJ4DnqbL8cdYbn qDM0R12UCJ6lDluSfHU1jOLsTSWiawWJWKWyQRkefoLifbJBmYE+cssM7JHbgkTQh25ZGr+SSMRc e+g2lYhliBIxda2UREz0PG9mGvvkD0MzdFlInwbfLBETPaCTmZY0qZ2l59qJEllfRdJ3A5SQh4We xw3F+xx7ySx8BloqcuylKA8LxZrM0qSeLLP04gGhM2QRsaxSD3EAPWqq1l4pvwx/5p1ZWMpvQSBo 0i+zmHz3pkoxgXqGrCFUKxVKZxQ9Tx+K9wmlQzN0/tGt5+kzip6TwagpjZgwahWfJpkhSwhdvsdl R4GgD8qzNOxTXiDpkwvrvdmrk/lkArHRU/iYrcpBoq0jh+n0w3C8SN/mtGE0iflD7qeMCW3t9eOt N4kpdToQ9lZH4JYSE3owLhRvO9+aMVzATH5GA9QV7aZ3AkISSPQdjSb7vus5/mx1+uhBetGdDvJH WnsPU89N0owgfwIIvg4FMNz0gc2+d8Nf6nVwdAB6vvWCrX38ApRZo2A28SLf5WONEyd7Mc2ircoP iyjP/kKmy920ymyqMpuqzKYqs+mHZDYJdZd/R1V81X7X/oLaS+fdeQsdPHDw4QI12m7nI6rg83YX 1NsF+5RNncvWVeujdF5dnP6tjc8sPiUlF906XWVS5HVfWt3uFTpZ+CSze11JDYB2WRXAV1kVADms Snol+YXk18lfpkplr1LZf3wqO/YaIn5AyWGKt8jzI6LMDyrJH1PCCWL/mxfC/ynd0TrNttcXsfQN QmjeJWNrT5k6QfagaT3zKbJXdwpxVcCL5RK7VP46RgTO8/K93u8G7dAXvCnK1uQuToO5pFAuTyaA SpZ3LhbH8PUfE57yP/Ci9LXTMen7Q65xR3hxq6JqpcJdvAE+PFXfJ+DF26Gv/oPybSEvoDFw1aWv 3fkNfClurgtnBMRZypPKtV15Qa+WXtDBXDcH4jho9cRl5b9U/kvlv1T+S+W//PH8l+LCcHJxsdD0 Lq5NwVsRKrL8tDc16ZsyOdQ9+dqFOXYFFk5+fk1OOu967fOzTuucw06+L8MmTTLQk1vwd4CmqqIr smeCoE7L338HPoIwqDtjf5ie02rBZRP+1ulB+pbdOPbidMsWu/jNzpjhfeMoUucpMeghfrwOfZmn okufY4U6IU+lIAZd20UMhlbmoKxyYjDw9zZDuS4Vg6GjrwBXDFOVisEQ0mgLYrCMncSwfPnSbyAG 9IQaVTF5aF0iBhN/qbJi5k9bKojB1Nbur/uDXsIhMZ5hBk1M6b1HqLSKSS6TcOD1CoyyUjkuvAGu YEvZJ8uFt8MllT6psMV9sdCkLCjXpJkuUKkXj1ELb24KUrHKpdJDA/zFwFC+15uBoZ1kZNvfDaxY +Lvgwa2WPh0ElaxofFNufAINLevqUomrS/d0danE1aU7uLpU4upS+aGFULmewud/K04hWu5AOGiA ngjHy/dJAlIVGz0TjpdvSwPiNOh74xVbfiwcVCI3raOZOz9bvREnvZuxMyw0MXe8V10yoiDc38xx cUBGaWiBv86p70XpK48HnGLO20GBOVaFCaowQRUmqMIEVZigChP8q4UJqjugwgCqO6C/yx1Qbgy+ m0eG/O3dznAYLW5/Zl+XgJG3LHP7E4DbrrnVPwJVsqVnW6HKClVWqLJClRWqrFBlhSorVFmhyt8Q VWZJdd8PLpkmS66DOmNLBHTCDxWIp54rNrP+KFHQJX8FzGpVkdAKs1aYtcKsFWatMGuFWSvMWmHW 3zcSugRmpQErf/rhD40u+TMJFbqs0GWFLit0WaHLCl1W6LJClxW6/BER0e8Bmbo0Kqqm779Fo6Kh e+sMBlHPDxqAXHpjLxAb0t8GuVJ1HbiuWJHh1zmDBehqV9C1gq4VdK2gawVdK+j6rwFd051e+jhp vir/WovsidLd0Mhqs5WGvOa7bXkgov4fe9f+3baNrH/3X8F1eq/s1rHFh0gxrbvHseXGW8XOiZ0m Peeew6UkyOKGIlWR8qO7/d/vDEiKBAVYj9jJtpmcNrGBAQgMHvy+ITCzqtfML4YZdJO8TxBmIMxA mIEwA2EGwgyfjBnqhoyNoUPLUdowdLstcQYGywkmGHoBKzxViYXcpznXZVd8D2dNWMN7LzaLTnMR ACEAQgCEAAgBkL8GAKkEs4/DcJmDqwg3/ezNyTFBf+RPtW8n8EbcyX7czXOFHX0lEGEYphJEGJYu ARGXF96bTuft8dvOiRJJGPZ6nmd0w5F6noH0jTzPQDmp5xndaC/1PAMyUv8suuGqPc/ophCTr9BV HhzQhzlQiRU49u+1XpyOtB4rvpSJ6jNXDQIxLyCNF4Tpm8QOgXIt+XCYrWXRQ1BG6i5HN21l/BDI dFyJ+nIsnY5xohUOpDIdyuIQ67rVXM+3DxSQN9bSN/LtA+XkA2HpS3376JYhdYCjW2bFt4+s01Y9 flOut0EwZVG6P/CQ24hF7LWiOUEBaeBDTN8knhOUk0YhwvRlEZ1QRuq7S29ZyjhokNmy1RNMUBTO tRs/DMQl2XKNp3LNBnXLJw2PuSV3zaZzR2WSMraudhGt22bdPRZ+PQ/8UDvWMPQiEKqpFk+QzgE7 Ywz2pSxYoz+9ZtoQsmv1OWuF7sEC8m3Zbm8SvAfLyaeC3V4WvgdkXPke55hqWu0sLDXv9KwLAPf0 9BIw1cuzq0ucOzO2ivYcZ60whFBAsWicMlDeWtpzpNHzIN1dFooQZeQbQruldA2ot+369PO6R2+B 9aIO11Bc213z9ehKg6Jj+mavR1eXTx0e32mJ4lxd/sZx22og5rqyzavbvQC2+/rogwqGGTwA8FN8 XDJLg868FevYdKBlDtl0yKZDNh2y6ZBNh2w6fyabjjg9O8ddL/+ssrBEeGbVXFItzgfl/dnVq/kQ STeyd8dXxRo44YO1KPXLUffsRCK0gvEpDMZBmqxkfpq/51UWqLnA2kYoo6l2qw15ddA49u9yrBgP tTCGVPxLKKTrT8bWoG4pmIR0ka29y17M90nKxtqI+QOAbNj8XE9n59wsVKpVqMsokL5RhUcFLsIX PcCk2yAd8c+Os0SUIxhFMIpgFMEoglEEowhGPRWM4qBGEw8SlZfnsj9Q+P3oHg00mSEk1gb+ONIA Mg3+ntWSVzGLsrfXT+fvjj1vMf3dJey6MD9dt8zLWy/PlGI8seDJ0dWRtj3HQmE4DiIAV9tzwbkB CF+euxwOFn/QZKd9O/y+kjSHYlqwp/HK+D+A1g4z0FeRDYY7O0NIH8YTFu1gQ/a2b7d3d7XDQ+38 Xbe7W5HVON7Z0XdrdeDVs6wng505qNrFO3m11KMP1eqGkyn0a7gDY8Wm0z1te02g9n/R9q7Qbewp dGUuXsvk/RfA8bwD+R08ZcuO/bA/C/0U27dia2DCXeFMuw3CEMPNfNTiCP5jjYRb+EM2ZjCoWEV6 G4uJlemocQXsBGif+14LtB+zjuCPP/wAaXta8N134hgVPQ1kuskyv9P0bvf7vJW3U38iPlLkDPPu XPpRkN5nFEAsgIfpsidAzdoP+dP+85/8h+cLiVkbit6Uic/LRHGWl2MyhOGYRR+j+DbS8n/rqs/n qSEk/lGf99rOvEptb/t/wnCg4V/b4pLZhZY3JYvArC8CntqsPJI/UOASlvA9I4WhhU1FFGm16mFT puw50AcMVMR/86/Hfr6sErGos+IXV0kAzCSd+vda41kDDcU5WVHJNrI2NLRBzDIrM95Z0Hyt/m0T WtQm0zJxIuJExImIExEnIk70RThRyTKuOpdQtnOKW9SzHElM4LUGgL4iXZGqAxijqfwybhhCGDw8 H5bF+dwfwdvL7wUhQEexgLXioYvSbZj+wrBKzFJ5xAvtPNaSWX/EzyjgkTQ8SNRP42ntma0mIRJC JIRICJEQIiFEQojky3zsJs9m5NnsiT2biVeKC5z4o4gGnQfgLB6nl8PZCRRhUV+0dRnt4hx/R4Sx ohnN+WQE65LfMEKwhGAJwRKCJQRLCPZLIVglqDB1NagwrYVbX5V6RNFWa0VTm5+MD3r3KYunAzb9 dGvboqmsWUvf6IoTlJNecTIMe+kVJ5CRXnESAVztil0NwdW1tAGIW4RgTfXI11uzOPS1FqlHv16V Zda/ESMEmnlp7PWYbYmy9nrXcKGA9FKUYTkbXcOFcvIzupaz9BquYbWl13ANy31A0S3DqGln+2DA bg5mUz8axONtUbh6w7Bek63rtZquWTqOUhalohyq7ImOONt4M1GiArtU31rDYStUapcXF8vSNQn5 +rVd9WVyiQqRkA8T0t9q+nMEXwbFC2PiA8er7RiO/kA1bbu+Y2TTuFZHu72erwijLb+4C+kb+Yow 2q70UrLhNpf6ijAUN0sNV1f7ipAoBvULykn93qbKKbh+26xz/aLeVbl+qV7i+sT1iesT1yeuT1yf uP5jcn1B6Ojytffy16vOxVtYNLKevLx8f/TGtsQ9JE8TSVh9fRydn1y8hs7+cnYsPljMqXGVWi0/ da5en19BD2RaOLo6Vaxz5arIKstzlp0kUt6tyN/N9cdtSS5llOB1Xrhy1HzBwlIAph/ViK5mGlEA unhGYNdwjQXrUxnjBwZ86IG+4whPc4vlWk8TTAcJUY6O0f0uu/ZThi7ysTGFT97MPT5MCn45AvK5 Xyi8NNH3Izx73mPFHROxzTZ9JiPoTNCZoDNBZ4LOBJ0JOj8ldF4o9vri3Rq4+jHg86JkDnrXCpUg YK96ZKUKPlw7RIL5VLHEnxBEmhRenEAkgUgCkQQiCUQSiCQQSSBycxBZC7X1aVhSHTLc5A4MVUbO G7WV02yiS+/PClBvHgGhzr2uE0IlhEoIlRAqIVRCqIRQCaESQn0Yod48kZ0TMNmfD0bqJsFIgpEE IwlGEowkGEkwkmAkwciNYeRjWjp121BaOnVn4W5Y1q78bhf84w2CqVjGba916NU0mtL7c5C+0f05 09Cl9+cgXXJ/Tjz0CjLSG3Sm4agvy5r8Sq9CS3i2GLXEx34iFONBhNe67dV8gcdrN7jttS4RsGVE IHvYp/IA0yD3iMQDiAcQDyAeQDyAeADxgC/GA2Qaz0u/PufKX5EuKC+tyS+arQ7/RchVNyKXuHJ9 1G+u6rTlrwU+bYoWQuCTwCeBTwKfBD4JfBL4JPC5JvismZ4/CYO6ltLybBl1m+o1gNIbNk0QPZqI MkMAhqLl17Ja65merZbcVGyhb8QNTM9WS+rZ0LRsfanp2bLlZnDLUftbMFsts6Km2xFLR2yq9cM4 YQDCc90nHMyJ5dpPFjId6pY6joB0MWS6kOdKPYGadlM9RewFx3WcNnh+6oWwskRZs/Xo/V2T1+h6 SWwaQksbyDh4lMMB64f+FKgIrMoshGw/ntR6YulEYYjCEIUhCkMUhigMURiiMP/lFEasHctfPkxt KIgTBXH6bEGcZDxYQOfaTnNPg/+2t/N/dldjt7atdCFo2o5boS55HfwbBlDrJLiO/FAbwXIPge8K BR19xaP/ZQFbSqwco7kRw3UMaWACSLeXMlzHkHojNB2rWWpqgao6QlSDguKGuGCBL03ZEP6P+izR fC25H8OIfdSSCesHwwD40G2QjjBs/BToEUf7oZ+MxOpxKJ6ICTttqTtHSLeUTNiR+3A323gaTmUG aBuuREdcRX6/zyYpaCfS2HiS3mvZihWLt6wn00FbHpMD0l2lDtq21Cl5QW6RrRVji32cJcSFiQsT FyYuTFyYuDBxYeLCfzouPO9s5wo2BK58DoTLnC5/651edLsX72Gpdo8uX3VOoBmvYUf/mfg08en/ Yj5ducykJb3ZMKPOGRDliTtIrv8Xs3a1v2u69kJrrsiy246aZbtNSXC1CQO+WKOYbutxo4MdpOPJ Qb9/nKZXr97tx+IXwn+ibhovtg5G8ZgdDPwbdnDCko9pPDk4iW+jMPYHyQFA/IxWPG/u682DSgNe 6BiFaxZl28JAmxNgDdr0z7KDjYVW7OwP/NT/rnnX3F2tgn4chqyfAhcLB/kQgLyeDVxGvEQ1zr9g Ex0jOkZ0jOgY0TGiY0THiI4RHauAHMg4ySopwRZiLz8C8BzF/Vk8S7Qbfxr4UbqHJ8H6fgJoOwzG QYoAvzglllTK73OYrJ3iIbg7Hy/F7Gmv3jx/90HT9UBVNg3GLB4O/Ps5URwstGveIq+CnTlQg25c 3icpG2sj5g/YFLuQl/e8JJ31gAT0p3HCr+WM4gkbzsLwXhuyW4SCacz5yl7Wbu12FPRHeHmH6ysM gC1w835/5FdROwdHPRbGt3mHtTccvlZ7CM34wU8SNkVegwTI8/irxdOCpLgUtKcBwOqzvI5KYUBb SZpo7IZFGmD14ZQB6oYOIBzDy0YBfpGrotUC52WPEPnRvFqRkhXZ80ZW0R3+zLG5JtH3xQ2bToMB 3nS6x/OwBrItgJR+WKqUzyQOL/GLD37ILM0AD2LSnKvNWwLPe88AibJsEHqs7+Mv/HxjcD3CU44p jFk6YvUPmD5vW6bc3iwIU5jDOAlAFKY4fouaXs/GDCoqW30bz0JExEEYav5kEs7npGQGZI27ggf/ dP5OO9aA60/96X0+uEl2chLpXsG5knx+AdIOcG3gs5N88FFd4a1/n3Ceks26zvkFbCjQgkugaJVa YOFofj+d+TiR0dvGIK8kATl4Ksfs/jTlH+GwIph0eceBm07HME5YCiciDI4fBn5SGZxicmo72fqp rLhd/Dpbz/aqAlxT8UemjVlltnHl7XwLrHpnF2hZKS8yCtnE+KM2K2W8Ph/3ofa3et3LibvbVjtY XiTuIXTuNnpS0i5nss1a+mYuSVxHfs7cdZaE9AYJ+edTQX31z8GL+ktgdKYxTOM0ZJ/D9GH/8o/O z68e3fSBhxZUlotqFxsL7VjJ+CFWQeYPMn+Q+YPMH2T+IPMHmT/I/EHmj3XMH+JmePzq4v35qmaR KgzbzDBSreFxTSNC20rjiICvP7N5RGjSV2Qgker8qzWR1GfB12IkqfZbYSYRRFYylFRLPL6ppF77 YxtL0BTzxCcc/jrGEotHjRX09/G3GZsxUch+3BPyuXni8m34zngCM4mutnFknWsstGAlA0lReE3T iNV0yOkrmUbINEKmETKNkGmETCNkGiHTyKJppK6hN2cnq5pMMmC2mbEkK/u4ZpK8PaWBJMfUn9k0 kjfjKzKK1PT81ZpDypH/WgwhWY8VJpA8cyXjRyb7+GaPst6lBg+r6bZUBg9LN4wKYeeXje6TPmh5 fwSTz+8FYZDeiyXMFSOtzAtYUnd0kG5tYtKAclLDhKW3msu8JoCM1OOCpdum2qih245SRxMohIxe LICmE66ijqgbUaotb4vRfKAthtmun0aptkeUtdRxdixdN2sVFTeQamJqTwmWYdfryBsiSPEgNU9j LoO6pR45LNPcyCMHlJOPiWlKPHLUJKT+OCwTvWKurkDYZD6DCnN7VfKvwbvbXx/fYmapjV7z/jUW GrGS0axSfl27WTlXyG5GdjOym5HdjOxmZDcjuxnZzchuttxutrj+f708PupKZ6j63ZUXWtUSN0d7 mxnj5sUf1x5Xtqo0yZW4/TNb5crGfEWGuUVtf7W2OWH8t74S89y80woLXZm/tYqRbi7++HY6oerl pjrBWlAz1Vlog1j0S5mPPnSMfYSiv80C3L8Gs/H4XuPhtFktsodltR8/fkNZtzRoh2VhTAq5h0rI M8lDJRF4IvBE4InAE4EnAk8Engj8n5nA59g/+0MOM8lh5mdzmCmbdsN+lIZlLMeFWVn9fl4X4iib N8Kbr5fzDqzEk87puSCrVeF3PBx6acn9dn6b+QNIiGbjHpvuafv7+7lHzvmTZB0YRvOn58+uPbG4 uzW3hQiZ+bItCGLVZiJ58JacywrCaOAYjoCn9afMT3e2OedEOofRPOxms9YpFEcueljEsJxnDHeG ox8Pm7tC6r9rHciKFirE5c6ftwdN4MFDLjudn73LztWe5rq1J2tZ1EZ4Si3jD+G3WYQRLqr9qInn RB1a8rfD5/r3hT6WsfhWNbxEjcW3TKPujgXm8Z2fpiJJb7WfLJSG1XKlQSUh3d3o1ITdlIbmgPTW klMTdlNuLrCNpvrUhESFpMNP1uE1Iw1+4iwkFX6qChPS4KdOQlLheiq08ajgglk9s1ScX2QMLPs8 loUTFgu3VgySvWZ8Y7ddhjcWm7JOfGPLtim+MVnMyWJOFnOymJPFnCzmZDEni/mXtJjXtuPLK768 JVkP5EEDVaXUWZfqQkLWKmGv7pMDTjAya6nCblhYL0Xwyu1m/PDNtxMApTvZj7s1KQFcrWRws9vq G25OsxrONRhqt0wb+TdMA/B8zbQhQGEtmU0m8TSFvvu9sAbxHfPpqJNjyamOYylj2kKe/Pqbg3Fe VSTHcZo1njgM4/5HQaZtOE/W0bbiXlXbdDbiiG3FncK2ZS7hiG1LfmOs3XrgolvbloVNvgCc0wVI oGSHbTzY9ATsUG82S3pYtGItYth2XSKGRAyJGBIxJGJIxJCIIRFDIoZEDNXEcHFh1b6QLKy+Uw6N VySVlTM6SwhlAXdVVLLIX59EuoapJJGupUsIwCmqr6vG/65tr+cqxXXkfNB17I1okuvInVK4bWOp qxS3Lf+s57q2kii1DOR5/HQQ6iljsMH1fu6NYevZM+259I/27Blmvp1FUXadrFJsP89Ul9y64vea kMkjB0LwDnNloPXutQo/ECrlbGEvv/0EhbauWcSmfpqVwttTR7M0xiKasd9yYcaeRTdx3+fMrB+P x3h7KcTJjoW3NO344vz07Cfv9KzbuUS2fKiViQVUEhJx91mQPL54/Rp27css8Zu6BrWtLXh8RpvM rS0h74Xdciq6D6Lh1M9iRcPQHIAe3oR+Csx/vD8Z10o6drNSMgx6B9jDOMJSx5nkSDp4+cgc+7A0 siuZvZApB4wPld/3+jce3n0bHN61bc+2ns+ij1F8Gz0Hdc7unl9Hs6qQxy+DLRPte73gGle7Hx3C 0i0SoZtJeoiTNE+5u/OKq4oelK5lsbs+m/ALbbUMvJuWTPw+q2aw6MY7fvPmtHsEXCdh6aEs/cYP Z0zI+fABMhfks1SZtLz+Il1WQiK8KNc9kVZcJC/IVwajXqaatVBuFCepvFglZ6FUirY5RTkhTyx5 x2DtF7/hfuB5HqAeL0c9XmX00MxS3hMsJw1P56cHB8HUQyhRy+OGs3pF0KBxBLtOKsnII7nVqsn8 ikvEuW21np65+6pVkcVxq4uGqjrmZ+QWMtQ5iaou3DlAtXPnPDBKoZ+M2AA0OsZTlfUSVT/ttX6o HsKfwcaT9N7LDibDTLuulwWZYbJQMh/VMhktvh6+pL38pS3Ny5hE+YgyBzDO+U9A5D/IMgvMIcur 8A/pI0UYVamB3xv3/GTs9e5TFk/xt1G1ikwAZilMu+IfiQDaY/FF5cH+PuA/yITuWB/eGLEsrzjd LcvLjqFLc/hykOVEDF4zsICDSJYbT1iUJKGH/0uycQ6xBNtS19TkdiArMGXX7E6WkQTXkS99RpIO enGsyupLUwN5X7O7APIcPqOVOVJ1w7z2srecRAGYCVpP/Z4qM54pWgmZ/KqwKjOBLY8pi/J1qsrL VqIqG30sKPNUkw4zb/1A+Uy+mSgyw1iqc2yHPFUmnV09EHPgZbYMpJQvvGWSOGeyDyxe55c33nEw AbpxFkGX2V3loSjGPwN4MAC4tMthxyxcQmgexIVfK/W79zv88wubJoB2KnmwnnvZFATcON9b+FAo pfKVPs52oYfEcGqiGJ+Ik7KxoiBONn8wwI0HFmnkhSxSiuLMA6UOQ/86WSY0xuFMJqz/kOAw8YbY xjhCzPeQ5I1KNO79C1FI8St+TMnx3WEjcwrZqGbhjykKHEJmNQOB53VFnTyRXU/ZBOqBvysVJcyf 9keIHnCO9e55gxpRHLHCI8CgJhr5UZyEDOt6SAx3YxzUB4Vgi0VQ/bBQMpqlA4QrCqlMsen4EEcJ 6EaeDMuZ47h4OASYACg/rYwz5vKvuFxGlsHLHh+XORl4XLb+qhBzqSysDc97CS+MylMwbRwPmFcF hDyVXw2qJwISXEzMXlCH3JolJP8uqXaGr2ndVmSYhiLDthQZbUm6rJEz1WNVT1U9tPLMm3C+ueXY 5TD7rCzJ8YD5pwBBUPdl7hzq4LyE1T+EDSfbAqWGhJyvXszSySxdzmMzIltQvMOG1tjC5YuLm/8k rPSCqR02MgtQmcK/kx1fQcZ77s/ypHOKUifcelZYDhpbneNXF97xYSP/6RxEovznK56KXzcrO0Ln Q6fzged0T45OTry3J7+eH70+gxqeTwe4MwR9zCrb3j17efHyH/gzf5d8824/5onYmIc/84PY1WLp EIpDEm8E/LjwGfawUf8MWwrhp9DDRmm0KXOyj4rVPG7CKQXyL8u89vzLcpmZf007bBRl0O7fQev1 1cXbw8aLxpZgLD9sVI3lja3LV51uFxJ7QXSQjLI9K9uzs0GHdL5LfvNvBNKwU8PGc/cHihd58OKe +GiUglpmyfQASKQf5gLcFtJQbTO5QL4ZNYpf+5P/L+0MdhqGYTB8z4vkwoF3QByROHCPENvEAakS HYjHxzZOmzj+vVRop9rp6jVZUuX7tH3Vc2poofRw2jdN4AuVpu+bE//IqhZb61zfXz/POTW1N9mc 5NkmqK95rsl61FUnEVOcxIbadD/YlKdRTl+WIXehMUbfee/+U1hyHAR5PqY23Bu8qNtL01yQE+/1 9WGK5LR8nNp6pVu3Uutt3DubY6JVlCsNq5V34srfOr3e/dArpxUMo1WGiXTSySvyjYcoP2jzBnuf Ol/p0+maF/Rgt97l7bjrRY2ZftTo0JNm3tSZtEUAw9wqs2qEzyN4HqLzmKfd4HSA0nn0f4QklRB4 uQ1bjqnNLPKSPdGcADMI6E94EIeb7JIL5v4uJoI00odwiHxh28SHfJCTQUEiUEt8A8MzeiDvw7QP wjlk5SAe65NUZCRFmkQopLhuR0iubyk3QAtBPBPJIo4P4/NuKCEgbQk5VdCOQqrVjIUwxc0BcEa2 TADqA/R/JNWYMmOu2mkhX8d6TSDXHElt1s2BzG7j+LoRsmOQG4PMGKDfIONgLl5QPQUVVFBFxS/J V2RmBY3abkrotI1HKdW2gCqpbei6q7aRMVenXBzksNS48e1uhF8en57lXj/wvKk3gP9sYb+QKz+p LeH4sP+wYVu7WM64T79QSwECFwMUAAAACABqh4M2qqw1llwyAAAhFAIACgANAAAAAAABAAAApIEA AAAAY29uZmlnLmxvZ1VUBQAD13kSRlV4AABQSwUGAAAAAAEAAQBFAAAAmTIAAAAA ------=_20070403091801_40561-- From boxbackup at fluffy.co.uk Tue Apr 3 15:03:34 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 3 Apr 2007 15:03:34 +0100 (BST) Subject: [Box Backup] Compile errors with Debian Etch AMD64 In-Reply-To: <61642.82.43.155.147.1175588281.squirrel@webmail.officenetworksystems.co.uk> References: <61642.82.43.155.147.1175588281.squirrel@webmail.officenetworksystems.co.uk> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---128931150-1287922559-1175608979=:4044 Content-Type: TEXT/PLAIN; CHARSET=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Dave, On Tue, 3 Apr 2007, David Bamford wrote: > I just moved to Debian and following the instructions in the wiki=20 > http://www.boxbackup.hostworks.ca/index.php/Compiling_and_Installing_on_D= ebian_GNU/Linux > > I get compile problems in bbackupquery BackupQueries.cpp:818: error:=20 > =91LLONG_MIN=92 was not declared in this scope BackupQueries.cpp:818: err= or:=20 > =91LLONG_MAX=92 was not declared in this scope What version of Box Backup? I think this is fixed in the trunk, in which=20 case it's a known issue :-) Cheers, Chris. --=20 _____ __ _ \ __/ / ,__(_)_ | 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 | ---128931150-1287922559-1175608979=:4044-- From boxbackup at fluffy.co.uk Tue Apr 3 15:23:36 2007 From: boxbackup at fluffy.co.uk (Stuart Hickinbottom) Date: Tue, 03 Apr 2007 15:23:36 +0100 Subject: [Box Backup] Compile errors with Debian Etch AMD64 In-Reply-To: References: <61642.82.43.155.147.1175588281.squirrel@webmail.officenetworksystems.co.uk> Message-ID: <46126368.8050307@hickinbottom.demon.co.uk> Indeed, I think that is: http://bbdev.fluffy.co.uk/trac/changeset/626 You can download the 'unified diff' at the foot of that page if you'd like to try applying that patch yourself, which I think you should be able to do since you're downloading and compiling it rather than using the pre-packaged version. Stuart Chris Wilson wrote: > Hi Dave, > > On Tue, 3 Apr 2007, David Bamford wrote: > >> I just moved to Debian and following the instructions in the wiki >> http://www.boxbackup.hostworks.ca/index.php/Compiling_and_Installing_on_Debian_GNU/Linux >> >> >> I get compile problems in bbackupquery BackupQueries.cpp:818: error: >> ???LLONG_MIN??? was not declared in this scope BackupQueries.cpp:818: >> error: ???LLONG_MAX??? was not declared in this scope > > What version of Box Backup? I think this is fixed in the trunk, in > which case it's a known issue :-) > > Cheers, Chris. From boxbackup at fluffy.co.uk Wed Apr 4 08:40:54 2007 From: boxbackup at fluffy.co.uk (Dave Bamford) Date: Wed, 04 Apr 2007 08:40:54 +0100 Subject: [Box Backup] Compile errors with Debian Etch AMD64 In-Reply-To: <46126368.8050307@hickinbottom.demon.co.uk> References: <61642.82.43.155.147.1175588281.squirrel@webmail.officenetworksystems.co.uk> <46126368.8050307@hickinbottom.demon.co.uk> Message-ID: <46135686.7050708@logical-progress.com> I used Torstens patch on the vanilla download from Bens link on fluffy. This worked fine although there are quite a number of warnings. I really only need the server but if you try to compile individual packages as per the instructions you get the debug version and not release. Thanks for your help. I had to move to Debian because I couldn't get Fedora to work with this motherboard. ACPI problems, even with the boot switch noapic fedora made a mess of the grub files. Its the Gigabyte M57SLi-s4 motherboard which is meant to support linuxbios but I was too nervous about removing the unsocketed chip. Thanks Dave Stuart Hickinbottom wrote: > Indeed, I think that is: > http://bbdev.fluffy.co.uk/trac/changeset/626 > > You can download the 'unified diff' at the foot of that page if you'd > like to try applying that patch yourself, which I think you should be > able to do since you're downloading and compiling it rather than using > the pre-packaged version. > > Stuart > > Chris Wilson wrote: > >> Hi Dave, >> >> On Tue, 3 Apr 2007, David Bamford wrote: >> >> >>> I just moved to Debian and following the instructions in the wiki >>> http://www.boxbackup.hostworks.ca/index.php/Compiling_and_Installing_on_Debian_GNU/Linux >>> >>> >>> I get compile problems in bbackupquery BackupQueries.cpp:818: error: >>> ???LLONG_MIN??? was not declared in this scope BackupQueries.cpp:818: >>> error: ???LLONG_MAX??? was not declared in this scope >>> >> What version of Box Backup? I think this is fixed in the trunk, in >> which case it's a known issue :-) >> >> Cheers, Chris. >> > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > From boxbackup at fluffy.co.uk Fri Apr 6 11:04:57 2007 From: boxbackup at fluffy.co.uk (Dave Bamford) Date: Fri, 06 Apr 2007 11:04:57 +0100 Subject: [Box Backup] Windows client on different drive Message-ID: <46161B49.90806@logical-progress.com> I just noticed this strange behavior when changing servers, I was monitoring the log file on the new server and editing the bbackupd.conf file on the client. After running bbstoreaccounts check xxx fix on the store I used bbackupquery on the client to check the store. On the client windows (2003 server) is installed on the F drive, but I put a copy of the bbackupd.conf file on the C drive. After editing the copy on the C drive bbackupquery queried the correct server, but starting the client did not go to this server. It was only after editing the conf file on the F drive that the client worked correctly. ie bbackupquery always looks at the C drive but bbackupd looks at the install drive. Just something to be aware of. Dave Bamford From boxbackup at fluffy.co.uk Fri Apr 6 14:42:26 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 6 Apr 2007 14:42:26 +0100 (BST) Subject: [Box Backup] Windows client on different drive In-Reply-To: <46161B49.90806@logical-progress.com> References: <46161B49.90806@logical-progress.com> Message-ID: Hi Dave, On Fri, 6 Apr 2007, Dave Bamford wrote: > I just noticed this strange behavior when changing servers, I was > monitoring the log file on the new server and editing the bbackupd.conf > file on the client... ie bbackupquery always looks at the C drive but > bbackupd looks at the install drive. Just something to be aware of. Thanks, noted, already on the Known Bugs page [http://bbdev.fluffy.co.uk/trac/wiki/KnownBugsWin32] and the bug tracker [http://bbdev.fluffy.co.uk/trac/ticket/12]. 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 Apr 6 17:59:25 2007 From: boxbackup at fluffy.co.uk (Dave Bamford) Date: Fri, 06 Apr 2007 17:59:25 +0100 Subject: [Box Backup] Windows client on different drive In-Reply-To: References: <46161B49.90806@logical-progress.com> Message-ID: <46167C6D.8050509@logical-progress.com> Chris Wilson wrote: > Hi Dave, > > On Fri, 6 Apr 2007, Dave Bamford wrote: > >> I just noticed this strange behavior when changing servers, I was >> monitoring the log file on the new server and editing the >> bbackupd.conf file on the client... ie bbackupquery always looks at >> the C drive but bbackupd looks at the install drive. Just something >> to be aware of. > > Thanks, noted, already on the Known Bugs page > [http://bbdev.fluffy.co.uk/trac/wiki/KnownBugsWin32] and the bug > tracker [http://bbdev.fluffy.co.uk/trac/ticket/12]. > > Cheers, Chris. Next time I'll look there first Happy Easter Dave From boxbackup at fluffy.co.uk Fri Apr 6 19:18:48 2007 From: boxbackup at fluffy.co.uk (Bernd Zimmermann) Date: Fri, 06 Apr 2007 20:18:48 +0200 Subject: [Box Backup] bbackupd - read errors on database files Message-ID: <46168F08.1070105@zedv.de> This is a multi-part message in MIME format. --------------060806010901070808070109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I am running box backup 0.10 (most recent download) on CentOS 4.4 After the first sync my SubVersion repository was backed up fine. The svn/db/strings file is large - about 2.6 GB. Then, after some changes to the SVN repository caused by commits, following syncs report this error: Apr 6 10:11:44 codd bbackupd[16595]: Backup object failed, error when reading //var/www/svn/db/strings Apr 6 10:11:44 codd bbackupd[16595]: Error code when uploading was (4/11), BackupStore BadBackupStoreFile The config I am using has been generated with the 'snapshot' option and was not modified except for the location specification. Does this mean box backup is not designed to manage backups of data stores for applications like SubVersion? Is a special configuration neccessary for this use case? Thanks Bernd --------------060806010901070808070109 Content-Type: text/x-vcard; charset=utf-8; name="bernd.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bernd.vcf" begin:vcard fn:Bernd Zimmermann n:Zimmermann;Bernd org:it-consulting adr:;;Alter Postweg 104 D;Seevetal - Horst;Lower Saxony;21220;Germany email;internet:bernd at zedv.de title:senior consultant tel;work:+49 (4105) 668 033 tel;fax:+49 (12120) 274 964 tel;cell:+49 (170) 4 735 471 x-mozilla-html:TRUE url:http://www.zedv.de version:2.1 end:vcard --------------060806010901070808070109-- From boxbackup at fluffy.co.uk Fri Apr 6 19:34:34 2007 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Fri, 06 Apr 2007 20:34:34 +0200 Subject: [Box Backup] Migrating - best practice? Message-ID: <461692BA.2060000@nethinks.com> After quite some time of running 0.09, I plan on finally upgrading to 0.10 ... what's the best way of migrating? Please note that there are some 20+ active servers doing backups on the server ... (mostly Linux, couple of Win boxes) Would compiling & running the server with a different port be an option, in order to be able to run the version in parallel, or should I just take everything offline, then do all the upgrades and the re-run with 0.10? What about the backup store? Should I start with clean directories, or stick with the old files? Tnx, -garry From boxbackup at fluffy.co.uk Sun Apr 8 08:32:52 2007 From: boxbackup at fluffy.co.uk (Per Reedtz Thomsen) Date: Sun, 08 Apr 2007 00:32:52 -0700 Subject: [Box Backup] Migrating - best practice? In-Reply-To: <461692BA.2060000@nethinks.com> References: <461692BA.2060000@nethinks.com> Message-ID: <46189AA4.6070307@reedtz.com> On 4/6/07 11:34 AM, Garry Glendown wrote: > After quite some time of running 0.09, I plan on finally upgrading to > 0.10 ... what's the best way of migrating? Please note that there > are some 20+ active servers doing backups on the server ... (mostly > Linux, couple of Win boxes) > > Would compiling & running the server with a different port be an > option, in order to be able to run the version in parallel, or should > I just take everything offline, then do all the upgrades and the > re-run with 0.10? What about the backup store? Should I start with > clean directories, or stick with the old files? I would suggest running 0.10 in parallel on a different port, because otherwise you're on an irreversible track, that you have to finish, before all your clients are being backed up again. Running in parallel you don't have the looming problem of backups not happening until you're done. I would use the old store. AFAIK, there are no format differences. I have moved accounts, including data from 0.09 to 0.10 and it picked up the existing data, and is able to retrieve and back it up. FYI, my situation is a little different from yours, in that I was also setting up a new server when I started migrating clients to 0.10. 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 Mon Apr 9 09:57:21 2007 From: boxbackup at fluffy.co.uk (Bernd Zimmermann) Date: Mon, 09 Apr 2007 10:57:21 +0200 Subject: [Box Backup] bbackupquery compare reports unexplainable errors Message-ID: <4619FFF1.40401@zedv.de> This is a multi-part message in MIME format. --------------080600030400050703030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, my box backup (bbackupd and bbsotored) is running on a CentOS 4.4 machine. I have set it up using the generated config file for 'snapshot'. bbackupctl sync is scheduled by crontab to run every 3 hours. During the past easter holiday there was no load on the machine and so I tried a "bbackupquery compare -a" to verify the backup. The result were some error messages like: Local file '//home/ablage/alex/Rechner_Drucker_IP.xls/Rechner_Drucker_IP.xls has different contents to store file '/codd/home/ablage/alex/Rechner_Drucker_IP.xls'. Local file '//var/lib/rpm/__db.001/__db.001' has different contents to store file '/codd/var/lib/rpm/__db.001'. Local file '//var/lib/rpm/__db.002/__db.002' has different contents to store file '/codd/var/lib/rpm/__db.002'. Local file '//var/lib/rpm/__db.003/__db.003' has different contents to store file '/codd/var/lib/rpm/__db.003'. I restored the .xls file to a temporary place and indeed a 'cmp' on it confirmed that its content is different to the original file. Size and timestamp are equal. The files were not changed between the setup of 'box backup' and the moment when I run the compare. What might be wrong here? Shall I touch these files? How can I force to get a valid backup of these files? Thanks, Bernd --------------080600030400050703030604 Content-Type: text/x-vcard; charset=utf-8; name="bernd.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bernd.vcf" begin:vcard fn:Bernd Zimmermann n:Zimmermann;Bernd org:it-consulting adr:;;Alter Postweg 104 D;Seevetal - Horst;Lower Saxony;21220;Germany email;internet:bernd at zedv.de title:senior consultant tel;work:+49 (4105) 668 033 tel;fax:+49 (12120) 274 964 tel;cell:+49 (170) 4 735 471 x-mozilla-html:TRUE url:http://www.zedv.de version:2.1 end:vcard --------------080600030400050703030604-- From boxbackup at fluffy.co.uk Mon Apr 9 12:35:24 2007 From: boxbackup at fluffy.co.uk (Garry Glendown) Date: Mon, 09 Apr 2007 13:35:24 +0200 Subject: [Box Backup] Problem compiling 0.10 Message-ID: <461A24FC.4070805@nethinks.com> In the course of moving from 0.09 to 0.10, which generally went pretty smooth, I came to an older box (SuSE 7.3) that I use BoxBackup with ... 0.09 worked fine (compiled on the box, and still does), but I can't get 0.10 to compile ... I'm a bit rusty at C++ programming, so maybe someone can help me out here: g++ -g -Wall -I../../lib/common -DBOX_VERSION="\"0.10\"" -g -Wall -c Daemon.cpp -o ../../debug/lib/server/Daemon.o Daemon.cpp: In method `int Daemon::Main(const char *, int, const char **)': Daemon.cpp:174: initialization of non-const reference type `class auto_ptr &' Daemon.cpp:174: from rvalue of type `auto_ptr' /usr/include/g++/memory:40: in passing argument 1 of `auto_ptr::operator =(auto_ptr &)' make: *** [../../debug/lib/server/Daemon.o] Error 1 Tnx! From boxbackup at fluffy.co.uk Mon Apr 9 15:23:11 2007 From: boxbackup at fluffy.co.uk (Stefan Tauner) Date: Mon, 09 Apr 2007 16:23:11 +0200 Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) Message-ID: hoi ive been playing with boxbackup since yesterday, so maybe i missed something in the very good structured and uptodate wiki (sorry for the sarcasm :) im running debian etch on an intel p3 as server/ca and win2k on my laptop. on the server i compiled bb 0.10 from source (after patching BackupQueries.cpp LLONG_MIN --> std::numeric_limits::min() and adding #undef min #undef max just like it is in trunk) (the packages for getting the additional features on etch are libedit-dev und libdb4.4-dev) then i installed chris' precompiled binaries rev 784 (updated them today to the current 1280) into my truecrypt container (mounted as removable device). backing up my documents folder from "D:\Documents\" on fat32 works without problems. i could also restore several files using bbackupquery get (-i). but... changing directory locally doesnt work at all. ive tried lots of commands with and without quoting, with escaping and even with "sh cd..." i couldnt even get into the parent dir or a subdir. in the best case it gives an error message only and does nothing. sometimes (most of the time with 784) it fell back into the windows directory: query > lcd d:\ Local current directory is now '\\?\d:\' query > sh ls CMD.EXE was started with '\\?\d:\' as the current directory path. UNC paths are not supported. Defaulting to Windows directory. whats the correct syntax to cd to another drive with the win32 rls? the compare command doesnt work either compare -aq fails instantly (=3D on the first file?) with: =46ailed to open 'D:\Documents\\Default.rdp': The filename, directory name, or volume label syntax is incorrect. ps/commentary: i want to migrate from rsyncing to my local server to using encrypted incremental backups somewhere remote. i have been looking for a long time (even before bb 0.10 was released) and there is nothing that servs my needs. bb could somewhere in the not too far future, but it needs a lot of ui love to get there. the installation process is very well done despite the "overhead" of the ca and signing the certs. the daemon/service principle is great, but the restore process should be a lot more user friendly (like it is with rdiff backup e.g. http://www.nongnu.org/rdiff-backup/examples.html#restore) combined with a gui for browsing the repository and the features so far, would be really what i would ever ask from a backup solution. the wiki is a mess. thats a _big_ problem for new people. you should at least mark the outdated stuff clearly, that would help a lot (e.g. ive been using rev 784 the whole day with good faith that its the current release because its listed on http://bbdev.fluffy.co.uk/trac/wiki/Installation) im quite sure those things would get fixed, if the wiki would be editable for everyone. great work so far nonetheless, thank you! :) ive started this mail with one single question... sorry for protracting it like this ;) --=20 mfG, Stefan Tauner "Only wimps use tape backup: _real_ men just upload their important stuff= on ftp, and let the rest of the world mirror it ;)" --- Linus Torvalds From boxbackup at fluffy.co.uk Mon Apr 9 17:40:34 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 9 Apr 2007 17:40:34 +0100 (BST) Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: References: Message-ID: Hi Stefan, > backing up my documents folder from "D:\Documents\" on fat32 works > without problems. > i could also restore several files using bbackupquery get (-i). > but... changing directory locally doesnt work at all. > ive tried lots of commands with and without quoting, with escaping and > even with "sh cd..." > i couldnt even get into the parent dir or a subdir. > in the best case it gives an error message only and does nothing. > sometimes (most of the time with 784) it fell back into the windows > directory: > query > lcd d:\ > Local current directory is now '\\?\d:\' > query > sh ls > CMD.EXE was started with '\\?\d:\' as the current directory path. UNC > paths > are not supported. Defaulting to Windows directory. > > whats the correct syntax to cd to another drive with the win32 rls? Thanks for reporting this, I will look into it. > the compare command doesnt work either > compare -aq fails instantly (= on the first file?) with: > Failed to open 'D:\Documents\\Default.rdp': The filename, directory > name, or volume label syntax is incorrect. Does your location directory end with a backslash in the configuration file? It shouldn't. Will check this as well. > i want to migrate from rsyncing to my local server to using encrypted > incremental backups somewhere remote. i have been looking for a long > time (even before bb 0.10 was released) and there is nothing that > servs my needs. bb could somewhere in the not too far future, but it > needs a lot of ui love to get there. Have you looked at Boxi? Also, we are not paid to do this, we are all volunteers, have you considered volunteering to help? > the wiki is a mess. thats a _big_ problem for new people. you should at > least mark the outdated stuff clearly, that would help a lot (e.g. ive > been using rev 784 the whole day with good faith that its the current > release because its listed on > http://bbdev.fluffy.co.uk/trac/wiki/Installation) im quite sure those > things would get fixed, if the wiki would be editable for everyone. I fixed the installation instructions (although actually 784 is the latest stable release, the two since are a bit more experimental). If you want to help us to improve the wiki, specific issues like this are much more useful than "the wiki is a mess". Cheersm 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 Apr 9 19:23:49 2007 From: boxbackup at fluffy.co.uk (James O'Gorman) Date: Mon, 9 Apr 2007 19:23:49 +0100 Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: References: Message-ID: <20070409182349.GB38629@netinertia.co.uk> On Mon, Apr 09, 2007 at 04:23:11PM +0200, Stefan Tauner wrote: > the wiki is a mess. thats a _big_ problem for new people. In what way? Do you have suggestions for improving it? You can also sign up for a wiki account and edit pages yourself (the whole point of a wiki, after all :-) ) The only thing I've just noticed on the ConfiguringAServer page ( http://bbdev.fluffy.co.uk/trac/wiki/ConfiguringAServer ) is that the example suggests creating the store in /tmp! Certainly on my systems (and indeed the server the wiki is hosted on) /tmp is emptied regularly... James From boxbackup at fluffy.co.uk Mon Apr 9 23:03:21 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 9 Apr 2007 23:03:21 +0100 (BST) Subject: [Box Backup] bbackupd - read errors on database files In-Reply-To: <46168F08.1070105@zedv.de> References: <46168F08.1070105@zedv.de> Message-ID: Hi Bernd, On Fri, 6 Apr 2007, Bernd Zimmermann wrote: > I am running box backup 0.10 (most recent download) on CentOS 4.4 > > After the first sync my SubVersion repository was backed up fine. > The svn/db/strings file is large - about 2.6 GB. > Then, after some changes to the SVN repository caused by commits, > following syncs report this error: > > Apr 6 10:11:44 codd bbackupd[16595]: Backup object failed, error when > reading //var/www/svn/db/strings > Apr 6 10:11:44 codd bbackupd[16595]: Error code when uploading was (4/11), > BackupStore BadBackupStoreFile > > The config I am using has been generated with the 'snapshot' option > and was not modified except for the location specification. > > Does this mean box backup is not designed to manage backups of data > stores for applications like SubVersion? Is a special configuration > neccessary for this use case? Is it possible that the database files changed while the backup was running, e.g. that something was committed to the SVN repository? That might cause the above error. If so, then subsequent backups should work, as long as the database is not being modified during the backup. In that case, it is probably better to make a hot copy of the subversion repository and back that up instead of the live repository. If not, then please let me know if you can reproduce the error. Please could you try downloading and compiling my merge branch (http://bbdev.fluffy.co.uk/svn/box/chris/merge) and enabling the LogAllFileAccess option (LogAllFileAccess = yes in bbackupd.conf) and see what it outputs about the file concerned? 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 Apr 9 23:05:17 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 9 Apr 2007 23:05:17 +0100 (BST) Subject: [Box Backup] Migrating - best practice? In-Reply-To: <461692BA.2060000@nethinks.com> References: <461692BA.2060000@nethinks.com> Message-ID: Hi Garry, On Fri, 6 Apr 2007, Garry Glendown wrote: > After quite some time of running 0.09, I plan on finally upgrading to 0.10 > ... what's the best way of migrating? Please note that there are some 20+ > active servers doing backups on the server ... (mostly Linux, couple of Win > boxes) > > Would compiling & running the server with a different port be an option, in > order to be able to run the version in parallel, or should I just take > everything offline, then do all the upgrades and the re-run with 0.10? What > about the backup store? Should I start with clean directories, or stick with > the old files? The recommended procedure is to run 0.09 and 0.10 servers in parallel. Unfortunately you cannot specify the listening port, but you can bind them to different IP addresses on the server. 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 Apr 9 23:23:23 2007 From: boxbackup at fluffy.co.uk (Martin Ebourne) Date: Mon, 09 Apr 2007 23:23:23 +0100 Subject: [Box Backup] Problem compiling 0.10 In-Reply-To: <461A24FC.4070805@nethinks.com> References: <461A24FC.4070805@nethinks.com> Message-ID: <1176157403.3435.0.camel@avenin.ebourne.me.uk> On Mon, 2007-04-09 at 13:35 +0200, Garry Glendown wrote: > In the course of moving from 0.09 to 0.10, which generally went pretty > smooth, I came to an older box (SuSE 7.3) that I use BoxBackup with ... > 0.09 worked fine (compiled on the box, and still does), but I can't get > 0.10 to compile ... I'm a bit rusty at C++ programming, so maybe someone > can help me out here: Probably an old version of g++ that isn't sufficiently standards conforming. Can't remember the minimum needed for box, but somewhere in the region of 3.2 or 3.3 I think. Cheers, Martin. From boxbackup at fluffy.co.uk Tue Apr 10 00:38:27 2007 From: boxbackup at fluffy.co.uk (Stefan Tauner) Date: Tue, 10 Apr 2007 01:38:27 +0200 Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: References: Message-ID: hi chris On Mon, 9 Apr 2007 17:40:34 +0100 (BST), you wrote: >Does your location directory end with a backslash in the configuration=20 >file? It shouldn't. Will check this as well. in both zip files the sample config file has a \ at the end of the path so i didnt dare to change this :) i removed the backslash and the quick compare works now. >Have you looked at Boxi? Also, we are not paid to do this, we are all=20 >volunteers, have you considered volunteering to help? i havent looked into it yet because the last release was 2005, but i just realized who made it, so i guess its not dead ;) >I fixed the installation instructions (although actually 784 is the = latest=20 >stable release, the two since are a bit more experimental). If you want = to=20 >help us to improve the wiki, specific issues like this are much more=20 >useful than "the wiki is a mess". > ic yes i thought about contributing, and i probably will, although my english skills arent as good as id like them to be :) i cant say exactly whats the problem, i just havent found it to be very helpful when i was looking for advice. i think the problem is, that it has too much noise (think about the stuff from the old wiki). for example http://bbdev.fluffy.co.uk/trac/wiki/GeneralInstall and http://bbdev.fluffy.co.uk/trac/wiki/CompilationOnDebian are almost equivalent but both lack some of the details of the other, so you have to read both to get all information. ill probably merge them and add my input in the next days (if thats ok?) id maybe interested in contributing code also, although c++ is new to me. there are so many small thinks, that could be improved even by my imo :) do you guys have an irc channel somewhere? --=20 mfG, Stefan Tauner From boxbackup at fluffy.co.uk Tue Apr 10 00:47:10 2007 From: boxbackup at fluffy.co.uk (Stefan Tauner) Date: Tue, 10 Apr 2007 01:47:10 +0200 Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: <20070409182349.GB38629@netinertia.co.uk> References: <20070409182349.GB38629@netinertia.co.uk> Message-ID: On Mon, 9 Apr 2007 19:23:49 +0100, you wrote: >On Mon, Apr 09, 2007 at 04:23:11PM +0200, Stefan Tauner wrote: >> the wiki is a mess. thats a _big_ problem for new people. > >In what way? Do you have suggestions for improving it? You can also sign >up for a wiki account and edit pages yourself (the whole point of a >wiki, after all :-) ) i have to admit i was too lazy... and i have a certain blockade when it comes to editing others stuff, especially when im new to something. >The only thing I've just noticed on the ConfiguringAServer page >( http://bbdev.fluffy.co.uk/trac/wiki/ConfiguringAServer ) is that the >example suggests creating the store in /tmp! Certainly on my systems >(and indeed the server the wiki is hosted on) /tmp is emptied >regularly... good example i already typed the command before realising ... wtf :) --=20 mfG, Stefan Tauner From boxbackup at fluffy.co.uk Tue Apr 10 02:42:51 2007 From: boxbackup at fluffy.co.uk (G.) Date: Mon, 9 Apr 2007 18:42:51 -0700 (PDT) Subject: [Box Backup] bbackupd - read errors on database files Message-ID: <20070410014251.75744.qmail@web36702.mail.mud.yahoo.com> > > Apr 6 10:11:44 codd bbackupd[16595]: Backup object failed, error when > > reading //var/www/svn/db/strings > > Does this mean box backup is not designed to manage backups of data > > stores for applications like SubVersion? Is a special configuration > > neccessary for this use case? > Is it possible that the database files changed while the backup was > running, e.g. that something was committed to the SVN repository? I have a similar problem under Windows with SVN repositories. I think repository database files get updated, but their timestamps do not change, so Box never picks them up (the reason I proposed MD5 signatures within file attributes a while ago). Gary ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 From boxbackup at fluffy.co.uk Tue Apr 10 09:25:59 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 10 Apr 2007 09:25:59 +0100 (BST) Subject: [Box Backup] bbackupd - read errors on database files In-Reply-To: <20070410014251.75744.qmail@web36702.mail.mud.yahoo.com> References: <20070410014251.75744.qmail@web36702.mail.mud.yahoo.com> Message-ID: Hi Gary, On Mon, 9 Apr 2007, G. wrote: >>> Apr 6 10:11:44 codd bbackupd[16595]: Backup object failed, error when >>> reading //var/www/svn/db/strings > >>> Does this mean box backup is not designed to manage backups of data >>> stores for applications like SubVersion? Is a special configuration >>> neccessary for this use case? > >> Is it possible that the database files changed while the backup was >> running, e.g. that something was committed to the SVN repository? > > I have a similar problem under Windows with SVN repositories. Do you really get this error? "Backup object failed, error when reading ..."? > I think repository database files get updated, but their timestamps do > not change, so Box never picks them up (the reason I proposed MD5 > signatures within file attributes a while ago). Nice idea in theory, but realise that it means that you have to MD5 every file that doesn't appear to have changed (i.e. almost all of them), to be really sure that it hasn't. That's an awful lot of overhead. I think the consensus is that inode change notification is the most efficient way to detect changed files. Now we just have to implement 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 Tue Apr 10 11:33:47 2007 From: boxbackup at fluffy.co.uk (G.) Date: Tue, 10 Apr 2007 03:33:47 -0700 (PDT) Subject: [Box Backup] bbackupd - read errors on database files Message-ID: <232035.70740.qm@web36708.mail.mud.yahoo.com> Chris, >> I have a similar problem under Windows with SVN repositories. >Do you really get this error? "Backup object failed, error when reading >..."? No, sorry to be unclear, I meant that a backup completes successfully, but a subsequent compare run will flag file content differences for SVN repository databases (and Excel files, as well). If I update relevant file timestamps and re-backup, yet another compare cycle shows no errors. >> I think repository database files get updated, but their timestamps do >> not change, so Box never picks them up (the reason I proposed MD5 >> signatures within file attributes a while ago). >Nice idea in theory, but realise that it means that you have to MD5 every >file that doesn't appear to have changed (i.e. almost all of them), to be >really sure that it hasn't. That's an awful lot of overhead. I already wrote a quick and dirty prototype a while ago for testing purposes, adding MD5s for all files to file attribute stream and to folder checksum algorithm. Given, my machines use the latest CPUs, but the overall backup completion time overhead was only around 10% - 15%. I also tested CRC-32s, but the difference was only in the 5% area, so MD5s are worth it. >I think the consensus is that inode change notification is the most >efficient way to detect changed files. Now we just have to implement it. How would that work under Window$? Gary ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html From boxbackup at fluffy.co.uk Tue Apr 10 20:29:33 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 10 Apr 2007 20:29:33 +0100 (BST) Subject: [Box Backup] bbackupd - read errors on database files In-Reply-To: <232035.70740.qm@web36708.mail.mud.yahoo.com> References: <232035.70740.qm@web36708.mail.mud.yahoo.com> Message-ID: Hi Gary and all, > I already wrote a quick and dirty prototype a while ago for testing > purposes, adding MD5s for all files to file attribute stream and to > folder checksum algorithm. Given, my machines use the latest CPUs, but > the overall backup completion time overhead was only around 10% - 15%. I > also tested CRC-32s, but the difference was only in the 5% area, so MD5s > are worth it. Ben, I'd be happy to implement this (especially if Gary can provide his quick and dirty code). What do you say, should we have it for the next version (post 0.11)? Maybe as an optional feature, off by default? We could store the MD5 checksum as an optional extended attribute, so it would be backwards compatible, or else have a special magic value of the MD5 field (maybe all zeroes) to indicate that no checksum has been stored. If necessary, we can run the entire bbackupd test suite twice, once with MD5 checksums enabled and once with them disabled, to make sure that nothing gets broken either way. Otherwise, I can just write a test that uses utimes(). >> I think the consensus is that inode change notification is the most >> efficient way to detect changed files. Now we just have to implement >> it. > > How would that work under Window$? Windows has the same functionality, but with a different interface. We can abstract that out. 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 Apr 12 09:47:58 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 12 Apr 2007 09:47:58 +0100 (BST) Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: References: Message-ID: Hi Stefan, On Tue, 10 Apr 2007, Stefan Tauner wrote: >> Does your location directory end with a backslash in the configuration >> file? It shouldn't. Will check this as well. > > in both zip files the sample config file has a \ at the end of the > path so i didnt dare to change this :) Sorry, what sample config file? As far as I'm aware, the zip files that I distribute don't have any sample config files. > i removed the backslash and the quick compare works now. OK, that's good to know, I've added a check for this to the bbackupquery compare command. > i havent looked into it yet because the last release was 2005, but i > just realized who made it, so i guess its not dead ;) It's not dead, it's pining for the hills ;-) It's been on hold for a while as I've been concentrating on improving the Box Backup core platform on Windows. That's getting close to finished now. > i cant say exactly whats the problem, i just havent found it to be > very helpful when i was looking for advice. If you find it difficult to find something, or duplicate information, and you don't feel confident about editing it yourself, then please point it out to us, as you have done here, and one of us can fix it for you. > i think the problem is, > that it has too much noise (think about the stuff from the old wiki). > for example > http://bbdev.fluffy.co.uk/trac/wiki/GeneralInstall > and > http://bbdev.fluffy.co.uk/trac/wiki/CompilationOnDebian > are almost equivalent but both lack some of the details of the other, > so you have to read both to get all information. To be fair, the start of the "CompilationOnDebian" page does say: > This howto was created during the testing of Box Backup 0.10 RC3, > February 2006. This page augments only slightly the GeneralInstall page, > which takes authority over any errors or uncertainties herein. > ill probably merge them and add my input in the next days (if thats > ok?) Sure, please go ahead The CompilationOnDebian page is, in my opinion, too verbose and specific to a particular, unusual distribution (DeMuDi) which nobody else is likely to be running. General Debian instructions would probably help more. There should be no need to edit your /etc/apt/sources.list file at all. > id maybe interested in contributing code also, although c++ is new to > me. there are so many small thinks, that could be improved even by my > imo :) Sure, please send questions, explanations or patches to the developers' list. http://bbdev.fluffy.co.uk/trac/wiki/MailingLists > do you guys have an irc channel somewhere? No, only the developers' list. I don't have time to hang out on IRC. 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 Apr 13 14:54:04 2007 From: boxbackup at fluffy.co.uk (Andrei) Date: Fri, 13 Apr 2007 16:54:04 +0300 Subject: [Box Backup] Support for BoxBackup Server on Windows Message-ID: Hello, Sorry if I'm asking something stupid. I know from the wiki that the 0.10 server doesn't run on windows. However, I'm wondering whether the same holds true for the latest code in the subversion repository. Has any progress been made towards making BoxBackup server run on Windows? Thanks! From boxbackup at fluffy.co.uk Fri Apr 13 21:57:23 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 13 Apr 2007 21:57:23 +0100 (BST) Subject: [Box Backup] Support for BoxBackup Server on Windows In-Reply-To: References: Message-ID: Hi Andrei, On Fri, 13 Apr 2007, Andrei wrote: > I know from the wiki that the 0.10 server doesn't run on windows. > > However, I'm wondering whether the same holds true for the latest code > in the subversion repository. Has any progress been made towards making > BoxBackup server run on Windows? The answer is "kind of". It runs well enough (in my branch, not 0.10 trunk) to make the unit tests pass. But I don't think you'd want to run it on Windows in practice, especially if you had more than one client. The reason is that it's not multi-threaded, only one client can connect at a time, and housekeeping runs synchronously after the client disconnects, which may block the client from reconnecting for a long time, with a large data store. Running a full multi-threaded server on Windows is not a priority for any of us at the moment, as far as I know. 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 Apr 16 19:17:50 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 16 Apr 2007 20:17:50 +0200 (CEST) Subject: [Box Backup] lcd with bbackupquery on win32 (chris' binaries) In-Reply-To: References: Message-ID: Hi Stefan, On Mon, 9 Apr 2007, Stefan Tauner wrote: > then i installed chris' precompiled binaries rev 784 (updated them > today to the current 1280) into my truecrypt container (mounted as > removable device). > > backing up my documents folder from "D:\Documents\" on fat32 works > without problems. > i could also restore several files using bbackupquery get (-i). > but... changing directory locally doesnt work at all. > ive tried lots of commands with and without quoting, with escaping and > even with "sh cd..." > i couldnt even get into the parent dir or a subdir. > in the best case it gives an error message only and does nothing. > sometimes (most of the time with 784) it fell back into the windows > directory: > query > lcd d:\ > Local current directory is now '\\?\d:\' > query > sh ls > CMD.EXE was started with '\\?\d:\' as the current directory path. UNC > paths > are not supported. Defaulting to Windows directory. > > whats the correct syntax to cd to another drive with the win32 rls? > > the compare command doesnt work either > compare -aq fails instantly (= on the first file?) with: > Failed to open 'D:\Documents\\Default.rdp': The filename, directory > name, or volume label syntax is incorrect. You are absolutely right, changing local directories was badly broken, and not spotted because we didn't have any unit tests. I've fixed it and added tests, and released a new version of the client. Please could you test it and let me know if it solves the problem for you? http://bbdev.fluffy.co.uk/trac/wiki/WindowsClientReleases 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 Apr 17 05:13:51 2007 From: boxbackup at fluffy.co.uk (boxbackup at fluffy.co.uk) Date: Tue, 17 Apr 2007 14:13:51 +1000 Subject: [Box Backup] Chris. Release 1516 Message-ID: <000e01c780a6$d0a72590$71f570b0$@com.au> Hi Chris you certainly have done a large body of work. I have been playing with you 1516 release and have noticed some problems that may or may not be bugs. The extended logging to file is very useful. Much better then event viewer. I have noticed that in the wiki for this patch it is listed that the extended logging info will go to the file instead of to the system event log. However the logging seems to go to both locations. On another note: I would like to play with this and VSS in windows. Is it possible to obtain a source package from you thanks. From boxbackup at fluffy.co.uk Tue Apr 17 10:25:06 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 17 Apr 2007 10:25:06 +0100 (BST) Subject: [Box Backup] Chris. Release 1516 In-Reply-To: <000e01c780a6$d0a72590$71f570b0$@com.au> References: <000e01c780a6$d0a72590$71f570b0$@com.au> Message-ID: Hi (Scott?), > I have been playing with you 1516 release and have noticed some problems > that may or may not be bugs. > > The extended logging to file is very useful. Much better then event > viewer. > > I have noticed that in the wiki for this patch it is listed that the > extended logging info will go to the file instead of to the system event > log. However the logging seems to go to both locations. The ExtendedLogFile is entirely separate from ExtendedLogging. Turn of ExtendedLogging to stop logging to the event viewer. > On another note: I would like to play with this and VSS in windows. Is > it possible to obtain a source package from you Can you download it with a Subversion client? This is very helpful if you want to submit changes. Follow the instructions here: http://bbdev.fluffy.co.uk/trac/wiki/CompileWithVisualC If you can't use Subversion, I can send you a zip of the sources. 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 Apr 17 11:12:01 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Tue, 17 Apr 2007 11:12:01 +0100 Subject: [Box Backup] Restore & Compare Issue Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I have been playing with Box Backup and ran into a couple of issues ( I have read the documentation over and over ) - -> Exception: Connection TLSReadFailed (Probably a network issue between client and server.) (7/34) Here is what I am trying to do: root at io:/root/bin# 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 > list 0000272a -d---- venus query > restore venus /tmp/venus_restore Exception: Connection TLSReadFailed (Probably a network issue between client and server.) (7/34) The other issue is I tried to do a compare... root at io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit 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. WARNING: Quick compare used -- file attributes are not checked. Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does not exist, but store file '/venus/ CoreSystem_backup_200704142000.tar.gz' does. Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does not exist, but store file '/venus/ CoreSystem_backup_200704152000.tar.gz' does. [ 0 (of 2) differences probably due to file modifications after the last upload ] Differences: 2 (0 dirs excluded, 0 files excluded) Logging off... Session finished. However inside the /data/mars directory I have: root at io:/data/mars# ls -alh total 7.5G drwxr-xr-x 2 root root 160 Apr 16 20:00 . drwxr-xr-x 11 root root 264 Mar 28 11:39 .. - -rw-r--r-- 1 root root 3.8G Apr 15 20:29 CoreSystem_backup_200704142000.tar.gz - -rw-r--r-- 1 root root 3.8G Apr 16 20:29 CoreSystem_backup_200704152000.tar.gz IO is the client / Mars is the BoxBackup server. Confused ? I do not understand why its unable to see the files which are in the specified directory. Has anyone else had this issue ?? Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGJJ106vWewLkSmagRAipLAJoDZSgOgavOn46gbW6PE3MpT9qg9QCfcwu2 BIjqkoH9zaAOOybGP03JTNE= =23Df -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Wed Apr 18 13:40:59 2007 From: boxbackup at fluffy.co.uk (dave bamford) Date: Wed, 18 Apr 2007 13:40:59 +0100 Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: <460147E1.90408@brightavenue.com> References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> Message-ID: <462611DB.5030000@logical-progress.com> Hi I get the same error but for a different reason. I just moved the server from a machine running FC5 to Debian and copied the accounts. I noticed I was getting the RaidFileDoesntExist (2/11) in the logs so I looked on the list and found this email. When I run bbstoreaccounts check xx fix it throws the same exception when it finds an error to fix. I tracked the code down to RaidFileUtil::RaidFileExists which most of the time returns NonRaid, but returns NoFile when a write is required. I am running SW RAID 1 in the OS so I have told the server that there is no RAID I hope this is right as it was how the old server worked. The store is mounted on /dev/md0 as /boxbackup. If I hack the code so that NoFile is replaced by NonRaid the check fix continues but eventually throws and exception CannotOverwriteExistingFile (2/4) Now I am stuck as I am not a programmer. Thanks Dave Bamford. Peter Porter wrote: > Ben Summers wrote: > >> >> On 21 Mar 2007, at 03:49, Peter Porter wrote: >> >>> I've come across an odd issue with one of my Box Backup clients >>> (v0.10, server and clients) -- "exception RaidFile >>> RaidFileDoesn'tExist (2/11)". The error arose several months ago, >>> and continues to happen on any attempted connection for that >>> particular client, both remote connections -- from bbackupd or >>> bbackupquery, during bbstored housekeeping, or locally on the backup >>> server when running "bbstoreaccounts info". >>> >>> I saw no further details when enabling ExtendedLogging or a debug >>> build, but I added a few extra debugging statements and figured out >>> that it can't find "info.rfw" in that account's folder. I see an >>> info.rfw file in other accounts' folders, but not in >>> /backups/backup/000000c2/. Any ideas what could have caused this, >>> or how to recreate this file? I'm hoping there's a way to recover >>> from this situation rather than blowing away the store and having >>> the client repopulate an empty store. I'd like to know what sort of >>> situation could cause this, but evidence for that may be long gone... >> >> >> >> bbstoreaccounts check c2 fix >> >> Ben > > > Well, I feel a bit stupid now. That was directly on the documentation > site. It found and repaired one error and resolved my issue. Thanks > for the help Ben, I apologize for wasting your time. > > I assume this has been discussed before, but is there a plan to add > command-line help (e.g. an -h or -? argument that explains what > commands are possible) to the various Box Backup applications? Or man > pages for the apps and config files? > > -Peter > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Fri Apr 20 00:03:39 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 20 Apr 2007 00:03:39 +0100 (BST) Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: <462611DB.5030000@logical-progress.com> References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> Message-ID: Hi Dave, On Wed, 18 Apr 2007, dave bamford wrote: > I get the same error but for a different reason. I just moved the server > from a machine running FC5 to Debian and copied the accounts. I noticed > I was getting the RaidFileDoesntExist (2/11) in the logs so I looked on > the list and found this email. When I run bbstoreaccounts check xx fix > it throws the same exception when it finds an error to fix. How big is the store for this account? Would it be possible for you to give one of us access to the entire store directory for the account? It's encrypted, so we can't ready your data, but it would be very helpful in fixing this bug. 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 Apr 20 00:27:45 2007 From: boxbackup at fluffy.co.uk (dave bamford) Date: Fri, 20 Apr 2007 00:27:45 +0100 Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> Message-ID: <4627FAF1.3030706@logical-progress.com> Chris Wilson wrote: > Hi Dave, > > On Wed, 18 Apr 2007, dave bamford wrote: > >> I get the same error but for a different reason. I just moved the >> server from a machine running FC5 to Debian and copied the accounts. >> I noticed I was getting the RaidFileDoesntExist (2/11) in the logs so >> I looked on the list and found this email. When I run bbstoreaccounts >> check xx fix it throws the same exception when it finds an error to fix. > > > How big is the store for this account? Would it be possible for you to > give one of us access to the entire store directory for the account? > It's encrypted, so we can't ready your data, but it would be very > helpful in fixing this bug. > > Cheers, Chris. Foot in mouth, I had the store mounted as readonly on error. So when I had problems with one of the drives it remounted the filesystem readonly. I have since found that the drives only work reliably if they are set to 150Mb/s transfer rate. Although the controller and the drives should support 300mb/s. So the only comment I have is that the error message should maybe be more informative. Sorry to waste peoples time. Dave From boxbackup at fluffy.co.uk Fri Apr 20 09:36:15 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 20 Apr 2007 09:36:15 +0100 (BST) Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: <4627FAF1.3030706@logical-progress.com> References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> <4627FAF1.3030706@logical-progress.com> Message-ID: Hi Dave, On Fri, 20 Apr 2007, dave bamford wrote: > Foot in mouth, I had the store mounted as readonly on error. So when I > had problems with one of the drives it remounted the filesystem > readonly. I have since found that the drives only work reliably if they > are set to 150Mb/s transfer rate. Although the controller and the drives > should support 300mb/s. > > So the only comment I have is that the error message should maybe be more > informative. So was there an error in the store that was causing the RaidFileDoesntExist exception, which you were able to fix with the bbstoreaccounts tool once the drive was remounted read-write? Is it the RaidFileDoesntExist error that you're saying should be more informative? From bbstored or bbstoreaccounts? 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 Apr 20 14:39:14 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Fri, 20 Apr 2007 14:39:14 +0100 Subject: [Box Backup] Restore & Compare Issue In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17 Apr 2007, at 11:12, Matt Brown wrote: > Hi All, > > I have been playing with Box Backup and ran into a couple of issues > ( I have read the documentation over and over ) > > - -> Exception: Connection TLSReadFailed (Probably a network issue > between client and server.) (7/34) > > Here is what I am trying to do: > > root at io:/root/bin# 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 > list > 0000272a -d---- venus > query > restore venus /tmp/venus_restore > Exception: Connection TLSReadFailed (Probably a network issue > between client and server.) (7/34) > Hi, Would using over a VPN be causing any issues related to Exception: Connection TLSReadFailed (Probably a network issue between client and server.) (7/34) (Clutching at straws now) Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGKMKJ6vWewLkSmagRAuULAJ49J90cSiPfBP1p/5g7cSAFQ6SaWACfVA7c 1bNx2K3yuWoFHTBaKz8IwXI= =M5Xg -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Fri Apr 20 15:56:32 2007 From: boxbackup at fluffy.co.uk (Mikael Syska) Date: Fri, 20 Apr 2007 16:56:32 +0200 Subject: [Box Backup] Restore & Compare Issue In-Reply-To: References: Message-ID: <4628D4A0.5040409@syska.dk> Matt Brown wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17 Apr 2007, at 11:12, Matt Brown wrote: > >> Hi All, >> >> I have been playing with Box Backup and ran into a couple of issues ( >> I have read the documentation over and over ) >> >> - -> Exception: Connection TLSReadFailed (Probably a network issue >> between client and server.) (7/34) >> >> Here is what I am trying to do: >> >> root at io:/root/bin# 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 > list >> 0000272a -d---- venus >> query > restore venus /tmp/venus_restore >> Exception: Connection TLSReadFailed (Probably a network issue between >> client and server.) (7/34) >> > > > > Hi, > > Would using over a VPN be causing any issues related to Exception: > Connection TLSReadFailed (Probably a network issue between client and > server.) (7/34) Not here ... been using BB over ssh tunnel and over IPsec vpn on freebsd with no problems. > > (Clutching at straws now) > > Regards > > Matt Brown > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFGKMKJ6vWewLkSmagRAuULAJ49J90cSiPfBP1p/5g7cSAFQ6SaWACfVA7c > 1bNx2K3yuWoFHTBaKz8IwXI= > =M5Xg > -----END PGP SIGNATURE----- > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > best regards Mikael Syska From boxbackup at fluffy.co.uk Fri Apr 20 16:17:17 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Fri, 20 Apr 2007 16:17:17 +0100 Subject: [Box Backup] Restore & Compare Issue In-Reply-To: <4628D4A0.5040409@syska.dk> References: <4628D4A0.5040409@syska.dk> Message-ID: <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> Hi, >> >> Would using over a VPN be causing any issues related to Exception: >> Connection TLSReadFailed (Probably a network issue between client >> and server.) (7/34) > Not here ... been using BB over ssh tunnel and over IPsec vpn on > freebsd with no problems. >> >> (Clutching at straws now) >> >> Regards >> >> Matt Brown >> >> _______________________________________________ >> boxbackup mailing list >> boxbackup at fluffy.co.uk >> http://lists.warhead.org.uk/mailman/listinfo/boxbackup >> >> > > best regards > Mikael Syska > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup Hi Mikael, Thanks for that, maybe I am taking the error to literaly and its not network related at all - could this be a permissions error SSL related ? BB does run as root so not sure what it cant access. Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGKNmA6vWewLkSmagRAv0PAKCCBVgkiEsl8jylYtY/pqx9xaeIHQCfQXZ9 cE94MZ2h4Ac9KHvJpYYzr6I= =cMiS -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Fri Apr 20 17:47:22 2007 From: boxbackup at fluffy.co.uk (Dave Bamford) Date: Fri, 20 Apr 2007 17:47:22 +0100 Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> <4627FAF1.3030706@logical-progress.com> Message-ID: <4628EE9A.2030400@logical-progress.com> Chris Wilson wrote: > Hi Dave, > > On Fri, 20 Apr 2007, dave bamford wrote: > >> Foot in mouth, I had the store mounted as readonly on error. So when >> I had problems with one of the drives it remounted the filesystem >> readonly. I have since found that the drives only work reliably if >> they are set to 150Mb/s transfer rate. Although the controller and >> the drives should support 300mb/s. >> >> So the only comment I have is that the error message should maybe be >> more informative. > > So was there an error in the store that was causing the > RaidFileDoesntExist exception, which you were able to fix with the > bbstoreaccounts tool once the drive was remounted read-write? > > Is it the RaidFileDoesntExist error that you're saying should be more > informative? From bbstored or bbstoreaccounts? > > Cheers, Chris. Yes its all fixed now. Initially the error message implied to me that raidfile.conf did not exist. perhaps the file that is being sought should be displayed in the message. I would probably have worked out what was wrong much quicker. Thanks Dave From boxbackup at fluffy.co.uk Fri Apr 20 20:56:30 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 20 Apr 2007 20:56:30 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue In-Reply-To: <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> Message-ID: Hi Matt, On Fri, 20 Apr 2007, Matt Brown wrote: >> > Would using over a VPN be causing any issues related to Exception: >> > Connection TLSReadFailed (Probably a network issue between client and >> > server.) (7/34) >> >> Not here ... been using BB over ssh tunnel and over IPsec vpn on freebsd >> with no problems. > > Thanks for that, maybe I am taking the error to literaly and its not network > related at all - could this be a permissions error SSL related ? > > BB does run as root so not sure what it cant access. I think it is network related, unless you have somehow got your certificates or key files messed up, but in that case I don't think you'd be able to log in with bbackupquery and get a file listing. Do you have any huge directories backed up? How long does the restore run before it fails with TLSReadFailed? What was the last file that it restored, and how big is that file? Was it completely restored? Perhaps we have to do SSL keepalives during restore to keep the connection open, as we do during backups? Is there any chance that the VPN tunnel went down during the restore? Or the Internet connection between client and server? Can you measure any packet loss on that connection by pinging from client to server while the restore is running? Could it perhaps be an MTU problem over the VPN tunnel? Do other things work over that tunnel? Can you use FTP to transfer large files in both directions? 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 Apr 20 21:00:49 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Fri, 20 Apr 2007 21:00:49 +0100 (BST) Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: <4628EE9A.2030400@logical-progress.com> References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> <4627FAF1.3030706@logical-progress.com> <4628EE9A.2030400@logical-progress.com> Message-ID: Hi Dave, On Fri, 20 Apr 2007, Dave Bamford wrote: >> > Foot in mouth, I had the store mounted as readonly on error. So when I >> > had problems with one of the drives it remounted the filesystem >> > readonly. I have since found that the drives only work reliably if they >> > are set to 150Mb/s transfer rate. Although the controller and the drives >> > should support 300mb/s. >> > >> > So the only comment I have is that the error message should maybe be >> > more informative. >> >> Is it the RaidFileDoesntExist error that you're saying should be more >> informative? From bbstored or bbstoreaccounts? > > Yes its all fixed now. Initially the error message implied to me that > raidfile.conf did not exist. perhaps the file that is being sought > should be displayed in the message. I would probably have worked out > what was wrong much quicker. OK, I've added a description to that exception: "Error when accessing a file on the store. Check the store with bbstoreaccounts check." That message should be displayed whenever the exception is thrown. Would that have been enough to point you in the right direction? 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 Apr 21 13:05:04 2007 From: boxbackup at fluffy.co.uk (Dave Bamford) Date: Sat, 21 Apr 2007 13:05:04 +0100 Subject: [Box Backup] RaidFileDoesntExist (2/11) In-Reply-To: References: <20070313163946.GA26373@ayup.limey.net> <20070313234711.GA22363@ayup.limey.net> <20070314235131.GB17302@ayup.limey.net> <20070315002943.GA20233@ayup.limey.net> <20070315024422.GA28106@ayup.limey.net> <20070317021944.GB26262@ayup.limey.net> <4600AB54.5080903@brightavenue.com> <603ADDB4-7F5F-4F30-A91C-755A353B9F71@fluffy.co.uk> <460147E1.90408@brightavenue.com> <462611DB.5030000@logical-progress.com> <4627FAF1.3030706@logical-progress.com> <4628EE9A.2030400@logical-progress.com> Message-ID: <4629FDF0.50207@logical-progress.com> Chris Wilson wrote: > Hi Dave, > > On Fri, 20 Apr 2007, Dave Bamford wrote: > >>> > Foot in mouth, I had the store mounted as readonly on error. So >>> when I > had problems with one of the drives it remounted the >>> filesystem > readonly. I have since found that the drives only work >>> reliably if they > are set to 150Mb/s transfer rate. Although the >>> controller and the drives > should support 300mb/s. >>> > > So the only comment I have is that the error message should >>> maybe be > more informative. >>> >>> Is it the RaidFileDoesntExist error that you're saying should be more >>> informative? From bbstored or bbstoreaccounts? >> >> Yes its all fixed now. Initially the error message implied to me that >> raidfile.conf did not exist. perhaps the file that is being sought >> should be displayed in the message. I would probably have worked out >> what was wrong much quicker. > > OK, I've added a description to that exception: > > "Error when accessing a file on the store. Check the store with > bbstoreaccounts check." > > That message should be displayed whenever the exception is thrown. > Would that have been enough to point you in the right direction? > > Cheers, Chris. Thanks Chris thats fine. Cheers Dave From boxbackup at fluffy.co.uk Sat Apr 21 14:15:11 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Sat, 21 Apr 2007 14:15:11 +0100 Subject: [Box Backup] Restore & Compare Issue In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> Message-ID: <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, >>> > Would using over a VPN be causing any issues related to >>> Exception: > Connection TLSReadFailed (Probably a network issue >>> between client and > server.) (7/34) >>> >>> Not here ... been using BB over ssh tunnel and over IPsec vpn on >>> freebsd with no problems. >> >> Thanks for that, maybe I am taking the error to literaly and its >> not network related at all - could this be a permissions error SSL >> related ? >> >> BB does run as root so not sure what it cant access. > > I think it is network related, unless you have somehow got your > certificates or key files messed up, but in that case I don't think > you'd be able to log in with bbackupquery and get a file listing. > I think the certs are fine, backing up seems to be fine. BB is sending a single 3.5GB file each night to the BB server. > Do you have any huge directories backed up? Only this one 3.5GB file (its a 20GB SQL database file compressed to 3.5GB (gzip)) > > How long does the restore run before it fails with TLSReadFailed? > Immediately, as soon as I ask it to restore a dir or do a get object the TLS issue raises it head, but sending to the server for backup part is fine. > What was the last file that it restored, and how big is that file? > Was it completely restored? > I have not managed to restore a single file, I am going to backup a small file 2Mb and see if I can restore that .. just to eliminate as a file size problem. > Perhaps we have to do SSL keepalives during restore to keep the > connection open, as we do during backups? > Possibly, however it does not appear to get a certain way then fail, it fails at the start and nothing except directories are created on the local client. > Is there any chance that the VPN tunnel went down during the > restore? Or the Internet connection between client and server? Can > you measure any packet loss on that connection by pinging from > client to server while the restore is running? > Not that I can see, this tunnel is a main link between two sites and is used continuously during the day, if the tunnel was to fail we would have approx 50 users screaming at us, so I think the tunnel is robust and stable. The backup is performed at night when there is little or no traffic. > Could it perhaps be an MTU problem over the VPN tunnel? Do other > things work over that tunnel? Can you use FTP to transfer large > files in both directions? The servers are all located at one location and all the users at another, there is constant traffic and scanned files being sent up and down the link. The link is a 10MB leased line at the other end and a 4MB leased line at our end. We can quite often achieve 3.5MB constant across it quite happily. We used to do an Rsync of the file (s) on a nightly basis over the same tunnel without issue - however looking at BB we wanted a secure backup (encrypted) and this BB server will service other backups from other servers in due course - however until I can satisfy myself I can get the data back I am unable to roll this out across the other servers which is a shame. Any light on this would be great, I am really looking forward to using BB :-) Kind Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGKg5i6vWewLkSmagRAvmLAJ4nofosu0ZJQDSXReo0qRxOVr+9oQCdF4CY fFxIXKB2TMul1/Hh++W11Bk= =5xkl -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Tue Apr 24 08:57:46 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Tue, 24 Apr 2007 08:57:46 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Hi Chris, > >>>> > Would using over a VPN be causing any issues related to >>>> Exception: > Connection TLSReadFailed (Probably a network issue >>>> between client and > server.) (7/34) >>>> >>>> Not here ... been using BB over ssh tunnel and over IPsec vpn on >>>> freebsd with no problems. >>> >>> Thanks for that, maybe I am taking the error to literaly and its >>> not network related at all - could this be a permissions error >>> SSL related ? >>> >>> BB does run as root so not sure what it cant access. >> >> I think it is network related, unless you have somehow got your >> certificates or key files messed up, but in that case I don't >> think you'd be able to log in with bbackupquery and get a file >> listing. >> > > I think the certs are fine, backing up seems to be fine. BB is > sending a single 3.5GB file each night to the BB server. > >> Do you have any huge directories backed up? > > Only this one 3.5GB file (its a 20GB SQL database file compressed > to 3.5GB (gzip)) > >> >> How long does the restore run before it fails with TLSReadFailed? >> > Immediately, as soon as I ask it to restore a dir or do a get > object the TLS issue raises it head, but sending to the server for > backup part is fine. > >> What was the last file that it restored, and how big is that file? >> Was it completely restored? >> > I have not managed to restore a single file, I am going to backup a > small file 2Mb and see if I can restore that .. just to eliminate > as a file size problem. > >> Perhaps we have to do SSL keepalives during restore to keep the >> connection open, as we do during backups? >> > Possibly, however it does not appear to get a certain way then > fail, it fails at the start and nothing except directories are > created on the local client. > >> Is there any chance that the VPN tunnel went down during the >> restore? Or the Internet connection between client and server? Can >> you measure any packet loss on that connection by pinging from >> client to server while the restore is running? >> > Not that I can see, this tunnel is a main link between two sites > and is used continuously during the day, if the tunnel was to fail > we would have approx 50 users screaming at us, so I think the > tunnel is robust and stable. The backup is performed at night when > there is little or no traffic. > >> Could it perhaps be an MTU problem over the VPN tunnel? Do other >> things work over that tunnel? Can you use FTP to transfer large >> files in both directions? > > The servers are all located at one location and all the users at > another, there is constant traffic and scanned files being sent up > and down the link. The link is a 10MB leased line at the other end > and a 4MB leased line at our end. We can quite often achieve 3.5MB > constant across it quite happily. We used to do an Rsync of the file > (s) on a nightly basis over the same tunnel without issue - however > looking at BB we wanted a secure backup (encrypted) and this BB > server will service other backups from other servers in due course > - however until I can satisfy myself I can get the data back I am > unable to roll this out across the other servers which is a shame. > > Any light on this would be great, I am really looking forward to > using BB :-) > Ok I have now tried with two other files, 1 which was 8k in size and 1 which was 11MB in size. Both were fetched without any TLS issues - therefore it appears that BB has an issue restoring single files over a certain size. The file I am trying to restore is 3.5GB is there a limit anywhere ? Kind Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGLbh+6vWewLkSmagRAl16AJ9p/jtRLOAzfZO9+f1Ye/F/+2kQpwCbBSdE BC/WGwAh6aN4L4zxMWRLj40= =CO1e -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Tue Apr 24 09:24:36 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 24 Apr 2007 09:24:36 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> Message-ID: Hi Matt, On Tue, 24 Apr 2007, Matt Brown wrote: >> > Do you have any huge directories backed up? >> >> Only this one 3.5GB file (its a 20GB SQL database file compressed to 3.5GB >> (gzip)) By the way, I don't think this is a good idea. Because of the way that gzip works, you will end up uploading about 3.5 GB every night (replacing the entire file). Normally for an rsync-style backup I would recommend that you back up uncompressed files instead. Box Backup does its own compression, so you should not actually lose much space on the server. However, I'm not sure whether it will be any more efficient on uploads because it depends how much of that 20 GB file gets churned every day. I'd say it's definitely worth a try. > Ok I have now tried with two other files, 1 which was 8k in size and 1 > which was 11MB in size. Both were fetched without any TLS issues - > therefore it appears that BB has an issue restoring single files over a > certain size. The file I am trying to restore is 3.5GB is there a limit > anywhere ? There should not be, but it's possible that either there is a bug with restoring large files (over 2 GB), or that the filesystem that you're restoring to does not support large files. To eliminate the latter, could you try dd'ing a large file in the restore directory? (Is that /tmp? Is it a ramdisk by any chance?) dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k and check that it does actually produce a 4GB file? 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 Apr 24 10:19:15 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Tue, 24 Apr 2007 10:19:15 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> Message-ID: <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> > Do you have any huge directories backed up? >>> Only this one 3.5GB file (its a 20GB SQL database file compressed >>> to 3.5GB (gzip)) > > By the way, I don't think this is a good idea. Because of the way > that gzip works, you will end up uploading about 3.5 GB every night > (replacing the entire file). > > Normally for an rsync-style backup I would recommend that you back > up uncompressed files instead. Box Backup does its own compression, > so you should not actually lose much space on the server. However, > I'm not sure whether it will be any more efficient on uploads > because it depends how much of that 20 GB file gets churned every > day. I'd say it's definitely worth a try. > >> Ok I have now tried with two other files, 1 which was 8k in size >> and 1 which was 11MB in size. Both were fetched without any TLS >> issues - therefore it appears that BB has an issue restoring >> single files over a certain size. The file I am trying to restore >> is 3.5GB is there a limit anywhere ? > > There should not be, but it's possible that either there is a bug > with restoring large files (over 2 GB), or that the filesystem that > you're restoring to does not support large files. > > To eliminate the latter, could you try dd'ing a large file in the > restore directory? (Is that /tmp? Is it a ramdisk by any chance?) > > dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k > > and check that it does actually produce a 4GB file? Hi Chris, Well the file is in question is an SQL backup done via NT Backup on a Windows 2003 Server and then rsync'd (via Cygwin) to a 2.5TB data central backup store (Linux box with large storage array) and in turn produces a 20GB file - this data store then needs an offsite backup so I am running the bbackup client to send to the remote host. As I am trying to keep the transfer small(ish) I gzip first otherwise we would be sending a 20GB file each night (and growing). 3.5GB a night is not too much of a problem for us as the pipe carrying the data is big enough and quiet at night - my main concern is if the gzip gets corrupted when sending/restoring as I do not like depending on compressed data where I can help it. I intend on sending all files uncompressed and then do a snapshot each night to the remote BB server (with exception of the SQL backup file). I have tried changing the LCD to other paths i.e /data /home and / tmp and still the same issue. I tried /tmp to make sure this was not a directory perms issue. The only thing I can conclude so far is that it would be something to do with the size of the file :( Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGLcuW6vWewLkSmagRAhQQAJ94sV/Elo1lkU0UNBm4veNpVY48owCfQB6E dHzw/RriJ7L482pw/IWS/oc= =pYFi -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Tue Apr 24 10:45:33 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 24 Apr 2007 10:45:33 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> Message-ID: Hi Matt, On Tue, 24 Apr 2007, Matt Brown wrote: > Well the file is in question is an SQL backup done via NT Backup on a > Windows 2003 Server and then rsync'd (via Cygwin) to a 2.5TB data > central backup store (Linux box with large storage array) and in turn > produces a 20GB file - this data store then needs an offsite backup so I > am running the bbackup client to send to the remote host. As I am trying > to keep the transfer small(ish) I gzip first otherwise we would be > sending a 20GB file each night (and growing). 3.5GB a night is not too > much of a problem for us as the pipe carrying the data is big enough and > quiet at night - my main concern is if the gzip gets corrupted when > sending/restoring as I do not like depending on compressed data where I > can help it. If I understand correctly, you are doing SQL server -> offsite store running bbackupd -> bbstored server? I would send the file from the SQL server to the offsite store uncompressed using rsync. That will use less than 3.5 GB of bandwidth and take less time too. Alternatively, gunzip it on the offsite store before running bbackupd on it. The problem is not just the 3.5 GB of bandwidth per day, but the fact that every update on the bbackupd server will be 3.5 GB as well. You will use a lot of space very quickly on the server if you do this. > I have tried changing the LCD to other paths i.e /data /home and /tmp and > still the same issue. I tried /tmp to make sure this was not a directory > perms issue. > > The only thing I can conclude so far is that it would be something to do with > the size of the file :( Please try the dd as well to make sure that it's not a local filesystem issue. 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 Apr 24 17:45:30 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Tue, 24 Apr 2007 17:45:30 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> Well the file is in question is an SQL backup done via NT Backup >> on a Windows 2003 Server and then rsync'd (via Cygwin) to a 2.5TB >> data central backup store (Linux box with large storage array) and >> in turn produces a 20GB file - this data store then needs an >> offsite backup so I am running the bbackup client to send to the >> remote host. As I am trying to keep the transfer small(ish) I gzip >> first otherwise we would be sending a 20GB file each night (and >> growing). 3.5GB a night is not too much of a problem for us as the >> pipe carrying the data is big enough and quiet at night - my main >> concern is if the gzip gets corrupted when sending/restoring as I >> do not like depending on compressed data where I can help it. > > If I understand correctly, you are doing SQL server -> offsite > store running bbackupd -> bbstored server? > > I would send the file from the SQL server to the offsite store > uncompressed using rsync. That will use less than 3.5 GB of > bandwidth and take less time too. > > Alternatively, gunzip it on the offsite store before running > bbackupd on it. > > The problem is not just the 3.5 GB of bandwidth per day, but the > fact that every update on the bbackupd server will be 3.5 GB as > well. You will use a lot of space very quickly on the server if you > do this. > >> I have tried changing the LCD to other paths i.e /data /home and / >> tmp and still the same issue. I tried /tmp to make sure this was >> not a directory perms issue. >> >> The only thing I can conclude so far is that it would be something >> to do with the size of the file :( > > Please try the dd as well to make sure that it's not a local > filesystem issue. Hi Chris, Well I ran the command and this was what was returned: root at io:/tmp# dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 60.7408 seconds, 70.7 MB/s In relation to the rsync of the actual file(s), the only way we are able to do that is if the Server that is running SQL Server 2005 (I am no windows expert, this is second hand) is told to disconnect the Database so we can rsync the actual SQL DB File(s) and then reconnect to it again afterwards - however because this is in a cluster environment, I am told the SQL Server would think SQL Server has failed or stopped and would fall over to the other SQL Server :( - therefore an automated backup is preformed each night using SQL Server or NT Backup to create this one large file - once this has been created we simply use Rsync to shift it over to the storage array. In addition, I was under the assumption that BB will use available soft/hard space available on the server and once this is close to full housekeeping would free up space. Currently we are only keeping about 7 days of backups of this file offsite - we have 3 months + in house if we needed to roll back plus transaction logs. However as always I am open to suggestions and ways around these kind of issues, as there is usually more than one way to skin a cat :-) Kind Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGLjQ56vWewLkSmagRAtDEAJ4iHcT9XgzwW06a7n2BhijaRGUNlwCfYGqN jMvj3cH9DutNo54csaArWng= =g8nz -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Tue Apr 24 22:58:55 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Tue, 24 Apr 2007 22:58:55 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> Message-ID: Hi Matt, On Tue, 24 Apr 2007, Matt Brown wrote: > Well I ran the command and this was what was returned: > > root at io:/tmp# dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k > 4096+0 records in > 4096+0 records out > 4294967296 bytes (4.3 GB) copied, 60.7408 seconds, 70.7 MB/s OK, so it's not a problem storing 4 GB files on your /tmp drive. It must be a bug in Box Backup restore, as far as I can tell. I will investigate as soon as I have time. > In relation to the rsync of the actual file(s), the only way we are able > to do that is if the Server that is running SQL Server 2005 (I am no > windows expert, this is second hand) is told to disconnect the Database > so we can rsync the actual SQL DB File(s) and then reconnect to it again > afterwards - however because this is in a cluster environment, I am told > the SQL Server would think SQL Server has failed or stopped and would > fall over to the other SQL Server :( - therefore an automated backup is > preformed each night using SQL Server or NT Backup to create this one > large file - once this has been created we simply use Rsync to shift it > over to the storage array. How about not gzipping the file before transferring it, and turning of compression in MS Backup? > In addition, I was under the assumption that BB will use available > soft/hard space available on the server and once this is close to full > housekeeping would free up space. Currently we are only keeping about 7 > days of backups of this file offsite - we have 3 months + in house if we > needed to roll back plus transaction logs. Yes, this is true, but you would be able to store a lot more history on the Box Backup server if the diffs were smaller. The best way to achieve this is to back up uncompressed files, as far as I know (especially if they are large files which change regularly, which seems to be the case 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 Thu Apr 26 11:37:17 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Thu, 26 Apr 2007 11:37:17 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> Message-ID: <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, >> Well I ran the command and this was what was returned: >> >> root at io:/tmp# dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k >> 4096+0 records in >> 4096+0 records out >> 4294967296 bytes (4.3 GB) copied, 60.7408 seconds, 70.7 MB/s > > OK, so it's not a problem storing 4 GB files on your /tmp drive. It > must be a bug in Box Backup restore, as far as I can tell. I will > investigate as soon as I have time. > Ok, that would be cool - I am happy to test any patches etc if that helps you ? >> In relation to the rsync of the actual file(s), the only way we >> are able to do that is if the Server that is running SQL Server >> 2005 (I am no windows expert, this is second hand) is told to >> disconnect the Database so we can rsync the actual SQL DB File(s) >> and then reconnect to it again afterwards - however because this >> is in a cluster environment, I am told the SQL Server would think >> SQL Server has failed or stopped and would fall over to the other >> SQL Server :( - therefore an automated backup is preformed each >> night using SQL Server or NT Backup to create this one large file >> - once this has been created we simply use Rsync to shift it over >> to the storage array. > > How about not gzipping the file before transferring it, and turning > of compression in MS Backup? > Well the file that is produced on the MS box is not gzipped until it reaches the storage array - it is once here we gzip and BB it to the offsite BBServer. >> In addition, I was under the assumption that BB will use available >> soft/hard space available on the server and once this is close to >> full housekeeping would free up space. Currently we are only >> keeping about 7 days of backups of this file offsite - we have 3 >> months + in house if we needed to roll back plus transaction logs. > > Yes, this is true, but you would be able to store a lot more > history on the Box Backup server if the diffs were smaller. The > best way to achieve this is to back up uncompressed files, as far > as I know (especially if they are large files which change > regularly, which seems to be the case here). > In addition Chris, I am not sure wether its just we have the directories in the wrong place but am also seeing this issue: root at io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit 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. WARNING: Quick compare used -- file attributes are not checked. Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does not exist, but store file '/venus/ CoreSystem_backup_200704142000.tar.gz' does. Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does not exist, but store file '/venus/ CoreSystem_backup_200704152000.tar.gz' does. [ 0 (of 2) differences probably due to file modifications after the last upload ] Differences: 2 (0 dirs excluded, 0 files excluded) Logging off... Session finished. However inside the /data/mars directory I have: root at io:/data/mars# ls -alh total 7.5G drwxr-xr-x 2 root root 160 Apr 16 20:00 . drwxr-xr-x 11 root root 264 Mar 28 11:39 .. - - -rw-r--r-- 1 root root 3.8G Apr 15 20:29 CoreSystem_backup_200704142000.tar.gz - - -rw-r--r-- 1 root root 3.8G Apr 16 20:29 CoreSystem_backup_200704152000.tar.gz Any pointers ? Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD0DBQFGMIDf6vWewLkSmagRAnqvAJMEIxEiSL+p1WXCC9oPj01hm40sAJY0tRk/ TnshTM0MqPTNcQ0bRIIG =0sqk -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Thu Apr 26 20:38:19 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 26 Apr 2007 20:38:19 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, On Thu, 26 Apr 2007, Matt Brown wrote: > Ok, that would be cool - I am happy to test any patches etc if that > helps you ? Yes, it's extremely important and useful to have your help in finding and fixing this bug, since I don't think I'll be able to reproduce it. I don't think anybody has had such a problem before so there must be something very unusual going on. > Well the file that is produced on the MS box is not gzipped until it > reaches the storage array - it is once here we gzip and BB it to the > offsite BBServer. Have you tried not gzipping it on the storage array? I think your backup would be faster and more efficient this way. > root at io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit ... > WARNING: Quick compare used -- file attributes are not checked. > Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does not exist, > but store file '/venus/CoreSystem_backup_200704142000.tar.gz' does. > Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does not exist, > but store file '/venus/CoreSystem_backup_200704152000.tar.gz' does. ... > However inside the /data/mars directory I have: > > root at io:/data/mars# ls -alh > total 7.5G > drwxr-xr-x 2 root root 160 Apr 16 20:00 . > drwxr-xr-x 11 root root 264 Mar 28 11:39 .. > - - -rw-r--r-- 1 root root 3.8G Apr 15 20:29 > CoreSystem_backup_200704142000.tar.gz > - - -rw-r--r-- 1 root root 3.8G Apr 16 20:29 > CoreSystem_backup_200704152000.tar.gz This is definitely very odd. Could you try something for me? Run the following command on io: strace -s 128 /usr/local/bin/bbackupquery "compare -aq" quit \ > /tmp/compare.log 2>&1 and gzip up /tmp/compare.log and send it to me? Is there anything strange about the /data filesystem? Do other kinds of compare work properly (e.g. not quick compare?) 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 Apr 26 22:40:27 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 26 Apr 2007 22:40:27 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, On Thu, 26 Apr 2007, Matt Brown wrote: > Well the file that is produced on the MS box is not gzipped until it > reaches the storage array - it is once here we gzip and BB it to the > offsite BBServer. By the way, exactly what kind of system is "io"? Did you build Box Backup from source on it? Did you run the unit tests? Did they pass? If you didn't run them, could you try? (./runtest ALL in the box backup source directory). I've just verified that I can restore a 2 GB file with no problem on my Linux system. I'm testing restoring a directory with several large files now. 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 Apr 26 22:59:08 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Thu, 26 Apr 2007 22:59:08 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, > By the way, exactly what kind of system is "io"? > Its a Linux Box - Ubuntu Server 6.06 (Dapper) running a compiled version of BB 0.10 - attached to a Dell Storage Array with 2.5TB capacity (Model No escapes me, but can get when onsite tomorrow). > Did you build Box Backup from source on it? Did you run the unit > tests? Did they pass? If you didn't run them, could you try? (./ > runtest ALL in the box backup source directory). > Indeed, tests appeared fine - I can re-run and submit output if required (if large maybe offlist). > I've just verified that I can restore a 2 GB file with no problem > on my Linux system. I'm testing restoring a directory with several > large files now. Hmm.. odd. Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGMSCx6vWewLkSmagRAr0+AJ0ehkOIoTk981loIUTq3OTza4muFgCfXAOc xnVnlY7hT8pkOd1nC/pfT0I= =sZo7 -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Thu Apr 26 23:05:08 2007 From: boxbackup at fluffy.co.uk (Matt Brown) Date: Thu, 26 Apr 2007 23:05:08 +0100 Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, > >> Ok, that would be cool - I am happy to test any patches etc if >> that helps you ? > > Yes, it's extremely important and useful to have your help in > finding and fixing this bug, since I don't think I'll be able to > reproduce it. I don't think anybody has had such a problem before > so there must be something very unusual going on. > Sure, be happy to. >> Well the file that is produced on the MS box is not gzipped until >> it reaches the storage array - it is once here we gzip and BB it >> to the offsite BBServer. > > Have you tried not gzipping it on the storage array? I think your > backup would be faster and more efficient this way. > I did the initial upload unzipped, Please dont take this the wrong way, but I was unsure how 'smart' the compare and diff algorithm would be as the file is being created a fresh each day on the windows box before it arrives at IO. >> root at io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit > ... >> WARNING: Quick compare used -- file attributes are not checked. >> Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does >> not exist, but store file '/venus/ >> CoreSystem_backup_200704142000.tar.gz' does. >> Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does >> not exist, but store file '/venus/ >> CoreSystem_backup_200704152000.tar.gz' does. > ... >> However inside the /data/mars directory I have: >> >> root at io:/data/mars# ls -alh >> total 7.5G >> drwxr-xr-x 2 root root 160 Apr 16 20:00 . >> drwxr-xr-x 11 root root 264 Mar 28 11:39 .. >> - - -rw-r--r-- 1 root root 3.8G Apr 15 20:29 >> CoreSystem_backup_200704142000.tar.gz >> - - -rw-r--r-- 1 root root 3.8G Apr 16 20:29 >> CoreSystem_backup_200704152000.tar.gz > > This is definitely very odd. Could you try something for me? Run > the following command on io: > > strace -s 128 /usr/local/bin/bbackupquery "compare -aq" quit \ > > /tmp/compare.log 2>&1 > Sure > and gzip up /tmp/compare.log and send it to me? > Ok will do. > Is there anything strange about the /data filesystem? > Only that it is a mounted file system which resides on a Dell Storage Array 2.5TB > Do other kinds of compare work properly (e.g. not quick compare?) Afraid not, I can however see the files and know they are there as per the snip above. Regards Matt Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGMSIZ6vWewLkSmagRAgDAAKCmuTLU9mE1++xxW2vNuFOY2fF0ZwCfaTvt AaLaG5VOIrL6IbI97ROQSig= =sMGZ -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Thu Apr 26 23:13:54 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 26 Apr 2007 23:13:54 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, >> By the way, exactly what kind of system is "io"? >> > Its a Linux Box - Ubuntu Server 6.06 (Dapper) running a compiled version > of BB 0.10 - attached to a Dell Storage Array with 2.5TB capacity (Model > No escapes me, but can get when onsite tomorrow). How is the storage array attached to Io? Network? SCSI? What does "mount" say about /data? > Indeed, tests appeared fine - I can re-run and submit output if required > (if large maybe offlist). Probably not necessary, but it would be interesting to know if Box Backup was compiled with large file support. As far as I can tell, the only way to check this is to run ./configure (with the same options that were used before, see the first few line of config.log for details) and check the last few lines of its output for: Large files: yes 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 Apr 26 23:17:11 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Thu, 26 Apr 2007 23:17:11 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, On Thu, 26 Apr 2007, Matt Brown wrote: >> Have you tried not gzipping it on the storage array? I think your >> backup would be faster and more efficient this way. > > I did the initial upload unzipped, Please dont take this the wrong way, > but I was unsure how 'smart' the compare and diff algorithm would be as > the file is being created a fresh each day on the windows box before it > arrives at IO. The diffing algorithm, as far as I know, does not care if the file is recreated each day (i.e. that the inode number has changed). It will just scan for matching blocks on both sides, and only send the blocks which have changed. This happens after compression, so it should do what you want. If it doesn't, I really want to know about it! Restoring a directory with 2 x 2GB files worked fine for me (linux FC2 on both ends). 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 Apr 27 21:57:55 2007 From: boxbackup at fluffy.co.uk (Marco Bartholomew) Date: Fri, 27 Apr 2007 16:57:55 -0400 Subject: [Box Backup] Exception: Cipher EVPFinalFailure (5/6) Message-ID: <463263D3.3010600@prepresstraining.com> (**Sorry if this message comes through twice, I forgot to make the first one text-only.**) I'm getting this error now too, and was wondering if there were any developments in this area. I recently upgraded our servers (running Linux - ArchLinux) from kernel 2.6.17 to 2.6.20, and openssl was upgraded as well. It appeared as if everything was running OK, but when I checked the logs, I noticed these errors on all our servers (all running the same distro and version.) Times are correct on all servers, and nothing else had changed except for the upgrade. Our window clients appear to be working normally. Apr 20 21:00:01 manjula bbackupd[28018]: Incoming connection from local (UNIX socket) Apr 20 21:00:01 manjula bbackupd[28018]: Connection from command socket Apr 20 21:00:01 manjula bbackupd[28018]: Beginning scan of local files Apr 20 21:00:01 manjula bbackupd[28018]: Opening connection to server backups.xxxxx.com... Apr 20 21:00:01 manjula bbackupd[28018]: Send Version(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Receive Version(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Send Login(0x5,0x0) Apr 20 21:00:01 manjula bbackupd[28018]: Receive LoginConfirmed(0x42db7dbe00780,0x2709242,0x2710000,0x30d4000) Apr 20 21:00:01 manjula bbackupd[28018]: Connection made, login successful Apr 20 21:00:01 manjula bbackupd[28018]: Send ListDirectory(0x1,0x2,0xc,false) Apr 20 21:00:01 manjula bbackupd[28018]: Receive Success(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Receiving stream, size 144 Apr 20 21:00:01 manjula bbackupd[28018]: Send SetClientStoreMarker(0x42e94f49fe640) Apr 20 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 20 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 20 21:00:01 manjula bbackupd[28018]: Exception caught (5/6), reset state and waiting to retry... Apr 20 21:01:41 manjula bbackupd[28018]: File statistics: total file size uploaded 0, bytes already on server 0, encoded size 0 Apr 21 21:00:01 manjula bbackupd[28018]: Incoming connection from local (UNIX socket) Apr 21 21:00:01 manjula bbackupd[28018]: Connection from command socket Apr 21 21:00:01 manjula bbackupd[28018]: Beginning scan of local files Apr 21 21:00:01 manjula bbackupd[28018]: Opening connection to server backups.xxxxxxxx.com... Apr 21 21:00:01 manjula bbackupd[28018]: Send Version(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Receive Version(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Send Login(0x5,0x0) Apr 21 21:00:01 manjula bbackupd[28018]: Receive LoginConfirmed(0x42e94f49fe640,0x2709242,0x2710000,0x30d4000) Apr 21 21:00:01 manjula bbackupd[28018]: Connection made, login successful Apr 21 21:00:01 manjula bbackupd[28018]: Send ListDirectory(0x1,0x2,0xc,false) Apr 21 21:00:01 manjula bbackupd[28018]: Receive Success(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Receiving stream, size 144 Apr 21 21:00:01 manjula bbackupd[28018]: Send SetClientStoreMarker(0x42ea912774640) Apr 21 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 21 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 21 21:00:01 manjula bbackupd[28018]: Exception caught (5/6), reset state and waiting to retry... Apr 21 21:01:41 manjula bbackupd[28018]: File statistics: total file size uploaded 0, bytes already on server 0, encoded size 0 Paul MacKenzie wrote: > Hello > > I have this error: Exception: Cipher EVPFinalFailure (5/6) > > ------------- > > server# bbackupquery > Box Backup Query Tool v0.10, (c) Ben Summers and contributors 2003-2006 > Using configuration file /usr/local/etc/box/bbackupd.conf > Connecting to store... > Handshake with store... > Login to store... > Login complete. > > Type "help" for a list of commands. > > query > ls > 00000002 -d---- Exception: Cipher EVPFinalFailure (5/6) > > ------------------- > > How can it be fixed? > > The clocks are the same right now > > Thu Mar 15 09:37:13 EDT 2007 > > Any help would be greatly appreciated. > > Thanks > > Paul > > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > From boxbackup at fluffy.co.uk Fri Apr 27 21:26:40 2007 From: boxbackup at fluffy.co.uk (Marco Bartholomew) Date: Fri, 27 Apr 2007 16:26:40 -0400 Subject: [Box Backup] Exception: Cipher EVPFinalFailure (5/6) In-Reply-To: <200703151339.l2FDdCIU005393@elephants.elehost.com> References: <200703151339.l2FDdCIU005393@elephants.elehost.com> Message-ID: <46325C80.4@prepresstraining.com> Hi: I'm getting this error now too, and was wondering if there were any developments in this area. I recently upgraded our servers (running Linux - ArchLinux) from kernel 2.6.17 to 2.6.20, and openssl was upgraded as well. It appeared as if everything was running OK, but when I checked the logs, I noticed these errors on all our servers (all running the same distro and version.) Times are correct on all servers, and nothing else had changed except for the upgrade. Our window clients appear to be working normally. Apr 20 17:13:19 manjula bbackupd[28018]: Starting daemon (config: /etc/box/bbackupd.conf) (version 0.09) Apr 20 21:00:01 manjula bbackupd[28018]: Incoming connection from local (UNIX socket) Apr 20 21:00:01 manjula bbackupd[28018]: Connection from command socket Apr 20 21:00:01 manjula bbackupd[28018]: Beginning scan of local files Apr 20 21:00:01 manjula bbackupd[28018]: Opening connection to server backups.xxxxx.com... Apr 20 21:00:01 manjula bbackupd[28018]: Send Version(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Receive Version(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Send Login(0x5,0x0) Apr 20 21:00:01 manjula bbackupd[28018]: Receive LoginConfirmed(0x42db7dbe00780, 0x2709242,0x2710000,0x30d4000) Apr 20 21:00:01 manjula bbackupd[28018]: Connection made, login successful Apr 20 21:00:01 manjula bbackupd[28018]: Send ListDirectory(0x1,0x2,0xc,false) Apr 20 21:00:01 manjula bbackupd[28018]: Receive Success(0x1) Apr 20 21:00:01 manjula bbackupd[28018]: Receiving stream, size 144 Apr 20 21:00:01 manjula bbackupd[28018]: Send SetClientStoreMarker(0x42e94f49fe6 40) Apr 20 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:dig ital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 20 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:dig ital envelope routines:EVP_DecryptFinal_ex:bad decrypt Apr 20 21:00:01 manjula bbackupd[28018]: Exception caught (5/6), reset state and waiting to retry... Apr 20 21:01:41 manjula bbackupd[28018]: File statistics: total file size uploaded 0, bytes already on server 0, encoded size 0 Apr 21 21:00:01 manjula bbackupd[28018]: Incoming connection from local (UNIX socket) Apr 21 21:00:01 manjula bbackupd[28018]: Connection from command socket Apr 21 21:00:01 manjula bbackupd[28018]: Beginning scan of local files Apr 21 21:00:01 manjula bbackupd[28018]: Opening connection to server backups.xxxxxxxx.com... Apr 21 21:00:01 manjula bbackupd[28018]: Send Version(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Receive Version(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Send Login(0x5,0x0) Apr 21 21:00:01 manjula bbackupd[28018]: Receive LoginConfirmed(0x42e94f49fe640,0x2709242,0x2710000,0x30d4000) Apr 21 21:00:01 manjula bbackupd[28018]: Connection made, login successful Apr 21 21:00:01 manjula bbackupd[28018]: Send ListDirectory(0x1,0x2,0xc,false) Apr 21 21:00:01 manjula bbackupd[28018]: Receive Success(0x1) Apr 21 21:00:01 manjula bbackupd[28018]: Receiving stream, size 144 Apr 21 21:00:01 manjula bbackupd[28018]: Send SetClientStoreMarker(0x42ea912774640) Apr 21 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_e x:bad decrypt Apr 21 21:00:01 manjula bbackupd[28018]: SSL err during Read: error:06065064:digital envelope routines:EVP_DecryptFinal_e x:bad decrypt Apr 21 21:00:01 manjula bbackupd[28018]: Exception caught (5/6), reset state and waiting to retry... Apr 21 21:01:41 manjula bbackupd[28018]: File statistics: total file size uploaded 0, bytes already on server 0, encoded size 0 Paul MacKenzie wrote: > Hello > > I have this error: Exception: Cipher EVPFinalFailure (5/6) > > ------------- > > server# bbackupquery > Box Backup Query Tool v0.10, (c) Ben Summers and contributors 2003-2006 > Using configuration file /usr/local/etc/box/bbackupd.conf > Connecting to store... > Handshake with store... > Login to store... > Login complete. > > Type "help" for a list of commands. > > query > ls > 00000002 -d---- Exception: Cipher EVPFinalFailure (5/6) > > ------------------- > > How can it be fixed? > > The clocks are the same right now > > Thu Mar 15 09:37:13 EDT 2007 > > Any help would be greatly appreciated. > > Thanks > > Paul > > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > > From boxbackup at fluffy.co.uk Sat Apr 28 11:15:28 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sat, 28 Apr 2007 11:15:28 +0100 (BST) Subject: [Box Backup] Exception: Cipher EVPFinalFailure (5/6) In-Reply-To: <463263D3.3010600@prepresstraining.com> References: <463263D3.3010600@prepresstraining.com> Message-ID: Hi Marco, On Fri, 27 Apr 2007, Marco Bartholomew wrote: > I'm getting this error now too, and was wondering if there were any > developments in this area. > > I recently upgraded our servers (running Linux - ArchLinux) from kernel > 2.6.17 to 2.6.20, and openssl was upgraded as well. It appeared as if > everything was running OK, but when I checked the logs, I noticed these > errors on all our servers (all running the same distro and version.) Times > are correct on all servers, and nothing else had changed except > for the upgrade. Our window clients appear to be working normally. What version of OpenSSL are you using? It seems there may be a bug with 0.9.8d: http://www.mail-archive.com/openssl-dev at openssl.org/msg22413.html In which case, you might like to downgrade to 0.9.8 to see if it fixes the problem. As far as I can tell, this error is not actually causing any data loss. It simply means that the stream was not shut down correctly, when it was already in the process of being shut down. However, bbackupd will discard its internal state when this happens, so it will operate less efficiently, generate more network traffic and take longer to back up. Please let us know if downgrading fixes the problem. 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 Apr 28 18:49:12 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sat, 28 Apr 2007 18:49:12 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, On Thu, 26 Apr 2007, Matt Brown wrote: >> > Ok, that would be cool - I am happy to test any patches etc if that >> > helps you ? >> >> Yes, it's extremely important and useful to have your help in finding >> and fixing this bug, since I don't think I'll be able to reproduce it. >> I don't think anybody has had such a problem before so there must be >> something very unusual going on. OK, I was finally able to reproduce the problem. It only happens with files over 2 GB. I eventually remembered that somebody had seen this problem before, and Ben had written up a problem ticket: http://bbdev.fluffy.co.uk/trac/ticket/2 But the problem never actually got fixed. I wrote some tests and fixed this and one more problem which prevented files over 2GB (on the server) from being downloaded. I've been able to restore a single 3GB file from the server using the "get" command. I verified that the md5 checksum matched the original. There is still a problem somewhere in the backup protocol, because the bbackupquery client craps out after restoring or comparing the file, with a protocol error. I'm still working on this one, but it's slow going because it takes so long to download the file each time. If you want to help out, you could try downloading the latest version of my Box Backup tree from: http://bbdev.fluffy.co.uk/svn/box/chris/merge/ and install it on the server and the client, and see if you can restore your files with the "get" command, and if they have the correct contents. It would also be VERY useful if you could continue to run this version and report any problems that you have with it, since it will almost certainly become the next release (0.11) with only small changes, and additional testing would be most welcome. >> > root at io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit >> ... >> > WARNING: Quick compare used -- file attributes are not checked. >> > Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does not >> > exist, but store file '/venus/CoreSystem_backup_200704142000.tar.gz' >> > does. >> > Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does not >> > exist, but store file '/venus/CoreSystem_backup_200704152000.tar.gz' >> > does. >> ... >> > However inside the /data/mars directory I have: >> > >> > root at io:/data/mars# ls -alh >> > total 7.5G >> > drwxr-xr-x 2 root root 160 Apr 16 20:00 . >> > drwxr-xr-x 11 root root 264 Mar 28 11:39 .. >> > - - -rw-r--r-- 1 root root 3.8G Apr 15 20:29 >> > CoreSystem_backup_200704142000.tar.gz >> > - - -rw-r--r-- 1 root root 3.8G Apr 16 20:29 >> > CoreSystem_backup_200704152000.tar.gz I still haven't been able to reproduce this problem, so I think I still the strace output to figure out what's going on. 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 Sun Apr 29 21:24:38 2007 From: boxbackup at fluffy.co.uk (Imran Niazi) Date: Sun, 29 Apr 2007 13:24:38 -0700 Subject: [Box Backup] Issue with Incremental backup of mail folder Message-ID: <20070429200124.M44807@naweb.com> Hey guys, I'm running 0.10 of server/client, and I ran into an issue. One of the machines that the client runs on is the mail server, and of course backing up /var/spool/mail (mbox format large file that stores all the messages for a particular user). Anyway, all the emails of a particular user were deleted, approximately 8 days ago. I thought I could get into atleast an one or two old backup of that folder, but the file only shows once, and its about 24 hours old (I assume its still under MaxUploadWait. I assumed that we would be able to get to an older version of a file, but it would also mean there would be as many versions of that file as there would be days. But It also means that if a file is truncated , we have no backups of the file. Or I'm hoping there is a low level way of finding out previous versions of the file and possibly un-diffing the file? I guess the way it works is, that since the inode didn't change, the backup thinks that all modifications are the same file and the original can be discarded (or maybe the client behaves like that?) I guess if its not possible to get the old versions, then it would be cool to have it such that a user can specify a certain date & time, and the backup would give you the state of a file at that time. Also there would be an option to give a time range, where if a file changed after the time spcified, but still in the time/date range. To do this functionality, however, you'd have to track a timeline plus diffs for each file. There would be a resource/info file for each file tracked/backedup, that would list the initial date of backup, the date the next backup ran, and the diff of it. If the space requirements are going to be very large for this feature then there should also be a configurable number of days/months that it keeps this state information. In its housekeeping, it will remove the deltas from earlier than those days, and update the initial state be the state on that date, as well change the 'initial date' in the resource/info file. Anyway, i'm quickly thinking out loud, and there might be a big flaw in my thinking. It would be an important feature, I believe. Of course if this is how its done already, then I probably wasted everyone's time reading this email. :) Imran Niazi From boxbackup at fluffy.co.uk Sun Apr 29 22:34:05 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sun, 29 Apr 2007 22:34:05 +0100 (BST) Subject: [Box Backup] Restore & Compare Issue ** UPDATE ** In-Reply-To: References: <4628D4A0.5040409@syska.dk> <41E3B7F4-B669-4484-9329-CCF93C0A82FB@mbrown.co.uk> <8C732675-6853-49AB-9008-7C6B9321AA9C@mbrown.co.uk> <202A6CCA-ECCE-4121-8078-C7B2910B2F37@mbrown.co.uk> <83C3A3E8-D317-45A9-878B-48C721F7C444@mbrown.co.uk> Message-ID: Hi Matt, On Sat, 28 Apr 2007, Chris Wilson wrote: > I've been able to restore a single 3GB file from the server using the > "get" command. I verified that the md5 checksum matched the original. > > There is still a problem somewhere in the backup protocol, because the > bbackupquery client craps out after restoring or comparing the file, > with a protocol error. I'm still working on this one, but it's slow > going because it takes so long to download the file each time. I think I've fixed the remaining problems with quick and full compare, and restore, in my tree (http://bbdev.fluffy.co.uk/svn/box/chris/merge/). I would greatly appreciate your help in testing that this is the case. Please note that there was a bug in bbackupd which resulted in it choosing an invalid block size for the upload of large files. The files can be restored, but not compared, because an assertion check fails in the compare command with this block size. The bug is fixed in my tree, but you will need to upload the file again before the new block size will take effect. If you need to restore an older version of the file (with the invalid block size) for some reason, I can supply a patch which will increase the maximum block size to enable you to do so. 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 Sun Apr 29 22:48:26 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Sun, 29 Apr 2007 22:48:26 +0100 (BST) Subject: [Box Backup] Issue with Incremental backup of mail folder In-Reply-To: <20070429200124.M44807@naweb.com> References: <20070429200124.M44807@naweb.com> Message-ID: Hi Imran, On Sun, 29 Apr 2007, Imran Niazi wrote: > Anyway, all the emails of a particular user were deleted, approximately > 8 days ago. I thought I could get into atleast an one or two old backup > of that folder, but the file only shows once, and its about 24 hours old Did you try listing with the -o option? (show old versions of files). > (I assume its still under MaxUploadWait. I assumed that we would be > able to get to an older version of a file, but it would also mean there > would be as many versions of that file as there would be days. But It > also means that if a file is truncated , we have no backups of the file. Truncation or replacement of the file should not have any effect on the way that backups work, i.e. the number of old versions which are kept. The only things that will affect that are the size of the increments (daily changes) and the available space on the store for this account (versus the amount of data in current files, i.e. how much space is available for storing old versions of files). > Or I'm hoping there is a low level way of finding out previous versions > of the file and possibly un-diffing the file? If the old version is present on the store (shown with ls -o) then you can just restore it with "get -i" and its object ID. If it's not shown, then I'm afraid the case is pretty hopeless (unless you have a backup of the store itself at an earlier date). > I guess the way it works is, that since the inode didn't change, the > backup thinks that all modifications are the same file and the original > can be discarded (or maybe the client behaves like that?) No, we only check the inode number to determine if files have been renamed. Box Backup treats file modification in-place, and file deletion and rewriting, exactly the same. > I guess if its not possible to get the old versions, then it would be > cool to have it such that a user can specify a certain date & time, and > the backup would give you the state of a file at that time. Yes, that would be a cool feature. Boxi has something like that, where you can restore a file "as of" a specific time, and you will get last version backed up before that time. > Also there would be an option to give a time range, where if a file > changed after the time spcified, but still in the time/date range. To > do this functionality, however, you'd have to track a timeline plus > diffs for each file. I think that we do this already, i.e. we know the last modification date (not the upload date) of each "old version" still on the store. > There would be a resource/info file for each file tracked/backedup, that > would list the initial date of backup, the date the next backup ran, and > the diff of it. We don't quite do that already, since we don't track the actual times of backup runs, but what I described above should hopefully be enough for what you need. > If the space requirements are going to be very large for this feature > then there should also be a configurable number of days/months that it > keeps this state information. At the moment, we keep it as long as we keep the reverse diff (i.e. the old version of the file) itself. I can't see a reason for keeping it for more or less time than that. > In its housekeeping, it will remove the deltas from earlier than those > days, and update the initial state be the state on that date, as well > change the 'initial date' in the resource/info file. The algorithm to decide what is removed from the store is unfortunately quite complicated, and I don't understand it well. There have been proposals to store the "entire state" of the remote system at a particular time (i.e. snapshot time) as a single entity that would be deleted in its entirety or not at all. That would allow one to implement a policy like "keep the last 14 days worth of backups". Unfortunately, nobody has had time to implement that in Box Backup yet. rdiff-backup does something like that already, but it's not encrypted. For what it's worth, I currently use rdiff-backup for all of my backups (but never to untrusted machines). I hope this helps, 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 Apr 30 07:08:20 2007 From: boxbackup at fluffy.co.uk (Imran Niazi) Date: Sun, 29 Apr 2007 23:08:20 -0700 Subject: [Box Backup] Issue with Incremental backup of mail folder In-Reply-To: References: <20070429200124.M44807@naweb.com> Message-ID: <20070430053358.M62964@naweb.com> Hello Chris, I really appreciate taking the time to answer my email in detail. > Did you try listing with the -o option? (show old versions of files). Yeah, I usually use 'ls -dots' > Truncation or replacement of the file should not have any effect on > the way that backups work, i.e. the number of old versions which are > kept. The only things that will affect that are the size of the > increments (daily changes) and the available space on the store for > this account (versus the amount of data in current files, i.e. how > much space is available for storing old versions of files). Yeah, actually I forgot to note the current store info: Account ID: 00040404 Last object ID: 660916 Blocks used: 9157304 (35770.72Mb) Blocks used by old files: 29429 (114.96Mb) Blocks used by deleted files: 5389922 (21054.38Mb) Blocks used by directories: 25831 (100.90Mb) Block soft limit: 9175040 (35840.00Mb) Block hard limit: 12058624 (47104.00Mb) Client store marker: 1176226959000000 I guess boxbackup or housekeeping puts more emphasis on deleted files and less on old files. This is a mail server, and files are the mbox format files (i.e. one big mail file) for each user. the user in question, her mailbox was probably about 40 megs. And she receives about 10 or 15 emails a day. so the file is constantly changing, and only being sent to bbstored every 24 hours (which is what the threshold is set to now). Oh, btw, the bbstored process in this case has been running since late 2006, but most probably since october 2006, thats when I upgraded (or reinstalled after upgrading the OS, I forget which). Btw I've been running boxbackup, for three years, I think when 0.5 was released. On some of the other clients, the store looks little different: Account ID: 00010101 Last object ID: 5867185 Blocks used: 34586439 (135103.28Mb) Blocks used by old files: 845160 (3301.41Mb) Blocks used by deleted files: 21068380 (82298.36Mb) Blocks used by directories: 166764 (651.42Mb) Block soft limit: 34586440 (135103.28Mb) Block hard limit: 38046108 (148617.61Mb) Client store marker: 1171203234000000 Account ID: 00020202 Last object ID: 1380899 Blocks used: 26214040 (102398.59Mb) Blocks used by old files: 5824767 (22753.00Mb) Blocks used by deleted files: 17815456 (69591.62Mb) Blocks used by directories: 78734 (307.55Mb) Block soft limit: 26214400 (102400.00Mb) Block hard limit: 31457280 (122880.00Mb) Client store marker: 1175843302000000 Account ID: 00030303 Last object ID: 5654517 Blocks used: 40366239 (157680.62Mb) Blocks used by old files: 1712 (6.69Mb) Blocks used by deleted files: 9633809 (37632.07Mb) Blocks used by directories: 148124 (578.61Mb) Block soft limit: 40366240 (157680.62Mb) Block hard limit: 44403888 (173452.69Mb) Client store marker: 1177484669000000 Account ID: 00050505 Last object ID: 88868 Blocks used: 638507 (2494.17Mb) Blocks used by old files: 258480 (1009.69Mb) Blocks used by deleted files: 13590 (53.09Mb) Blocks used by directories: 17988 (70.27Mb) Block soft limit: 15728640 (61440.00Mb) Block hard limit: 18350080 (71680.00Mb) Client store marker: 1164184762000000 > Yes, that would be a cool feature. Boxi has something like that, > where you can restore a file "as of" a specific time, and you will > get last version backed up before that time. Yeah? But in this case, the file was backed up every 24 hours, but only version I can get is the latest one (24 hours ago). (just to be clear) > rdiff-backup does something like that already, but it's not > encrypted. For what it's worth, I currently use rdiff-backup for all > of my backups (but never to untrusted machines). I haven't used rdiff-backup but have heard of it. I've been using boxbackup with great success in the past 3 years. I've had to restore couple of harddrives that crashed, and I was able to get data pretty quickly. I mainly like the feature of boxbackup that the items in question are online and I can browse the directory structure etc. I was used to the commercial solutions which provided the nice directory listing etc. but some of the open source backup programs I saw, were snapshot based, and I would have to restore the backup to a dir to see what files that were there etc. Plus I like the fact that the client distributes the load of backups during the day (assuming that files are changing a few at a time etc.) Not to mention that content is encyrpted etc. Thanks again, Imran Niazi http://www.niazi.net From boxbackup at fluffy.co.uk Mon Apr 30 15:09:26 2007 From: boxbackup at fluffy.co.uk (Marco Bartholomew) Date: Mon, 30 Apr 2007 10:09:26 -0400 Subject: [Box Backup] Exception: Cipher EVPFinalFailure (5/6) In-Reply-To: References: <463263D3.3010600@prepresstraining.com> Message-ID: <4635F896.3030809@prepresstraining.com> Chris Wilson wrote: > Hi Marco, > > > What version of OpenSSL are you using? It seems there may be a bug > with 0.9.8d: > > http://www.mail-archive.com/openssl-dev at openssl.org/msg22413.html > > > In which case, you might like to downgrade to 0.9.8 to see if it fixes > the problem. > > Chris: Thanks for the reply. The version of openssl we upgraded to is 0.9.8e, and there is definitely a bug associated with it as well: http://archlinux.org/news/313/ (I guess I might have checked there first - d'oh) Apparently a patched version is already in testing at Arch. I'm going to wait a bit and see if that version becomes production-ready soon, but if not, I will give the downgrade a shot. Thanks much From boxbackup at fluffy.co.uk Mon Apr 30 15:21:14 2007 From: boxbackup at fluffy.co.uk (Daniel Netzer) Date: Mon, 30 Apr 2007 16:21:14 +0200 Subject: [Box Backup] External CA / asp related questions Message-ID: <4635FB5A.9070404@gehrkens.it> Hi there, first of all: great program! I really like boxbackup! We are currently evaluating a possible boxbackup integration in our Xen based hosting products for file based backups and I have a few questions: * Is it possible to integrate boxbackup into an existing ca infrastructure? * Are there any news on management tools/API? (I have read "BoxBackup Server Side Management Specs") * Is it possible to get information on bandwith usage for clients? (Did not find anything definite on the list just something about sending statistics to a socket...) * Are there any plans for database integration for eg. accounts and/or configs? Thank you! best regards Daniel From boxbackup at fluffy.co.uk Mon Apr 30 18:32:36 2007 From: boxbackup at fluffy.co.uk (Chris Wilson) Date: Mon, 30 Apr 2007 18:32:36 +0100 (BST) Subject: [Box Backup] External CA / asp related questions In-Reply-To: <4635FB5A.9070404@gehrkens.it> References: <4635FB5A.9070404@gehrkens.it> Message-ID: Hi Daniel, On Mon, 30 Apr 2007, Daniel Netzer wrote: > * Is it possible to integrate boxbackup into an existing ca infrastructure? It probably is. There are normally two CAs, one for server certs and one for client certs. The server needs a copy of the client CA certificate, which signed the client certificates, and vice versa. The common name of the client certificates must be the account number, encoded in hex with no leading zeroes, and nothing else. If such certificates can fit in with your CA infrastructure, then you should be able to use them. > * Are there any news on management tools/API? (I have read "BoxBackup > Server Side Management Specs") Not yet, I'm afraid. Whata re your specific requirement? let's discuss it. > * Is it possible to get information on bandwith usage for clients? (Did > not find anything definite on the list just something about sending > statistics to a socket...) The server logs the number of bytes used by the client. Roughly speaking, it should be the same as rsyncing the same directories, maybe a bit better since compression is used and file lists are not sent each time. > * Are there any plans for database integration for eg. accounts and/or > configs? Plans yes, but no time to implement them yet. 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 |