From: Sam P. <sa...@ar...> - 2005-11-30 23:03:06
|
Hi, I succeed to backup 3 directories but a 13Gb /home directory never with=20 rsyncd method, I got : [...] Can't link /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrier = s=E9minaire.doc to /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7c8b66= 0cae58dfb16cd [ 1 lignes saut=E9es ] Can't link /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcreation = k en france.pdf to /mnt/backuppc/BackupPC/cpool/e/e/9/ee9b3444890040d1233= 308cc760e1128 [ 416 lignes saut=E9es ] Read EOF: Connexion r=E9-initialis=E9e par le correspondant Tried again: got 0 bytes finish: removing in-process file ahamdoun/Abdelhake-Aplus/ClientAPlusNet/= Sami/Doc/DOCUMENT DEVIS.doc Child is aborting Parent read EOF from child: fatal error! Done: 350 files, 108968599 bytes Got fatal error during xfer (Child exited prematurely) Backup aborted (Child exited prematurely) How to backup a large size directory with BackupPC ? Thanks in advance for your help. Sam. --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: Les M. <le...@fu...> - 2005-11-30 23:24:23
|
On Wed, 2005-11-30 at 17:02, Sam Przyswa wrote: > Hi, >=20 > I succeed to backup 3 directories but a 13Gb /home directory never with= =20 > rsyncd method, I got : >=20 > [...] > Can't link /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrie= r s=C3=A9minaire.doc to /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7= c8b660cae58dfb16cd > [ 1 lignes saut=C3=A9es ] Out of inodes? What does 'df -i' say? --=20 Les Mikesell le...@fu... |
From: Sam P. <sa...@ar...> - 2005-12-01 00:02:33
|
Les Mikesell a =C3=A9crit : >On Wed, 2005-11-30 at 17:02, Sam Przyswa wrote: > =20 > >>Hi, >> >>I succeed to backup 3 directories but a 13Gb /home directory never with= =20 >>rsyncd method, I got : >> >>[...] >>Can't link /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrie= r s=C3=A9minaire.doc to /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7= c8b660cae58dfb16cd >>[ 1 lignes saut=C3=A9es ] >> =20 >> > >Out of inodes? What does 'df -i' say? > =20 > Sys. de fich. Inodes IUtil. ILib. %IUti. Mont=C3=A9 sur /dev/mapper/Disque02-BACKUPPC 10387456 798653 9588803 8% /mnt/backuppc This is the LVM device of my backuppc home. Sam. --=20 Sam Przyswa - Chef de projet Arial Concept - Int=C3=A9grateur Internet 36, rue de Turin - 75008 - Paris - France Tel: 01 40 54 86 04 - 0870 444 650 - Fax: 01 40 54 83 01 Skype ID: arial-concept Web: http://www.arial-concept.com - Email: In...@ar... --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: <ta...@nu...> - 2005-12-01 09:05:37
|
Quoting Sam Przyswa <sa...@ar...>: > Les Mikesell a =C3=A9crit : > >> On Wed, 2005-11-30 at 17:02, Sam Przyswa wrote: >> >>> Hi, >>> >>> I succeed to backup 3 directories but a 13Gb /home directory never >>> with rsyncd method, I got : >>> >>> [...] >>> Can't link >>> /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrier >>> s=C3=A9minaire.doc to >>> /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7c8b660cae58dfb16cd >>> [ 1 lignes saut=C3=A9es ] >>> >> >> Out of inodes? What does 'df -i' say? >> > Sys. de fich. Inodes IUtil. ILib. %IUti. Mont=C3=A9 sur > > /dev/mapper/Disque02-BACKUPPC > 10387456 798653 9588803 8% /mnt/backuppc > > This is the LVM device of my backuppc home. This is the same problem I am experiencing. My problem is also on LVM2, running reiserfs. Any tips on how to a) increase the nr of inodes or b) check other problems would be welcome. Regards, Tarjei > > Sam. > > -- Sam Przyswa - Chef de projet > Arial Concept - Int=C3=A9grateur Internet > 36, rue de Turin - 75008 - Paris - France > Tel: 01 40 54 86 04 - 0870 444 650 - Fax: 01 40 54 83 01 > Skype ID: arial-concept > Web: http://www.arial-concept.com - Email: In...@ar... > > > > -- Ce message a =EF=BF=BDt=EF=BF=BD v=EF=BF=BDrifi=EF=BF=BD par MailScann= er > pour des virus ou des polluriels et rien de > suspect n'a =EF=BF=BDt=EF=BF=BD trouv=EF=BF=BD. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > _______________________________________________ > BackupPC-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/backuppc-users > http://backuppc.sourceforge.net/ > |
From: Les M. <le...@fu...> - 2005-12-01 19:31:07
|
On Thu, 2005-12-01 at 03:05, ta...@nu... wrote: > Quoting Sam Przyswa <sa...@ar...>: > >>> > >>> [...] > >>> Can't link=20 > >>> /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrier=20 > >>> s=C3=A9minaire.doc to=20 > >>> /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7c8b660cae58dfb16cd > >>> [ 1 lignes saut=C3=A9es ] > >>> > >> > >> Out of inodes? What does 'df -i' say? > >> > > Sys. de fich. Inodes IUtil. ILib. %IUti. Mont=C3=A9 = sur > > > > /dev/mapper/Disque02-BACKUPPC > > 10387456 798653 9588803 8% /mnt/backuppc > > > > This is the LVM device of my backuppc home. >=20 > This is the same problem I am experiencing. My problem is also on LVM2,= =20 > running > reiserfs. Any tips on how to a) increase the nr of inodes or b) check o= ther > problems would be welcome. Are the link errors all coming from files with characters that aren't 7-bit ASCII? Maybe this is a perl character set issue. --=20 Les Mikesell le...@fu... |
From: Sam P. <sa...@ar...> - 2005-12-05 16:15:53
|
Les Mikesell a =E9crit : >On Thu, 2005-12-01 at 03:05, ta...@nu... wrote: > =20 > >>Quoting Sam Przyswa <sa...@ar...>: >> =20 >> >>>>>[...] >>>>>Can't link=20 >>>>>/mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrier=20 >>>>>s=C3=A9minaire.doc to=20 >>>>>/mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7c8b660cae58dfb16cd >>>>>[ 1 lignes saut=C3=A9es ] >>>>> >>>>> =20 >>>>> >>>>Out of inodes? What does 'df -i' say? >>>> >>>> =20 >>>> >>>Sys. de fich. Inodes IUtil. ILib. %IUti. Mont=C3=A9 s= ur >>> >>>/dev/mapper/Disque02-BACKUPPC >>> 10387456 798653 9588803 8% /mnt/backuppc >>> >>>This is the LVM device of my backuppc home. >>> =20 >>> >>This is the same problem I am experiencing. My problem is also on LVM2,= =20 >>running >>reiserfs. Any tips on how to a) increase the nr of inodes or b) check o= ther >>problems would be welcome. >> =20 >> > >Are the link errors all coming from files with characters that >aren't 7-bit ASCII? Maybe this is a perl character set issue. > =20 > On the same server we have 8 others backuped machine with perhaps some=20 filename with 8-bit chars (ISO-8859-1) without problems but only one dir=20 /home 13Gb size. We tried with tar, rsync, rsyncd, with the same result,=20 and we have 56Gb left on the LVM2 device. Last thing, we noticed this problem after added some big files on this=20 dir, no too much problems before... Please help. Sam. --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: Les M. <le...@fu...> - 2005-12-05 16:41:36
|
On Mon, 2005-12-05 at 10:15, Sam Przyswa wrote: > >Are the link errors all coming from files with characters that > >aren't 7-bit ASCII? Maybe this is a perl character set issue. > > > > > > On the same server we have 8 others backuped machine with perhaps some > filename with 8-bit chars (ISO-8859-1) without problems but only one dir > /home 13Gb size. We tried with tar, rsync, rsyncd, with the same result, > and we have 56Gb left on the LVM2 device. > > Last thing, we noticed this problem after added some big files on this > dir, no too much problems before... I think tar has an 8 gig file size limit. Depending on the compile options and libraries the others can end up with a 2 gig limit. Can you try copying the problem file(s) to the backuppc server with the native tool to see if/how that fails? Also, if you have a config from an older version of backuppc you may have a very short timeout that is going off on big files. -- Les Mikesell le...@fu... |
From: Ralf G. <Ral...@ra...> - 2005-12-06 11:15:27
|
Les Mikesell schrieb: > On Mon, 2005-12-05 at 10:15, Sam Przyswa wrote: > [problem with backing up a 13GB file] > > I think tar has an 8 gig file size limit. Depending on the compile > options and libraries the others can end up with a 2 gig limit. Can > you try copying the problem file(s) to the backuppc server with the > native tool to see if/how that fails? Also, if you have a config from > an older version of backuppc you may have a very short timeout that > is going off on big files. I'm backing up a >9GB tgz file with backuppc and tar as transfer method without problems. Client: RHEL AS 4.0 with GNU tar 1.14 Backuppc: Debian 3.1 with GNU tar 1.14 http://backuppc.sourceforge.net/faq/limitations.html#maximum_backup_file_sizes It seems that with GNU tar the max. size is either 8GB or maybe 64GB. Ralf |
From: Guus H. <gu...@ho...> - 2005-12-05 16:48:17
|
On Mon, 2005-12-05 at 17:15 +0100, Sam Przyswa wrote: [...] > >Are the link errors all coming from files with characters that > >aren't 7-bit ASCII? Maybe this is a perl character set issue. > > > > > > On the same server we have 8 others backuped machine with perhaps some > filename with 8-bit chars (ISO-8859-1) without problems but only one dir > /home 13Gb size. We tried with tar, rsync, rsyncd, with the same result, > and we have 56Gb left on the LVM2 device. > > Last thing, we noticed this problem after added some big files on this > dir, no too much problems before... Hm, I have a suspicion that backuppc somehow or somewhere doesn't play nice with big files, even with huge timeout settings. Where 'big' is larger than about 400 MB. I only use rsync-over-ssh or rsyncd, so I don't know if this is backuppc related or rsync related. What you can try is see if regular rsync does work. You'll probably need to install an rsync daemon on your backuppc server, but that shouldn't interfere. Then execute the same command as backuppc does to try and backup the problematic directory. If that does work, that it isn't any charset issue, but more likely something in backuppc (bug in rsyncp, backuppc itself or your config). In that case, I still think you should collect as much debug info as possible (output from tcpdump, strace and logfiles from backuppc) and report back to this list or to Craig Barratt personally. Maybe he or we can then see what's going on. > Please help. > > Sam. Hth, -- Guus Houtzager Email: gu...@ho... PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D Early to rise, early to bed, makes a man healthy, wealthy and dead. --Rincewind, The Light Fantastic |
From: Sam P. <sa...@ar...> - 2005-12-05 17:08:53
|
Guus Houtzager a =E9crit : >On Mon, 2005-12-05 at 17:15 +0100, Sam Przyswa wrote: > >[...] > > =20 > >>>Are the link errors all coming from files with characters that >>>aren't 7-bit ASCII? Maybe this is a perl character set issue. >>>=20 >>> >>> =20 >>> >>On the same server we have 8 others backuped machine with perhaps some=20 >>filename with 8-bit chars (ISO-8859-1) without problems but only one di= r=20 >>/home 13Gb size. We tried with tar, rsync, rsyncd, with the same result= ,=20 >>and we have 56Gb left on the LVM2 device. >> >>Last thing, we noticed this problem after added some big files on this=20 >>dir, no too much problems before... >> =20 >> > >Hm, I have a suspicion that backuppc somehow or somewhere doesn't play >nice with big files, even with huge timeout settings. Where 'big' is >larger than about 400 MB. I only use rsync-over-ssh or rsyncd, so I >don't know if this is backuppc related or rsync related. > >What you can try is see if regular rsync does work. You'll probably need >to install an rsync daemon on your backuppc server, but that shouldn't >interfere. Then execute the same command as backuppc does to try and >backup the problematic directory. If that does work, that it isn't any >charset issue, but more likely something in backuppc (bug in rsyncp, >backuppc itself or your config). In that case, I still think you should >collect as much debug info as possible (output from tcpdump, strace and >logfiles from backuppc) and report back to this list or to Craig Barratt >personally. Maybe he or we can then see what's going on. > =20 > Right, I do that and will tell you more later, thanks for your help. Sam. --=20 Sam Przyswa - Chef de projet Arial Concept - Int=E9grateur Internet 36, rue de Turin - 75008 - Paris - France Tel: 01 40 54 86 04 - 0870 444 650 - Fax: 01 40 54 83 01 Skype ID: arial-concept Web: http://www.arial-concept.com - Email: In...@ar... --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: Sam P. <sa...@ar...> - 2005-12-10 03:38:05
|
Guus Houtzager a =E9crit : >On Mon, 2005-12-05 at 17:15 +0100, Sam Przyswa wrote: > >[...] > > =20 > >>>Are the link errors all coming from files with characters that >>>aren't 7-bit ASCII? Maybe this is a perl character set issue. >>>=20 >>> >>> =20 >>> >>On the same server we have 8 others backuped machine with perhaps some=20 >>filename with 8-bit chars (ISO-8859-1) without problems but only one di= r=20 >>/home 13Gb size. We tried with tar, rsync, rsyncd, with the same result= ,=20 >>and we have 56Gb left on the LVM2 device. >> >>Last thing, we noticed this problem after added some big files on this=20 >>dir, no too much problems before... >> =20 >> > >Hm, I have a suspicion that backuppc somehow or somewhere doesn't play >nice with big files, even with huge timeout settings. Where 'big' is >larger than about 400 MB. I only use rsync-over-ssh or rsyncd, so I >don't know if this is backuppc related or rsync related. > =20 > I have not bigs file but big directories size 4Gb and 13Gb >What you can try is see if regular rsync does work. You'll probably need >to install an rsync daemon on your backuppc server, but that shouldn't >interfere. Then execute the same command as backuppc does to try and >backup the problematic directory. If that does work, that it isn't any >charset issue, but more likely something in backuppc (bug in rsyncp, >backuppc itself or your config). In that case, I still think you should >collect as much debug info as possible (output from tcpdump, strace and >logfiles from backuppc) and report back to this list or to Craig Barratt >personally. Maybe he or we can then see what's going on. > =20 > I make tests with rsyncd *out* of BackupPC on the same LVM2 device with=20 the command: rsync -av --numeric-ids --perms --owner --group --devices --links=20 --times --block-size=3D2048 --recursive --exclude Maildir/=20 bac...@re...::MyModule ./temp With 2 directories, one 4Gb, one 13Gb the rsyncd failed on some files,=20 sometime .psd, sometime .dll and if I try to restart the backup it stop=20 on the same file. If I remove the file from the remote directory and=20 restart the backup it continue the process for a variable set of time=20 and failed with an other file... The remote machine is on ADSL 1Mbps upload, when the rsync backup failed=20 I got the message: On backup server: Abdelhake/panneaux/LOGO/LOGO BLEU.psd Abdelhake/panneaux/LOGO/LOGO MJC AVEC COLOR.psd rsync: writefd_unbuffered failed to write 4092 bytes: phase "unknown" [ge= nerator]: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(1099) rsync error: received SIGUSR1 or SIGINT (code 20) at main.c(985) Or: rsync: read error: Connection timed out (110) rsync error: error in rsync protocol data stream (code 12) at io.c(584) rsync: connection unexpectedly closed (252687 bytes received so far) [gen= erator] rsync error: error in rsync protocol data stream (code 12) at io.c(434) On remote machine rsyncd.log: 2005/12/06 04:37:08 [6171] send my.server.com [213.186.44.120] Groupware-= 2 (backuppc) Abdelhake/panneaux/LOGO/LOGO BLEU.psd 1050366 2005/12/06 04:57:21 [6171] rsync: writefd_unbuffered failed to write 4096= bytes: phase "unknown" [sender]: Connection timed out (110) 2005/12/06 04:57:21 [6171] rsync error: error in rsync protocol data stre= am (code 12) at io.c(1099) And the tcpdump on server: 12:16:34.968937 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034345867 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:16:35.006659 IP the.remote.com.rsync > my.server.com.42947: . ack 6952= 1 win 0 <nop,nop,timestamp 1046641254 2033652376> 12:17:13.206982 IP the.remote.com.rsync > my.server.com.42947: . 4149388:= 4150836(1448) ack 69521 win 0 <nop,nop,timestamp 1046645072 2033652376> 12:18:34.987042 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034465904 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:18:35.024770 IP the.remote.com.rsync > my.server.com.42947: . ack 6952= 1 win 0 <nop,nop,timestamp 1046653253 2033652376> 12:19:13.234200 IP the.remote.com.rsync > my.server.com.42947: . 4149388:= 4150836(1448) ack 69521 win 0 <nop,nop,timestamp 1046657072 2033652376> 12:20:35.006414 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034585942 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:20:35.044110 IP the.remote.com.rsync > my.server.com.42947: . ack 6952= 1 win 0 <nop,nop,timestamp 1046665252 2033652376> 12:21:13.261435 IP the.remote.com.rsync > my.server.com.42947: . 4149388:= 4150836(1448) ack 69521 win 0 <nop,nop,timestamp 1046669072 2033652376> 12:22:35.024371 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034705980 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:22:35.062016 IP the.remote.com.rsync > my.server.com.42947: . ack 6952= 1 win 0 <nop,nop,timestamp 1046677251 2033652376> 12:23:13.288689 IP the.remote.com.rsync > my.server.com.42947: . 4149388:= 4150836(1448) ack 69521 win 0 <nop,nop,timestamp 1046681072 2033652376> 12:24:35.042232 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034826017 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:24:35.079978 IP the.remote.com.rsync > my.server.com.42947: . ack 6952= 1 win 0 <nop,nop,timestamp 1046689250 2033652376> 12:26:35.060706 IP my.server.com.42947 > the.remote.com.rsync: . ack 4149= 388 win 31548 <nop,nop,timestamp 2034946054 1046571783,nop,nop,sack 1 {41= 50836:4217572}> 12:26:35.098439 IP the.remote.com.rsync > my.server.com.42947: R 41272746= 68:4127274668(0) win 0 It seems that it's not a BackupPC problem but rsync or dsl link... Some help is welcome :-/ Sam. --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: Sam P. <sa...@ar...> - 2005-12-03 17:45:40
|
ta...@nu... a =C3=A9crit : > Quoting Sam Przyswa <sa...@ar...>: > >> Les Mikesell a =C3=A9crit : >> >>> On Wed, 2005-11-30 at 17:02, Sam Przyswa wrote: >>> >>>> Hi, >>>> >>>> I succeed to backup 3 directories but a 13Gb /home directory never=20 >>>> with rsyncd method, I got : >>>> >>>> [...] >>>> Can't link=20 >>>> /mnt/backuppc/BackupPC/pc/mjc-home/new/fHome/fabedu/fcourrier=20 >>>> s=C3=A9minaire.doc to=20 >>>> /mnt/backuppc/BackupPC/cpool/e/e/0/ee0ef20975ecd7c8b660cae58dfb16cd >>>> [ 1 lignes saut=C3=A9es ] >>>> >>> >>> Out of inodes? What does 'df -i' say? >>> >> Sys. de fich. Inodes IUtil. ILib. %IUti. Mont=C3=A9 s= ur >> >> /dev/mapper/Disque02-BACKUPPC >> 10387456 798653 9588803 8% /mnt/backuppc >> >> This is the LVM device of my backuppc home. > > > This is the same problem I am experiencing. My problem is also on=20 > LVM2, running > reiserfs. Any tips on how to a) increase the nr of inodes or b) check=20 > other > problems would be welcome. My LVM2 devices are ext3 filesystem. Sam. --=20 Sam Przyswa - Chef de projet Arial Concept - Int=C3=A9grateur Internet 36, rue de Turin - 75008 - Paris - France Tel: 01 40 54 86 04 - 0870 444 650 - Fax: 01 40 54 83 01 Skype ID: arial-concept Web: http://www.arial-concept.com - Email: In...@ar... --=20 Ce message a =E9t=E9 v=E9rifi=E9 par MailScanner pour des virus ou des polluriels et rien de suspect n'a =E9t=E9 trouv=E9. |
From: Guus H. <gu...@ho...> - 2005-12-01 09:23:44
|
On Thu, 2005-12-01 at 10:05 +0100, ta...@nu... wrote: [...] > This is the same problem I am experiencing. My problem is also on LVM2, > running > reiserfs. Any tips on how to a) increase the nr of inodes or b) check other > problems would be welcome. Reiser dynamically allocates inodes and by doing so has always enough inodes. To debug both your problems: all I can think of at this stage is try to narrow it down which directory which file is causing the problems (remember the buffering in the output in the logs, so you may not see the actual last line or file). When you have that determined, try to backup only that and if that fails, try to tcpdump and strace -p what's going on and post those results here. Maybe someone can see what's going on. I'm betting there's an error or bug somewhere in the rsync-on-the-client vs the backuppc-rsyncp-on-the-server. Please increase the rsyncloglevel of backuppc to 9 (don't know the exact name on top of my head). > Regards, > Tarjei Hth, -- Guus Houtzager Email: gu...@ho... PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D Early to rise, early to bed, makes a man healthy, wealthy and dead. --Rincewind, The Light Fantastic |
From: Tarjei H. <ta...@nu...> - 2005-12-03 12:17:23
|
On Thu, 2005-12-01 at 10:23 +0100, Guus Houtzager wrote: > On Thu, 2005-12-01 at 10:05 +0100, ta...@nu... wrote: > > [...] > > > This is the same problem I am experiencing. My problem is also on LVM2, > > running > > reiserfs. Any tips on how to a) increase the nr of inodes or b) check other > > problems would be welcome. > > Reiser dynamically allocates inodes and by doing so has always enough > inodes. > > To debug both your problems: all I can think of at this stage is try to > narrow it down which directory which file is causing the problems > (remember the buffering in the output in the logs, so you may not see > the actual last line or file). When you have that determined, try to > backup only that and if that fails, try to tcpdump and strace -p what's > going on and post those results here. Maybe someone can see what's going > on. I'm betting there's an error or bug somewhere in the > rsync-on-the-client vs the backuppc-rsyncp-on-the-server. > Please increase the rsyncloglevel of backuppc to 9 (don't know the exact > name on top of my head). Hi, I'm starting to think that this is actually a full disk. I've ordered a new one and hope that will solve the issues. Df is reporting the disk to be 90% full so I think that is the problem. If not, expect me to be back with more inpit :-) Tarjei > > Regards, > > Tarjei > > Hth, > -- Tarjei Huse <ta...@nu...> |
From: Les M. <les...@gm...> - 2005-12-03 17:29:14
|
On Sat, 2005-12-03 at 06:15, Tarjei Huse wrote: > Hi, I'm starting to think that this is actually a full disk. I've > ordered a new one and hope that will solve the issues. Df is reporting > the disk to be 90% full so I think that is the problem. A certain amount (like 10%) may be reserved for root only and backuppc doesn't run as root. -- Les Mikesell le...@fu... |
From: Tarjei H. <ta...@nu...> - 2005-12-11 15:12:28
|
Hi, On Sat, 2005-12-03 at 13:15 +0100, Tarjei Huse wrote: > On Thu, 2005-12-01 at 10:23 +0100, Guus Houtzager wrote: > > On Thu, 2005-12-01 at 10:05 +0100, ta...@nu... wrote: > > [...] > > > > > This is the same problem I am experiencing. My problem is also on LVM2, > > > running > > > reiserfs. Any tips on how to a) increase the nr of inodes or b) check other > > > problems would be welcome. > > > > Reiser dynamically allocates inodes and by doing so has always enough > > inodes. > > > > To debug both your problems: all I can think of at this stage is try to > > narrow it down which directory which file is causing the problems > > (remember the buffering in the output in the logs, so you may not see > > the actual last line or file). When you have that determined, try to > > backup only that and if that fails, try to tcpdump and strace -p what's > > going on and post those results here. Maybe someone can see what's going > > on. I'm betting there's an error or bug somewhere in the > > rsync-on-the-client vs the backuppc-rsyncp-on-the-server. > > Please increase the rsyncloglevel of backuppc to 9 (don't know the exact > > name on top of my head). Did you mean the XferLogLevel or some other loglevel? > Hi, I'm starting to think that this is actually a full disk. I've > ordered a new one and hope that will solve the issues. Df is reporting > the disk to be 90% full so I think that is the problem. I just thought I'd report back that increasing disk size didn't solve the problem - allthought it was needed :-). Also, it prooved the importance of running stuff like this on lvm . I'm now trying to run a new backup after setting the XferLogLevel to 9 and adding -v and --progress to the rsyncargs. Is --progress allowed btw? Regards, Tarjei |
From: BackupPC U. <bac...@do...> - 2005-12-05 17:06:03
|
Hi, > Hm, I have a suspicion that backuppc somehow or somewhere doesn't play > nice with big files, even with huge timeout settings. Where 'big' is > larger than about 400 MB. I only use rsync-over-ssh or rsyncd, so I > don't know if this is backuppc related or rsync related. FWIW, we use BackupPC with rsyncd clients of both Windows and Linux flavor. We regularly backup large .iso files > 3.5 GB without issue across both platforms. Our server is running Slackware 10 with a custom 2.6.14 kernel over GB ethernet. Server uses ReiserFS and Perl is configured w/ large file support. Our client machines are mostly laptop t41 or dell desktops running WinXP. We use the backuppc-rsyncd client on Windows machines and latest rsync on the server. - bpcu |
From: Guus H. <gu...@ho...> - 2005-12-05 21:10:17
|
On Mon, 2005-12-05 at 09:08 -0800, BackupPC User wrote: > Hi, > > > Hm, I have a suspicion that backuppc somehow or somewhere doesn't play > > nice with big files, even with huge timeout settings. Where 'big' is > > larger than about 400 MB. I only use rsync-over-ssh or rsyncd, so I > > don't know if this is backuppc related or rsync related. > FWIW, we use BackupPC with rsyncd clients of both Windows and Linux flavor. We > regularly backup large .iso files > 3.5 GB without issue across both > platforms. I use rsyncd on windows and rsync-over-ssh on linux. Some machines are connected to the backuppc server on a "small" link (adsl or sdsl, 1 or 2 mbit), others at 100 Mbit. Large files on clients behind dsl don't work very well, on machines with a faster link it depends a little. Some machines: no trouble whatsoever, others act weird on large files. I don't have exact details which situation works and which don't. > Our server is running Slackware 10 with a custom 2.6.14 kernel over GB > ethernet. Server uses ReiserFS and Perl is configured w/ large file support. > Our client machines are mostly laptop t41 or dell desktops running WinXP. We > use the backuppc-rsyncd client on Windows machines and latest rsync on the > server. My backuppc server is running Debian Sarge, custom 2.6.14 kernel. Reiserfs 3 filesystem. Perl default Debian, but AFAIK that has large file support. I also use the backuppc-rsyncd clients on windows. > - bpcu Regards, -- Guus Houtzager Email: gu...@ho... PGP fingerprint = 5E E6 96 35 F0 64 34 14 CC 03 2B 36 71 FB 4B 5D Early to rise, early to bed, makes a man healthy, wealthy and dead. --Rincewind, The Light Fantastic |
From: Tarjei H. <ta...@nu...> - 2005-12-11 20:35:13
|
On Sun, 2005-12-11 at 13:07 -0500, Rick DeNatale wrote: > On 12/11/05, Tarjei Huse <ta...@nu...> wrote: > > > I just thought I'd report back that increasing disk size didn't solve > > the problem - allthought it was needed :-). Also, it prooved the > > importance of running stuff like this on lvm . > > How MANY files are in the directory (or directory tree) you are having > troubles with? > Rsync's memory utilization is sensitive to the number of files it > maintains a RAM data structure with information about the files. It > needs about 100 bytes per file. The share contains 40 000 files, so that shouldn't be a problem. > http://samba.anu.edu.au/rsync/FAQ.html#4 > > This rsync troubleshooting page has some more things you might want to > try. http://samba.anu.edu.au/rsync/issues.html Hmm, ok will do. Thanks. What I am wondering about is if it is possible to get a bit more information out of BackupPC wrt why a signal is sent. I think that would help. For example I am wondering why I just get "process killed by user signal", is it possible to log a bit more from the process sending the signal? Also, BackupPC starts up two processes when a backup starts, but I always get one of them defunct. Like this: [ssh] <defunct> backuppc 6478 0.0 0.0 0 0 ? Z 20:41 0:00 [BackupPC_dump] <defunct> Why is one of the processes just defunct? Kind regards, Tarjei > > -- > Rick DeNatale > > Visit the Project Mercury Wiki Site > http://www.mercuryspacecraft.com/ -- Tarjei Huse <ta...@nu...> |
From: Tristan S. <mel...@gm...> - 2005-12-12 15:01:38
|
Sorry if you've already covered this issue, but I'm assuming this backup takes a very long time over a 1mbps ADSL connection. From what I remember, BackupPC has a timeout on backups defined and will stop a backup if it last= s longer then that defined time. (I believe you can modify this time interva= l but I'm not sure how right now). How long is the 13gig backup going for before it fails? Is it always the same time interval? Or does it randomly change? If the time interval is random then the problem probably lies in the connection between locations. The connection reset by peer issues you were getting during the rsync operation seem to indicate that there are connection issues between the machines. I'm not too familiar with using rsync over such a slow connection with large amounts of data, but I'd assum= e that it is not normal to get connection reset by peer messages. It seems t= o me that the problem doesn't lie in BackupPC, but I'm just a lowly user not = a developer so I may not be right ;) -Tristan On 12/11/05, Tarjei Huse <ta...@nu...> wrote: > > On Sun, 2005-12-11 at 13:07 -0500, Rick DeNatale wrote: > > On 12/11/05, Tarjei Huse <ta...@nu...> wrote: > > > > > I just thought I'd report back that increasing disk size didn't solve > > > the problem - allthought it was needed :-). Also, it prooved the > > > importance of running stuff like this on lvm . > > > > How MANY files are in the directory (or directory tree) you are having > > troubles with? > > > Rsync's memory utilization is sensitive to the number of files it > > maintains a RAM data structure with information about the files. It > > needs about 100 bytes per file. > The share contains 40 000 files, so that shouldn't be a problem. > > http://samba.anu.edu.au/rsync/FAQ.html#4 > > > > This rsync troubleshooting page has some more things you might want to > > try. http://samba.anu.edu.au/rsync/issues.html > > Hmm, ok will do. Thanks. > > What I am wondering about is if it is possible to get a bit more > information out of BackupPC wrt why a signal is sent. I think that would > help. For example I am wondering why I just get "process killed by user > signal", is it possible to log a bit more from the process sending the > signal? > > Also, BackupPC starts up two processes when a backup starts, but I > always get one of them defunct. Like this: > [ssh] <defunct> > backuppc 6478 0.0 0.0 0 0 ? Z 20:41 0:00 > [BackupPC_dump] <defunct> > > Why is one of the processes just defunct? > > Kind regards, > Tarjei > > > > > -- > > Rick DeNatale > > > > Visit the Project Mercury Wiki Site > > http://www.mercuryspacecraft.com/ > -- > Tarjei Huse <ta...@nu...> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > BackupPC-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/backuppc-users > http://backuppc.sourceforge.net/ > |