Menu
▾
▴
[BackupPC-users] RE: BackupFilesOnly -- path with spaces?
|
From: Evan K. <eko...@th...> - 2004-01-12 19:39:02
|
I don't what I was on last night, but Its all better today! Sorry about that folks. Thanks, Evan. > -----Original Message----- > From: bac...@li... > [mailto:bac...@li...]On Behalf Of > bac...@li... > Sent: January 11, 2004 11:01 PM > To: bac...@li... > Subject: BackupPC-users digest, Vol 1 #533 - 5 msgs > > > Send BackupPC-users mailing list submissions to > bac...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/backuppc-users > or, via email, send a message with subject or body 'help' to > bac...@li... > > You can reach the person managing the list at > bac...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of BackupPC-users digest..." > > > Today's Topics: > > 1. BackupFilesOnly -- path with spaces? (Evan Kouroupis) > 2. Re: Query about XferLOG file (cba...@us...) > 3. Re: Query about XferLOG file (Ben) > 4. Re: Query about XferLOG file (cba...@us...) > 5. Re: Query about XferLOG file (Ben) > > --__--__-- > > Message: 1 > Reply-To: <eko...@th...> > From: "Evan Kouroupis" <eko...@th...> > To: <bac...@li...> > Date: Sun, 11 Jan 2004 20:03:18 -0500 > Subject: [BackupPC-users] BackupFilesOnly -- path with spaces? > > This is a multi-part message in MIME format. > > ------=_NextPart_000_0001_01C3D87D.F593ED90 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > How do you get BackupPC to understand a path that has spaces in the > directory name when using the BackupFilesOnly option. > > Ex.$Conf{BackupFilesOnly} = '/my special directory/'; > > It always reads it as 3 separate directories, i.e. > /my/special/directory. > > Thank you in advance. > Evan Kouroupis, MSCE + Internet, MCP, CNA > eko...@th... > www.theitpro.ca > > > ---------------------------------------------------------------------- > Try our new PC performance enhancing and Windows backup > software products > Immediate Delivery, order on-line! > www.theitpro.ca > > Don't get hacked, Don't go down again! > Get the HotBrick Firewall VPN Appliance > www.theitpro.ca/hotbrick.shtm > > Free computer tips and more...simply sign up to receive our > free newsletter, > "eNewsPro" > www.theitpro.ca (use the sign up form on the right side of > our home page) > ---------------------------------------------------------------------- > > > ------=_NextPart_000_0001_01C3D87D.F593ED90 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = > charset=3Diso-8859-1"> > > > <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD> > <BODY> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial > size=3D2>How do = > you get=20 > BackupPC to understand a path that has spaces in the > directory name when = > using=20 > the BackupFilesOnly option.</FONT></SPAN></DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial=20 > size=3D2>Ex.$Conf{BackupFilesOnly} =3D '/my special = > directory/';</FONT></SPAN></DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial size=3D2>It = > always reads it=20 > as 3 separate directories, i.e. = > /my/special/directory.</FONT></SPAN></DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial=20 > size=3D2></FONT></SPAN> </DIV> > <DIV><SPAN class=3D554535700-12012004><FONT face=3DArial > size=3D2>Thank = > you in=20 > advance.</FONT></SPAN></DIV> > <P><FONT face=3DArial size=3D2>Evan Kouroupis,</FONT><FONT = > face=3DArial></FONT> <FONT=20 > face=3DArial size=3D1>MSCE + Internet, MCP, CNA</FONT><FONT=20 > face=3DArial><BR></FONT><FONT face=3DArial = > size=3D2>eko...@th...</FONT><FONT=20 > face=3DArial><BR></FONT><FONT face=3DArial = > size=3D2>www.theitpro.ca</FONT><FONT=20 > face=3DArial><BR></FONT></P> > <P><FONT face=3D"Courier New"=20 > size=3D2>----------------------------------------------------- > -----------= > ------</FONT><FONT=20 > face=3DArial><BR>Try our new PC performance enhancing and > Windows backup = > software=20 > products<BR>Immediate Delivery, order on-line! </FONT><BR><U><FONT = > face=3DArial=20 > color=3D#0000ff>www.theitpro.ca</FONT></U> </P> > <P><FONT face=3DArial>Don't get hacked, Don't go down again!</FONT> = > <BR><FONT=20 > face=3DArial>Get the HotBrick Firewall VPN Appliance</FONT> > <BR><U><FONT = > > face=3DArial > color=3D#0000ff>www.theitpro.ca/hotbrick.shtm</FONT></U> = > </P> > <P><FONT face=3DArial>Free computer tips and more...simply > sign up to = > receive our=20 > free newsletter, "eNewsPro"</FONT> <BR><FONT face=3DArial><A=20 > href=3D"http://www.theitpro.ca/">www.theitpro.ca</A> > (use the sign = > up form=20 > on the right side of our home page)</FONT> <BR><FONT face=3D"Courier = > New"=20 > size=3D2>----------------------------------------------------- > -----------= > ------</FONT><FONT=20 > face=3DArial> </FONT></P> > <DIV> </DIV></BODY></HTML> > > ------=_NextPart_000_0001_01C3D87D.F593ED90-- > > > > --__--__-- > > Message: 2 > To: Ben <be...@uk...> > cc: bac...@li... > From: cba...@us... > Subject: Re: [BackupPC-users] Query about XferLOG file > Date: Sun, 11 Jan 2004 18:17:54 -0800 > > Ben writes: > > > First, I tested a backup of a win2k machine. Fresh install, > all worked > > fine. Incrementals worked, it would only copy over changed > files, which > > was good. Then I put Active Directory on, and excluded the > c:\windows > > directory, still, backups worked fine. Then Exchange, and > still worked > > fine. Then I installed all the updates, and for some > reason, it now is > > always copying over around 90mb of files, even after doing an > > incremental straight after the previous incremental. Not > sure why, but > > in the XferLOG file, I have entires like this: > > > > create 777 65535/65535 4608 New WordPad Document.doc > > create d 550 65535/401 4096 Program Files > > create d 770 65535/401 0 Program Files/Accessories > > create d 770 65535/401 0 Program > Files/Accessories/Imagevue > > create d 770 65535/401 0 Program Files/ComPlus > Applications > > create d 770 65535/401 4096 Program Files/Common Files > > > > and on and on. Anyway, see in the log file, the first line > is "create" > > (without the 'd') - this is a new file. > > > > The rest of the files however, have the 'd' after them. > What does that > > mean? Does that mean it's copying over the file, creating them, and > > then deleting them? Because 90mb is a lot of data to copy over. On > > other files, it has 'pool' and 'same'. What do they mean? > Does anyone > > else have any problems with this, where it's copying over files that > > seem to have not of changed? > > The letter shows the type of object, similar to the first letter > of the modes displayed by ls -l: > > - d -> directory > - l -> symbolic link > - b -> block special file > - c -> character special file > - p -> pipe file (fifo) > - nothing -> regular file > > The words mean: > > - "create" -> new for this backup (ie: directory or file not in pool) > - "pool" -> found a match in the pool > - "same" -> file is identical to previous backup (contents were > checksummed and verified during full dump). > - "skip" -> file skipped in incremental because attributes are the > same (only displayed if $Conf{RsyncLogLevel} >= 2). > > As Doug noted, every incremental is level 1, meaning it dumps all > changes back to the previous full. Multi-level incrementals are > not supported, but will be in the future. Smb and tar also only > do level 1 incrementals. > > Finally, even incrementals create the full directory tree. Therefore, > you will see a lot of "create d" entries, even on an incremental that > doesn't have any changed or new files. > > > And another thing, the XferLOG and Errors files are both exactly the > > same as each other. Not sure why that's the case. > > Looks like a bug in 2.0.2. Already fixed in newest code. > > "Errors" should omit lines that start with two spaces, and all > regular file messages with Rsync should start with two spaces. > There's an extra space in the regex at line 453 of BackupPC_Admin. > I'm attaching a patch. > > Craig > > --- cgi-bin/BackupPC_Admin 2003-10-06 23:55:49.000000000 -0700 > +++ cgi-bin/BackupPC_Admin.new 2004-01-11 16:31:50.047665600 -0800 > @@ -450,7 +450,7 @@ > || /^\s*Timezone is/ > || /^\s*creating lame (up|low)case table/i > || /^\.\// > - || /^ / > + || /^ / > ) { > $skipped++; > next; > > > --__--__-- > > Message: 3 > Subject: Re: [BackupPC-users] Query about XferLOG file > From: Ben <be...@uk...> > To: bac...@li... > Date: 12 Jan 2004 13:23:52 +1100 > > > --=-TeU9VCy57uMzfqpqEuoD > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > Thanks for the reply! I am really interested in getting multilevel > increments working. Is this a big job? If not, I would be > interested to > get this working. I have limited perl experience but enough > to do a few > things. > > On Mon, 2004-01-12 at 13:17, cba...@us... wrote: > > > Ben writes: > > > > > First, I tested a backup of a win2k machine. Fresh > install, all worked > > > fine. Incrementals worked, it would only copy over > changed files, which > > > was good. Then I put Active Directory on, and excluded > the c:\windows > > > directory, still, backups worked fine. Then Exchange, and > still worked > > > fine. Then I installed all the updates, and for some > reason, it now is > > > always copying over around 90mb of files, even after doing an > > > incremental straight after the previous incremental. Not > sure why, but > > > in the XferLOG file, I have entires like this: > > > > > > create 777 65535/65535 4608 New WordPad Document.doc > > > create d 550 65535/401 4096 Program Files > > > create d 770 65535/401 0 Program Files/Accessories > > > create d 770 65535/401 0 Program > Files/Accessories/Imagevue > > > create d 770 65535/401 0 Program > Files/ComPlus Applications > > > create d 770 65535/401 4096 Program Files/Common Files > > > > > > and on and on. Anyway, see in the log file, the first > line is "create" > > > (without the 'd') - this is a new file. > > > > > > The rest of the files however, have the 'd' after them. > What does that > > > mean? Does that mean it's copying over the file, creating > them, and > > > then deleting them? Because 90mb is a lot of data to copy over. On > > > other files, it has 'pool' and 'same'. What do they mean? > Does anyone > > > else have any problems with this, where it's copying over > files that > > > seem to have not of changed? > > > > The letter shows the type of object, similar to the first letter > > of the modes displayed by ls -l: > > > > - d -> directory > > - l -> symbolic link > > - b -> block special file > > - c -> character special file > > - p -> pipe file (fifo) > > - nothing -> regular file > > > > The words mean: > > > > - "create" -> new for this backup (ie: directory or file > not in pool) > > - "pool" -> found a match in the pool > > - "same" -> file is identical to previous backup (contents were > > checksummed and verified during full dump). > > - "skip" -> file skipped in incremental because > attributes are the > > same (only displayed if $Conf{RsyncLogLevel} >= 2). > > > > As Doug noted, every incremental is level 1, meaning it dumps all > > changes back to the previous full. Multi-level incrementals are > > not supported, but will be in the future. Smb and tar also only > > do level 1 incrementals. > > > > Finally, even incrementals create the full directory tree. > Therefore, > > you will see a lot of "create d" entries, even on an > incremental that > > doesn't have any changed or new files. > > > > > And another thing, the XferLOG and Errors files are both > exactly the > > > same as each other. Not sure why that's the case. > > > > Looks like a bug in 2.0.2. Already fixed in newest code. > > > > "Errors" should omit lines that start with two spaces, and all > > regular file messages with Rsync should start with two spaces. > > There's an extra space in the regex at line 453 of BackupPC_Admin. > > I'm attaching a patch. > > > > Craig > > > > --- cgi-bin/BackupPC_Admin 2003-10-06 23:55:49.000000000 -0700 > > +++ cgi-bin/BackupPC_Admin.new 2004-01-11 16:31:50.047665600 -0800 > > @@ -450,7 +450,7 @@ > > || /^\s*Timezone is/ > > || /^\s*creating lame (up|low)case table/i > > || /^\.\// > > - || /^ / > > + || /^ / > > ) { > > $skipped++; > > next; > > --=-TeU9VCy57uMzfqpqEuoD > Content-Type: text/html; charset=utf-8 > Content-Transfer-Encoding: 7bit > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> > <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.7"> > </HEAD> > <BODY> > Thanks for the reply! I am really interested in getting > multilevel increments working. Is this a big job? If not, I > would be interested to get this working. I have limited perl > experience but enough to do a few things.<BR> > <BR> > On Mon, 2004-01-12 at 13:17, cba...@us... wrote: > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I>Ben writes: > > > First, I tested a backup of a win2k machine. Fresh > install, all worked > > fine. Incrementals worked, it would only copy over > changed files, which > > was good. Then I put Active Directory on, and excluded > the c:\windows > > directory, still, backups worked fine. Then Exchange, > and still worked > > fine. Then I installed all the updates, and for some > reason, it now is > > always copying over around 90mb of files, even after doing an > > incremental straight after the previous incremental. Not > sure why, but > > in the XferLOG file, I have entires like this: > > > > create 777 65535/65535 4608 New WordPad Document.doc > > create d 550 65535/401 4096 Program Files > > create d 770 65535/401 0 Program Files/Accessories > > create d 770 65535/401 0 Program > Files/Accessories/Imagevue > > create d 770 65535/401 0 Program > Files/ComPlus Applications > > create d 770 65535/401 4096 Program Files/Common Files > > > > and on and on. Anyway, see in the log file, the first > line is "create" > > (without the 'd') - this is a new file. > > > > The rest of the files however, have the 'd' after them. > What does that > > mean? Does that mean it's copying over the file, > creating them, and > > then deleting them? Because 90mb is a lot of data to > copy over. On > > other files, it has 'pool' and 'same'. What do they > mean? Does anyone > > else have any problems with this, where it's copying > over files that > > seem to have not of changed? > > The letter shows the type of object, similar to the first letter > of the modes displayed by ls -l: > > - d -> directory > - l -> symbolic link > - b -> block special file > - c -> character special file > - p -> pipe file (fifo) > - nothing -> regular file > > The words mean: > > - "create" -> new for this backup (ie: > directory or file not in pool) > - "pool" -> found a match in the pool > - "same" -> file is identical to previous > backup (contents were > checksummed and verified during full dump). > - "skip" -> file skipped in incremental > because attributes are the > same (only displayed if $Conf{RsyncLogLevel} >= 2). > > As Doug noted, every incremental is level 1, meaning it dumps all > changes back to the previous full. Multi-level incrementals are > not supported, but will be in the future. Smb and tar also only > do level 1 incrementals. > > Finally, even incrementals create the full directory tree. Therefore, > you will see a lot of "create d" entries, even on > an incremental that > doesn't have any changed or new files. > > > And another thing, the XferLOG and Errors files are both > exactly the > > same as each other. Not sure why that's the case. > > Looks like a bug in 2.0.2. Already fixed in newest code. > > "Errors" should omit lines that start with two > spaces, and all > regular file messages with Rsync should start with two spaces. > There's an extra space in the regex at line 453 of BackupPC_Admin. > I'm attaching a patch. > > Craig > > --- cgi-bin/BackupPC_Admin 2003-10-06 23:55:49.000000000 -0700 > +++ cgi-bin/BackupPC_Admin.new 2004-01-11 16:31:50.047665600 -0800 > @@ -450,7 +450,7 @@ > || /^\s*Timezone is/ > || /^\s*creating lame (up|low)case table/i > || /^\.\// > - || /^ / > + || /^ / > ) { > $skipped++; > &n > bsp; > next;</I></FONT></PRE> > </BLOCKQUOTE> > </BODY> > </HTML> > > --=-TeU9VCy57uMzfqpqEuoD-- > > > > --__--__-- > > Message: 4 > To: Ben <be...@uk...> > cc: bac...@li... > From: cba...@us... > Subject: Re: [BackupPC-users] Query about XferLOG file > Date: Sun, 11 Jan 2004 18:30:21 -0800 > > Ben writes: > > > Hmm that's what I thought. Think it would be hard to write this into > > BackupPC? I know a bit of perl, I wonder what would be > involved. I guess > > the way it does it now, is that when an incremental is > done, it checks > > the filelist of the full backup and goes ahead and copies > the changed > > files. If that is true, then theoretically, it wouldn't be > that hard to > > make it so that incremental files are added to the full backup file > > list. Of course, just theory. > > Some pieces are already done for the next version. The code for > browsing, restoring, creating zip/tar files etc is now capable > of merging multi-level incrementals (ie: instead of merging one > incr with one full, you now might need to merge multiple incrs, > and then the full). > > The main remaining step is to actually make the dumps multi-level > (need some config parameter for specifying that). That's not too > hard, but will need a good deal of testing. > > Finally, your case of wanting only incrementals would mean that the > last full backup would never be deleted (you would always have to > keep the full). To fix that, I would probably change the deletion > policy so that fulls will get deleted (even if needed for folling > incrs), but the dependent incrs (typically the next one) would be > "filled in" from the full before the full is deleted. This part > would take a decent development effort. > > BTW, remember that a full dump with rsync doesn't require all the > file contents to be transferred. Just block checksums for the > contents are sent (approx 1/300 the amount of data). So a full > dump with rsync is not too onerous in terms of network traffic. > > > On Mon, 2004-01-12 at 11:25, Doug Lytle wrote: > > > > > I don't know. Craig has been quite busy, so I doubt it > would be any > > > time soon. > > You got that!! > > Craig > > > --__--__-- > > Message: 5 > Subject: Re: [BackupPC-users] Query about XferLOG file > From: Ben <be...@uk...> > To: bac...@li... > Date: 12 Jan 2004 13:57:38 +1100 > > > --=-AIimcXFjDPxcilYy5CU0 > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > > Some pieces are already done for the next version. The code for > > browsing, restoring, creating zip/tar files etc is now capable > > of merging multi-level incrementals (ie: instead of merging one > > incr with one full, you now might need to merge multiple incrs, > > and then the full). > > > > The main remaining step is to actually make the dumps multi-level > > (need some config parameter for specifying that). That's not too > > hard, but will need a good deal of testing. > > > Not too hard? Alright I might take a look and see if I can figure this > out but I doubt I will be able to do it, still, worth a try. > > > > > > Finally, your case of wanting only incrementals would mean that the > > last full backup would never be deleted (you would always have to > > keep the full). To fix that, I would probably change the deletion > > policy so that fulls will get deleted (even if needed for folling > > incrs), but the dependent incrs (typically the next one) would be > > "filled in" from the full before the full is deleted. This part > > would take a decent development effort. > > > > > Yeah that's right, just keep the last full backup and then rest are > incrementals. > > > > BTW, remember that a full dump with rsync doesn't require all the > > file contents to be transferred. Just block checksums for the > > contents are sent (approx 1/300 the amount of data). So a full > > dump with rsync is not too onerous in terms of network traffic. > > > Ah, I didn't relise that, I thought that all data gets > transferred in a > full dump. That's just with rsync is it? > > > > > > On Mon, 2004-01-12 at 11:25, Doug Lytle wrote: > > > > > > > I don't know. Craig has been quite busy, so I doubt it > would be any > > > > time soon. > > > > You got that!! > > > I know hehe > > > > > > Craig > > --=-AIimcXFjDPxcilYy5CU0 > Content-Type: text/html; charset=utf-8 > Content-Transfer-Encoding: 7bit > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> > <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.7"> > </HEAD> > <BODY> > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I>Some pieces are already done > for the next version. The code for > browsing, restoring, creating zip/tar files etc is now capable > of merging multi-level incrementals (ie: instead of merging one > incr with one full, you now might need to merge multiple incrs, > and then the full). > > The main remaining step is to actually make the dumps multi-level > (need some config parameter for specifying that). That's not too > hard, but will need a good deal of testing.</I></FONT></PRE> > </BLOCKQUOTE> > <BR> > Not too hard? Alright I might take a look and see if I can > figure this out but I doubt I will be able to do it, still, > worth a try.<BR> > <BR> > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I> > Finally, your case of wanting only incrementals would mean that the > last full backup would never be deleted (you would always have to > keep the full). To fix that, I would probably change the deletion > policy so that fulls will get deleted (even if needed for folling > incrs), but the dependent incrs (typically the next one) would be > "filled in" from the full before the full is > deleted. This part > would take a decent development effort. > </I></FONT></PRE> > </BLOCKQUOTE> > <BR> > Yeah that's right, just keep the last full backup and then > rest are incrementals.<BR> > <BR> > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I>BTW, remember that a full dump > with rsync doesn't require all the > file contents to be transferred. Just block checksums for the > contents are sent (approx 1/300 the amount of data). So a full > dump with rsync is not too onerous in terms of network > traffic.</I></FONT></PRE> > </BLOCKQUOTE> > <BR> > Ah, I didn't relise that, I thought that all data gets > transferred in a full dump. That's just with rsync is it? > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I> > > On Mon, 2004-01-12 at 11:25, Doug Lytle wrote: > > > > > I don't know. Craig has been quite busy, so I > doubt it would be any > > > time soon. > > You got that!!</I></FONT></PRE> > </BLOCKQUOTE> > <BR> > I know hehe<BR> > <BR> > <BLOCKQUOTE TYPE=CITE> > <PRE><FONT COLOR="#737373"><I> > Craig</I></FONT></PRE> > </BLOCKQUOTE> > </BODY> > </HTML> > > --=-AIimcXFjDPxcilYy5CU0-- > > > > > --__--__-- > > _______________________________________________ > BackupPC-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/backuppc-users > > > End of BackupPC-users Digest |