I had originally written about this problem last month (http://lists.samba.org/pipermail/samba/2002-November/085418.html) Since then, our company has added another Windows Fileserver which I'm trying to back up, and they are both having the problem. Because it happens on both servers, this leads me to believe it really is a problem with my Samba server. I've upgraded to 2.2.7a, as the changelog said that that release fixed some problems with large file support, but no-luck. I could try splitting the file into pieces on the Windows server, but that is kludgy. If anyone can help me get this solved, I'd be forever appreciative.. I'll do whatever I need to. If I need to go to the 3.0 version, I guess I can, but I'm wary of stability.. Colin Davis Former message attached------ I'm trying to back-up a set of windows machines onto a single Linux machine, so that I can easily make a tape from there. The Linux Machine (RedHat 7.3, running samba 2.2.6), is set to use mount.smbfs to log in to each machine's Administrative share, and copy several files from the hard drive. One machine is giving me a great deal of difficulty, however. Our last remaining window's fileserver (the rest have been converted), makes a backup of it'self every night, and stores it on the F: drive. This is easily completed in an hour or so. On the Linux machine, it is set to try to log in to the fileserver, and copy the file, every morning at 11:30am. The file (FullBackup.bcf) is 7.1 gig on the windows machine, but, left to it's own devices, Samba never stops copying it.. The file grows until it fills the entire filesystem! mkdir /mnt/bkp/BackupServer >> /etc/sambalog 2>&1=20 mkdir /mnt/bkp/BackupServer/BackupDir >> \etc\sambalog 2>&1 cp -R -u /mnt/smb/folder /mnt/bkp/BackupServer/BackupDir=20 Does anyone have any suggestions to why this might be happening? I'm really at a loss.. It happens no matter what filesystem I give the destination disk, so I think it must be an issue during the copy.. Colin
AFAIK smbfs does not have large file support (at least not full support). You could try smbtar with the patch that was posted to this list for fixing large file support in that. Colin Davis wrote:> > I had originally written about this problem last month > (http://lists.samba.org/pipermail/samba/2002-November/085418.html) > > Since then, our company has added another Windows Fileserver which I'm > trying to back up, and they are both having the problem. Because it > happens on both servers, this leads me to believe it really is a problem > with my Samba server. > > I've upgraded to 2.2.7a, as the changelog said that that release fixed > some problems with large file support, but no-luck. > > I could try splitting the file into pieces on the Windows server, but > that is kludgy. > > If anyone can help me get this solved, I'd be forever appreciative.. > I'll do whatever I need to. If I need to go to the 3.0 version, I guess > I can, but I'm wary of stability.. > > Colin Davis > > Former message attached------ > I'm trying to back-up a set of windows machines onto a single Linux > machine, so that I can easily make a tape from there. > > The Linux Machine (RedHat 7.3, running samba 2.2.6), is set to use > mount.smbfs to log in to each machine's Administrative share, and copy > several files from the hard drive. > > One machine is giving me a great deal of difficulty, however. > Our last remaining window's fileserver (the rest have been converted), > makes a backup of it'self every night, and stores it on the F: drive. > This is easily completed in an hour or so. > > On the Linux machine, it is set to try to log in to the fileserver, and > copy the file, every morning at 11:30am. The file (FullBackup.bcf) is > 7.1 gig on the windows machine, but, left to it's own devices, Samba > never stops copying it.. The file grows until it fills the entire > filesystem! > > mkdir /mnt/bkp/BackupServer >> /etc/sambalog 2>&1=20 > mkdir /mnt/bkp/BackupServer/BackupDir >> \etc\sambalog 2>&1 > cp -R -u /mnt/smb/folder /mnt/bkp/BackupServer/BackupDir=20 > > Does anyone have any suggestions to why this might be happening? > I'm really at a loss.. It happens no matter what filesystem I give the > destination disk, so I think it must be an issue during the copy.. > > Colin > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba-- =====================================================================Herb Lewis Silicon Graphics Networking Engineer 1600 Amphitheatre Pkwy MS-510 Strategic Software Organization Mountain View, CA 94043-1351 herb@sgi.com Tel: 650-933-2177 http://www.sgi.com Fax: 650-932-2177 PGP Key: 0x8408D65D ======================================================================
Thank you for the suggestion. I've been looking at SMBTAR, but I don't see a way to specify specific directories to back up with it, only entire shares. For example, if I wanted to backup the "h:\stuff goes here" , by logging into the "h$" Administrative share. Is there a way to do this with SMBTAR? I'd also love to know if there is a patch anywhere to fix smbfs, or what I should do. Would using smbclient work better? I appreciate your help, Colin -----Original Message----- From: Herb Lewis [mailto:herb@sgi.com] Sent: Tuesday, December 17, 2002 10:09 AM To: Colin Davis Cc: samba@lists.samba.org Subject: Re: [Samba] Still having trouble with copying large files AFAIK smbfs does not have large file support (at least not full support). You could try smbtar with the patch that was posted to this list for fixing large file support in that. Colin Davis wrote:> > I had originally written about this problem last month > (http://lists.samba.org/pipermail/samba/2002-November/085418.html) > > Since then, our company has added another Windows Fileserver which I'm > trying to back up, and they are both having the problem. Because it > happens on both servers, this leads me to believe it really is aproblem> with my Samba server. > > I've upgraded to 2.2.7a, as the changelog said that that release fixed > some problems with large file support, but no-luck. > > I could try splitting the file into pieces on the Windows server, but > that is kludgy. > > If anyone can help me get this solved, I'd be forever appreciative.. > I'll do whatever I need to. If I need to go to the 3.0 version, Iguess> I can, but I'm wary of stability.. > > Colin Davis > > Former message attached------ > I'm trying to back-up a set of windows machines onto a single Linux > machine, so that I can easily make a tape from there. > > The Linux Machine (RedHat 7.3, running samba 2.2.6), is set to use > mount.smbfs to log in to each machine's Administrative share, and copy > several files from the hard drive. > > One machine is giving me a great deal of difficulty, however. > Our last remaining window's fileserver (the rest have been converted), > makes a backup of it'self every night, and stores it on the F: drive. > This is easily completed in an hour or so. > > On the Linux machine, it is set to try to log in to the fileserver,and> copy the file, every morning at 11:30am. The file (FullBackup.bcf) is > 7.1 gig on the windows machine, but, left to it's own devices, Samba > never stops copying it.. The file grows until it fills the entire > filesystem! > > mkdir /mnt/bkp/BackupServer >> /etc/sambalog 2>&1=20 > mkdir /mnt/bkp/BackupServer/BackupDir >> \etc\sambalog 2>&1 > cp -R -u /mnt/smb/folder /mnt/bkp/BackupServer/BackupDir=20 > > Does anyone have any suggestions to why this might be happening? > I'm really at a loss.. It happens no matter what filesystem I give the > destination disk, so I think it must be an issue during the copy.. > > Colin > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba-- =====================================================================Herb Lewis Silicon Graphics Networking Engineer 1600 Amphitheatre Pkwy MS-510 Strategic Software Organization Mountain View, CA 94043-1351 herb@sgi.com Tel: 650-933-2177 http://www.sgi.com Fax: 650-932-2177 PGP Key: 0x8408D65D ======================================================================