sendsize - smbclient du
I have amanda 2.4.5 install on a FC4 machine. I plan to use this machine to backup several Windows 2K and XP machines. It is replacing a machine that is running amanda 2.4.4 running on FC2. The new machine has smbclient 3.0.14a-2, while the old has 3.0.10-1.fc2. I have not been able to get the new machine to backup a windows machine yet. It seems to hang while getting the estimates. So, I tried to issue the du command from the smb prompt after I connected to a share. du seems to take forever. After 10 minutes, it has not timed out. I searched the samba site and google for issues with du in the smbclient, and found nothing. Have others run into this problem? Clearly, it is not and amanda issue, but I thought this group might be able to provide some useful information. I built amanda from source, but I installed samba from rpm. Thanks
Re: Fedora upgrade Amanda slowed
> On Fri, Oct 29, 2004 at 07:57:58AM -0400, Jonathan Swaby wrote: > I > recently upgraded a RH9 box to Fedora Core1. The upgrade went fine, > > but my Amanda backups have slowed down a great deal. I am using > this > machine to backup a Win2k server, a Win2k3 server, and a > couple of > Linux boxes. The backups for the Linux boxes are running > at the same > pace as always, but my win boxes are extremely > slow. My Win2k box was > taking an hour and it now take 3.5 > hours. My Win2k3 box was taking 16 > minutes and now takes 1.25 > hours. Several of the packages Amanda uses > were upgraded in the > process. I am, however, still using Amanda 2.4.4. > Maybe a new > network driver? Check that your network connection still works as > previously. Does it still "handshake" properly, get the right > speed, right duplex, ... This appears to have been the problem. The 3c59x driver in FC1 on my Dell was the problem. The solution was odd. I found it in a bug report. The ethernet connection was working, but had a ton of collisions and receive errors. Following the suggestion in the bug report, I turned kudzu off and reboot the machine. No collisions, and no errors. Backup times are back to where they were. Thank you for your suggestion. Thanks Jonathan Swaby > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) >
Re: Fedora upgrade Amanda slowed
> > Hi, Gavin, > > on Freitag, 29. Oktober 2004 at 14:24 you wrote to amanda-users: > > GH> Hi, I'm http://FedoraNEWS.ORG/ghenry, so I like to think I know a bit > GH> about Fedora :-) > > GH> IIRC, from RH9 to FC1 the file protocol changed from smbfs to cifs, and > GH> all sorts of problems started to happen with samba. > > cifs and smbfs are filesystems (in fact kernel-modules), they are not > used by smbclient, which is used by AMANDA. > > These would only affect you if you mount Windows-shares via smbfs or > cifs and dump them via dump or tar. > Just using smbclient. > GH> I would upgrade to FC2 if at all possible. > > Without further knowledge I would also think this. Yeap, this is part of the plan. > > Jonathan, has anything changed in the smb.conf of that machine? > Maybe the update-procedure has modified this file. > Nope, the file appears to be unchanged. > Also the contents of /var/log/samba might tell you more. Nothing in the log. I assume this is because I am not starting smbd. I have tried to force smbclient to use port 139, but that does not seem to be the answer either. In googling a bit more, I ran into a thread or two that stated that port 445 transactions are slower than using 139. As I said, this did not help. Hopefully, I will get a chance to upgrade to FC2 on Monday. Thanks Jonathan Swaby
Fedora upgrade Amanda slowed
I recently upgraded a RH9 box to Fedora Core1. The upgrade went fine, but my Amanda backups have slowed down a great deal. I am using this machine to backup a Win2k server, a Win2k3 server, and a couple of Linux boxes. The backups for the Linux boxes are running at the same pace as always, but my win boxes are extremely slow. My Win2k box was taking an hour and it now take 3.5 hours. My Win2k3 box was taking 16 minutes and now takes 1.25 hours. Several of the packages Amanda uses were upgraded in the process. I am, however, still using Amanda 2.4.4. gtar 1.13.25 gzip 1.3.3 smbclient 3.0.7-2.FC1 Before the upgrade, I had gtar 1.13.25-11 gzip 1.3.3-9 smbclient 3.0.5 I have not yet tried down grading to smbclient 3.0.5. This might fix the problem. I have googled for possible answers, but I have found nothing. Has anyone else experienced this? Does anyone have any ideas on how to solve the problem? Thanks Jonathan Swaby
no backup size line SAMBA 3.0
I am getting a report from Amanda version 2.4.4p1-20031031 that
basically says that my backup failed. The Amanda server is a RH 7.2
box with SAMBA 3.0 installed. I needed SAMBA 3.0 in order to backup a
Win2k3 server with Active Directory. The backup was actually
performed. All of the files were backed up. I get the same report for
a Win NT 4.0 server as well. It is not a major issue as the backup is
working, and I can tell from one of the lines in the report that data
actually was backed up, but it would be nice if the report worked like
it did in the past. I have read about needing a patch for SAMBA and I
have read about needing a patch for Amanda. Since I have the lastest
snapshot of Amanda that should work with SAMBA 3.0, do I still need to
patch SAMBA? Has anyone else run into this quirk?
Below is a report from my NT 4.0 server. The tape size and runtime
would indicate that the backup was a success.
FAILURE AND STRANGE DUMP SUMMARY:
tempsrv//nt4server/doc$ lev 0 FAILED [no backup size line]
tempsrv//nt4server/doc$ lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 1:09
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)1:09 1:09 0:00
Tape Size (meg) 405.6 405.60.0
Tape Used (%) 1.01.00.0
Filesystems Taped 1 1 0
Avg Tp Write Rate (k/s) 100.1 100.1--
USAGE BY TAPE:
Label Time Size %Nb
nt4server01 1:09 405.61.0 1
FAILED AND STRANGE DUMP DETAILS:
/-- tempsrv//nt4server/doc$ lev 0 FAILED [no backup size line]
sendbackup: start [tempsrv://nt4server/doc$ level 0]
sendbackup: info BACKUP=/usr/bin/smbclient
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/smbclient -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| session request to nt4server failed (Called name not present)
| session request to 130 failed (Called name not present)
? [2003/11/04 07:43:02, 0] client/clitar.c:do_atar(710)
? File size change - truncating \data\error-log.Nov042003 to 2978 bytes
? [2003/11/04 07:52:10, 0] client/clitar.c:do_atar(710)
? File size change - truncating \data\referer-log.Nov042003 to 5692 bytes
? [2003/11/04 08:10:29, 0] client/clitar.c:process_tar(1433)
? tar: dumped 9456 files and directories
? [2003/11/04 08:10:29, 0] client/clitar.c:process_tar(1434)
? Total bytes written: 2408814080
sendbackup: error [no backup size line]
\
NOTES:
planner: tapecycle (1) <= runspercycle (28)
planner: Last full dump of tempsrv://nt4server/doc$ on tape overwritten in 1 run.
taper: tape nt4server01 kb 415392 fm 1 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
tempsrv -2.218/doc$ 0 FAILED ---
(brought to you by Amanda version 2.4.4p1-20031031)
multiple ethernet cards
Is it possible to run two amanda jobs at the same time on different ethernet cards. I have a machine that I am planning to use to backup my Win2k users. The data will be backed up to one of two partitions. Would it be possible to run Amanda jobs on different ethernet cards that backup to different partitions? Some users will back up to bk0 via eth0 and others will back up to bk1 via eth1. I am asking the question because I thought that I had read some place that you can ony run one Amanda job at a time. I was wondering if different interfaces and backing up to HD might solve the problem.
Re: Problem: Failed backups overwrite good backups
> > On Tue, Mar 11, 2003 at 01:35:48PM -0500, Jonathan Swaby wrote: > > > > > > On Tue, Mar 11, 2003 at 09:15:10AM -0500, Jonathan Swaby wrote: > > > > > > > > I am using Amanda 2.4.3b3 on a Linux RH 7.2 box to dump several > > > > windows clients to disk. I discovered a problem yesterday with my > > > > process. I run all of the backup jobs from a script. Each backup is a > > > > full backup. When one job completes, the next job runs. This all works > > > > correctly if the backup server is able to access the machine. If it is > > > > not able to connect to the machine, prehaps the machine is off, the > > > > existing backup files are overwritten. Does anyone know of a way to > > > > prevent this from happening? If it fails, I want it to leave the > > > > existing backup files. > > > > > > Which files are overwritten? > > > Is it the files in holding disk? that's normal if you run more than > > > one amdump by day for the same disk. > > Essentially it is overwritting the tape. In my case the tape is a > > directory on disk. I assumed it would only do this if it had data to > > write, but that does not appear to be the case. > > It's a tape, it is overwritten at every run, that's the way it works, > that's the way it should works (like a tape). I thought that it would erase the file only if it had something to write. It seems that it erases then checks to see if there is something to write. In any event my problem is solve I think. I wrote a small "C" program that takes its input from amcheck. If it sees the word ERROR or WARNING, it will return a value of 10. If amcheck works, it will return a value of 0. So, my script looks like this: su -c "amcheck amachine1 | backup_test" operator && su -c "amdump machine1" operator If backup_test returns a "0", it will do the dump. Thanks Jonathan Swaby > > Jean-Louis > -- > Jean-Louis Martineau email: [EMAIL PROTECTED] > Departement IRO, Universite de Montreal > C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 > Montreal, Canada, H3C 3J7Fax: (514) 343-5834 >
Re: Problem: Failed backups overwrite good backups
> > On Tue, Mar 11, 2003 at 09:15:10AM -0500, Jonathan Swaby wrote: > > > > I am using Amanda 2.4.3b3 on a Linux RH 7.2 box to dump several > > windows clients to disk. I discovered a problem yesterday with my > > process. I run all of the backup jobs from a script. Each backup is a > > full backup. When one job completes, the next job runs. This all works > > correctly if the backup server is able to access the machine. If it is > > not able to connect to the machine, prehaps the machine is off, the > > existing backup files are overwritten. Does anyone know of a way to > > prevent this from happening? If it fails, I want it to leave the > > existing backup files. > > Others may have additional ideas, but what about not having a tape available > and only backing up to the holding disk. Then once (or thrice) a day > run amdump to collect the held backups. IIRC amdump only uses a tape if > it first determines there are directories to flush. I will look into this thanks. My programming skills are not great, but the idea I have been toying with is to use the output of amcheck to determine whether or not to proceed with the backup. Now my backup script looks like this: su -c "amdump machine1" operator su -c "amdump machine2" operator If I can figure out how to do what I want it might look lie this: returncode = someprogram machine1 if (returcode==0) su -c "amdump machine1" operator Ideally "someprogram" would take the output from amcheck and scan it for errors or warnings like time-out and return value indicating whether or not to proceed with the backup. > > > The dumpcycles are set to 0 and the number of tapes is 1. I am just > > getting the system going, and I did not have a good feel for how much > > drive space was going to be consummed by the backups. > > > > If any one cares, this is how the system works. > > It is amazing how flexible the amanda system can be. > > The above arrangement (flush separately from dumps) might also let you > have the users select a time to backup as your scheme "tried" to do. > My users do not want the responsibility of having to backup their own data. I guess more importantly, my boss suggested that I not give them this responiblity. Thanks Jonathan Swaby > [[ interesting scheme snipped ]] > > jl > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) >
Re: Problem: Failed backups overwrite good backups
> > On Tue, Mar 11, 2003 at 09:15:10AM -0500, Jonathan Swaby wrote: > > > > I am using Amanda 2.4.3b3 on a Linux RH 7.2 box to dump several > > windows clients to disk. I discovered a problem yesterday with my > > process. I run all of the backup jobs from a script. Each backup is a > > full backup. When one job completes, the next job runs. This all works > > correctly if the backup server is able to access the machine. If it is > > not able to connect to the machine, prehaps the machine is off, the > > existing backup files are overwritten. Does anyone know of a way to > > prevent this from happening? If it fails, I want it to leave the > > existing backup files. > > Which files are overwritten? > Is it the files in holding disk? that's normal if you run more than > one amdump by day for the same disk. Essentially it is overwritting the tape. In my case the tape is a directory on disk. I assumed it would only do this if it had data to write, but that does not appear to be the case. > > Jean-Louis > -- > Jean-Louis Martineau email: [EMAIL PROTECTED] > Departement IRO, Universite de Montreal > C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 > Montreal, Canada, H3C 3J7Fax: (514) 343-5834 >
Problem: Failed backups overwrite good backups
I am using Amanda 2.4.3b3 on a Linux RH 7.2 box to dump several windows clients to disk. I discovered a problem yesterday with my process. I run all of the backup jobs from a script. Each backup is a full backup. When one job completes, the next job runs. This all works correctly if the backup server is able to access the machine. If it is not able to connect to the machine, prehaps the machine is off, the existing backup files are overwritten. Does anyone know of a way to prevent this from happening? If it fails, I want it to leave the existing backup files. The dumpcycles are set to 0 and the number of tapes is 1. I am just getting the system going, and I did not have a good feel for how much drive space was going to be consummed by the backups. If any one cares, this is how the system works. I created a couple of web pages to allow the user to add their machines to the backup list. The web pages are restricted via ip address. The user is informed that this is experimental and that they should also backup their data to zip disk or cd. The user is also instructed to contact the support person to make changes to the computers to allow the backups to happen. We only backup "My Documents" and Eudora. The users enters some basic information into a form and some information like IP address is collected behind the scenes. The data from the form is added to a mysql database. Initially, my plan was to have the users submit a date and time to run the backup. The users did not like this idea. I guess too much work for them. Good thing I guess, as I read some time there after that I could not run concurrent amdump jobs. I wrote a "C" program to construct everything else. Before doing this, I had to construct some template files for amanda.conf, changer.conf, and the disklist. I use sed to create the useable files. Anyways, the program checks for any new additions to the list. I have 2 servers to backup 80 machines in 5 different buildings. Each server runs the program and only looks for certain subnets. If a new machine has been added, it creates all of the directories, files, and tapes. Next the program looks through the list for its machines and creates a shell script to perform the backups and uses "at" to schedule the script. As I said this al works fine. The only problems I have run into have been with ZoneAlarm and the users PC not being set up correctly. Thanks Jonathan Swaby
