Re: Wrong amadmin reports and missing data
> On 2006-03-09 18:14, Iulian Topliceanu wrote: Paul Bijnens wrote: >>> Do you have runtapes > 1 ? >>> Or do you run amdump multiple times a day? >> >> Amanda uses sometime more than 1 tape per run. That's why vtape-7 was >> again next. So even if I would have defined runtapes 1, Amanda would >> have >> used more. > > AFAI have seen Amanda never uses more (v)tapes than the number specified > by "runtapes" (which defaults to 1). > > I think something else is going wrong here... > Can you send the complete amanda.conf to me? > Are you sure there is only one config running? I did some thinking and the only explanation for amadmin to report wrong information on vtape-7 is the lack holdingdisk space. Paul, as you can see in my amanda.conf, no holdingdisk is defined. I hadn't that much space for the vtapes, and considered it to be useless since I'm using vtapes and they're as fast as the HDD. Amanda is writing the information directly to tape, and when it comes to the end of the tape, it sees that there is no more space left on the device so the DLE can't be dumped on tape entirely but it has already overwritten the information on vtape-7. The reason why Amanda estimate didn't notice that the dump is too big to fit on the tape is that the vtape is 30 GB big, and /data/data0/share1 is 33 GB big. Is this a valid explanation? I still have no clue about the missing files in the incremental dump. How could that be possible? Is it because of network problems? (knowing that Amanda is using an UDP stream) The level 0 dump from a single machine (should be a cluster bun one machine is almost always not working) ~300 GB. Iulian Topliceanu
Re: Odd amrecover and amverify issue in 2.5.0b2
Ian Turner wrote: That is very fascinating. I don't think it is a tar problem, but the nature of the problem is not immediately obvious to me. Perhaps you can do the following: 1) Remove /tmp/amanda 2) Run amrecover (on the server) 3) Attach all the files in /tmp/amanda. It shouldn't be big, but if it is, then don't send it the list, just post it on the web or send it to me personally. Cheers, --Ian Sorry for the delay. I have done as you suggested and included the output of the amverify command. Also, I don't know if it makes a difference, but I should mention that I am running on AIX. Thanks! Output files: ammt.out: This file is empty amrestore.out: amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information amtape.out: changer: got exit: 0 str: 1 file:/u01/vtapes/gemini amtape: changed to slot 1 on file:/u01/vtapes/gemini defects: gemini-01 (): amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: reached end of information ** No header 0+0 in 0+0 out gemini-01 (): amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information ** No header 0+0 in 0+0 out gemini-01 (): amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information ** No header 0+0 in 0+0 out gemini-01 (): amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information ** No header 0+0 in 0+0 out gemini-01 (): amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information ** No header 0+0 in 0+0 out gemini-01 (): amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file h
Re: Wrong amadmin reports and missing data
On Thursday 09 March 2006 12:14, Iulian Topliceanu wrote: >> On 2006-03-09 17:19, Iulian Topliceanu wrote: >>> Paul Bijnens wrote: On 2006-03-09 13:25, Iulian Topliceanu wrote: > The dump definition looks like this: > > dumpcycle 10 day# the number of days in the normal dump > cycle runspercycle 8 day# the number of amdump runs in > dumpcycle days tapecycle 12 tapes # the number of tapes in > rotation seems fine. >>> >>> Amanda reported that the dumps where successfully to tape vtape-7, >>> but taking a simple look to what that vtape-7 contained (using ls), >>> has proved >>> the opposite, there was no sign of /var/spool/mail/p (and the other >>> DLE's >>> which had the same problem) on vtape-7. >>> >>> vtape-7 contained /data/data0/share1 (directory, which I said >>> above, was >>> reported not to be backuped successfully) >>> >>> I should mention that these this didn't occure on the same run. My >>> guess is that Amanda backuped successfully /var/spool/mail/p (and >>> the other DLE's) on the 24.02 and wrote them to vtape-7, but on the >>> 2.03 when this error occured: >>> >>> baal /data/data0/share1 lev 0 FAILED [dump larger than tape, >>> 31665455 KB, >>> incremental dump also larger than tape] >>> >>> The dumps where written again on vtape-7, so that's the reason why >>> /data/data0/share1 appears to pe on vtape-7 instead of >>> /var/spool/mail/p (and the other DLE's) >> >> [...] >> >>> I've noticed that 12 vtapes where used in less than 10 days (the >>> dumpcycle >>> = 10 days) but is that an excuse for missing data? >> >> Again on vtape-7 ??? How is that possible? >> Do you have runtapes > 1 ? >> Or do you run amdump multiple times a day? > >Amanda uses sometime more than 1 tape per run. That's why vtape-7 was >again next. So even if I would have defined runtapes 1, Amanda would > have used more. > If you've got runtapes=1, and it still uses more, I'd say that installation is hosed, possbly even confused as to where its .conf file is. Have you perchance done a reinstall somewhere along the line? >> Any idea why amadmin still believes that vtape-7 contains the data >> from feb 24, and not data from mar 2 ? > >This is what I'm trying to find out. and I have no logical explanation > yet. > >>>Level 1 dump didn't contain *all* of the expected files. Some of the >>> mails received during the level 0 dump and level 1 dump, where not >>> present. >>> >>>I should add that the volume /var/spool/mail (which is split in >>>/var/spool/mail/[a-z]) is 130 GB big and has ~7 million inodes. > >What about the missing files? Does anyone have a clue about how > something like this is possible? Is it because of the huge number of > inodes on the fs? > >Iulian Topliceanu -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: Wrong amadmin reports and missing data
On 2006-03-09 18:14, Iulian Topliceanu wrote: Paul Bijnens wrote: Do you have runtapes > 1 ? Or do you run amdump multiple times a day? Amanda uses sometime more than 1 tape per run. That's why vtape-7 was again next. So even if I would have defined runtapes 1, Amanda would have used more. AFAI have seen Amanda never uses more (v)tapes than the number specified by "runtapes" (which defaults to 1). I think something else is going wrong here... Can you send the complete amanda.conf to me? Are you sure there is only one config running? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Wrong amadmin reports and missing data
> On 2006-03-09 17:19, Iulian Topliceanu wrote: >> Paul Bijnens wrote: >>> On 2006-03-09 13:25, Iulian Topliceanu wrote: The dump definition looks like this: dumpcycle 10 day# the number of days in the normal dump cycle runspercycle 8 day# the number of amdump runs in dumpcycle days tapecycle 12 tapes # the number of tapes in rotation >>> seems fine. >>> > >> Amanda reported that the dumps where successfully to tape vtape-7, but >> taking a simple look to what that vtape-7 contained (using ls), has >> proved >> the opposite, there was no sign of /var/spool/mail/p (and the other >> DLE's >> which had the same problem) on vtape-7. >> >> vtape-7 contained /data/data0/share1 (directory, which I said above, >> was >> reported not to be backuped successfully) >> >> I should mention that these this didn't occure on the same run. My guess >> is that Amanda backuped successfully /var/spool/mail/p (and the other >> DLE's) on the 24.02 and wrote them to vtape-7, but on the 2.03 when this >> error occured: >> >> baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 >> KB, >> incremental dump also larger than tape] >> >> The dumps where written again on vtape-7, so that's the reason why >> /data/data0/share1 appears to pe on vtape-7 instead of /var/spool/mail/p >> (and the other DLE's) > [...] >> >> I've noticed that 12 vtapes where used in less than 10 days (the >> dumpcycle >> = 10 days) but is that an excuse for missing data? > > Again on vtape-7 ??? How is that possible? > Do you have runtapes > 1 ? > Or do you run amdump multiple times a day? Amanda uses sometime more than 1 tape per run. That's why vtape-7 was again next. So even if I would have defined runtapes 1, Amanda would have used more. > Any idea why amadmin still believes that vtape-7 contains the data > from feb 24, and not data from mar 2 ? This is what I'm trying to find out. and I have no logical explanation yet. >>Level 1 dump didn't contain *all* of the expected files. Some of the mails >>received during the level 0 dump and level 1 dump, where not present. >> >>I should add that the volume /var/spool/mail (which is split in >>/var/spool/mail/[a-z]) is 130 GB big and has ~7 million inodes. What about the missing files? Does anyone have a clue about how something like this is possible? Is it because of the huge number of inodes on the fs? Iulian Topliceanu
Re: Wrong amadmin reports and missing data
On 2006-03-09 17:19, Iulian Topliceanu wrote: Paul Bijnens wrote: On 2006-03-09 13:25, Iulian Topliceanu wrote: The dump definition looks like this: dumpcycle 10 day# the number of days in the normal dump cycle runspercycle 8 day# the number of amdump runs in dumpcycle days tapecycle 12 tapes # the number of tapes in rotation seems fine. Amanda reported that the dumps where successfully to tape vtape-7, but taking a simple look to what that vtape-7 contained (using ls), has proved the opposite, there was no sign of /var/spool/mail/p (and the other DLE's which had the same problem) on vtape-7. vtape-7 contained /data/data0/share1 (directory, which I said above, was reported not to be backuped successfully) I should mention that these this didn't occure on the same run. My guess is that Amanda backuped successfully /var/spool/mail/p (and the other DLE's) on the 24.02 and wrote them to vtape-7, but on the 2.03 when this error occured: baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] The dumps where written again on vtape-7, so that's the reason why /data/data0/share1 appears to pe on vtape-7 instead of /var/spool/mail/p (and the other DLE's) [...] I've noticed that 12 vtapes where used in less than 10 days (the dumpcycle = 10 days) but is that an excuse for missing data? Again on vtape-7 ??? How is that possible? Do you have runtapes > 1 ? Or do you run amdump multiple times a day? Any idea why amadmin still believes that vtape-7 contains the data from feb 24, and not data from mar 2 ? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Wrong amadmin reports and missing data
The mail very well formated, so I'm sending it again. Sorry for the duplicate. Paul Bijnens wrote: > On 2006-03-09 13:25, Iulian Topliceanu wrote: >> >> I'm using AMANDA server 2.4.5p1 on a RH 9 having DLT tapes and vtapes as >> well. >> >> All the backup clients are Linux machines using ext3 fs. >> >> I had two particular problem with a client running CentOS and using >> tar-1.14 and amanda-client 2.4.5p1. > > The CentOS tar-1.14 that I use does work fine AFAIK, and I also use >Amanda 2.4.5p1 on the production server (and clients). > > >> 1: amadmin (and the mail reports as well) reported that /var/spool/mail/p >> level 0 dump, was on vtape-7, but for unknown reasons, vtape-7 didn't >> contain any data regarding /var/spool/mail/p, it contained >> other data that had no relevance. > > Here you talk about "vtape-7", below you talk about "vtapes-7", plural. > Typing mistake in the mail, I presume... Typo, sorry. The right one is vtape-7 > > "other data"? amanda backups? or garbage? It contained other data, not garbage. It contained data that was reported as failed to be backuped. baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] > > One other thing: is the /var/spool/mail/p a directory or a plain file? /var/spool/mail/p is a directory. > >> >> I wasn't able to find /var/spool/mail/p level 0 dump, on any of the >> vtapes. The backup was inconsistent. > > What do you mean with "inconsistent" here? > Is that entry the only one that is missing, and seems the rest to > be OK? It wasn't the only entry that wasn't ok, I had another 7 DLE's which had the same problem, all of them reported to be also on vtape-7 (singular) > > >> >> I've checked the history of AMANDA, and /var/spool/mail/p level 0 dump, >> was reported to be on vtapes-7, and there wasn't any error during the >> backup procedure. > > ... "vtapes-7" ... > > >> >> The dump definition looks like this: >> >> dumpcycle 10 day# the number of days in the normal dump cycle >> runspercycle 8 day# the number of amdump runs in dumpcycle days >> tapecycle 12 tapes # the number of tapes in rotation > > seems fine. > >> >> Can I still trust AMANDA reports or should I do a manual check? > > I trust them. But you don't have to believe me. I've trusted them as well and I will still trust them > If you have reason to not trust them, then extra checks are appropriate. > However, would those extra checks have detected an error that Amanda > was unable to? What kind of extra checks did you think of? Amanda reported that the dumps where successfully to tape vtape-7, but taking a simple look to what that vtape-7 contained (using ls), has proved the opposite, there was no sign of /var/spool/mail/p (and the other DLE's which had the same problem) on vtape-7. vtape-7 contained /data/data0/share1 (directory, which I said above, was reported not to be backuped successfully) I should mention that these didn't occure on the same run. My guess is that Amanda backuped successfully /var/spool/mail/p (and the other DLE's) on the 24.02 and wrote them to vtape-7, but on the 2.03 when this error occured: baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] The dumps where written again on vtape-7, so that's the reason why /data/data0/share1 appears to pe on vtape-7 instead of /var/spool/mail/p (and the other DLE's) But why doesn't amadmin report that? Why doesn't Amanda make again a level 0 dump of /var/spool/mail/p? I've noticed that 12 vtapes where used in less than 10 days (the dumpcycle = 10 days) but is that an excuse for missing data? > > >> >> 2: the last level 0 dump of /var/spool/mail/p was on the 24.02, and the >> next incremental dump took place on the 27.02, so, though the level 0 >>dump >> of /var/spool/mail/p was missing, the incremental backup of >> /var/spool/mail/p should have had included all the new mails between >>24.02 >> - 27.02. >> >> How is is possible for GNUtar to skip files that have a ctime newer than >> the last level 0 dump? > > Do you mean that the level 1 dump did not contain the expected files >either? Did it contain anything at all? Level 1 dump didn't contain *all* of the expected files. Some of the mails received during the level 0 dump and level 1 dump, where not present. I should add that the volume /var/spool/mail (which is split in /var/spool/mail/[a-z]) is 130 GB big and has ~7 million inodes. Iulian Topliceanu
Re: Wrong amadmin reports and missing data
Paul Bijnens wrote: > On 2006-03-09 13:25, Iulian Topliceanu wrote: >> >> I'm using AMANDA server 2.4.5p1 on a RH 9 having DLT tapes and vtapes as >> well. >> >> All the backup clients are Linux machines using ext3 fs. >> >> I had two particular problem with a client running CentOS and using >> tar-1.14 and amanda-client 2.4.5p1. > > The CentOS tar-1.14 that I use does work fine AFAIK, and I also use Amanda 2.4.5p1 on the production server (and clients). > > >> 1: amadmin (and the mail reports as well) reported that /var/spool/mail/p >> level 0 dump, was on vtape-7, but for unknown reasons, vtape-7 didn't >> contain any data regarding /var/spool/mail/p, it contained >> other data that had no relevance. > > Here you talk about "vtape-7", below you talk about "vtapes-7", plural. > Typing mistake in the mail, I presume... Typo, sorry. > > "other data"? amanda backups? or garbage? It contained other data, not garbage. It contained data that was reported as failed to be backuped. baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] > > One other thing: is the /var/spool/mail/p a directory or a plain file? /var/spool/mail/p is a directory. > >> >> I wasn't able to find /var/spool/mail/p level 0 dump, on any of the >> vtapes. The backup was inconsistent. > > What do you mean with "inconsistent" here? > Is that entry the only one that is missing, and seems the rest to > be OK? It wasn't the only entry that wasn't ok, I had another 7 DLE's which had the same problem, all of them reported to be also on vtape-7 (singular) > > >> >> I've checked the history of AMANDA, and /var/spool/mail/p level 0 dump, >> was reported to be on vtapes-7, and there wasn't any error during the >> backup procedure. > > ... "vtapes-7" ... > > >> >> The dump definition looks like this: >> >> dumpcycle 10 day# the number of days in the normal dump cycle >> runspercycle 8 day# the number of amdump runs in dumpcycle days >> tapecycle 12 tapes # the number of tapes in rotation > > seems fine. > >> >> Can I still trust AMANDA reports or should I do a manual check? > > I trust them. But you don't have to believe me. I've trusted them as well and I will still trust them > If you have reason to not trust them, then extra checks are appropriate. > However, would those extra checks have detected an error that Amanda > was unable to? What kind of extra checks did you think of? Amanda reported that the dumps where successfully to tape vtape-7, but taking a simple look to what that vtape-7 contained (using ls), has proved the opposite, there was no sign of /var/spool/mail/p (and the other DLE's which had the same problem) on vtape-7. vtape-7 contained /data/data0/share1 (directory, which I said above, was reported not to be backuped successfully) I should mention that these this didn't occure on the same run. My guess is that Amanda backuped successfully /var/spool/mail/p (and the other DLE's) on the 24.02 and wrote them to vtape-7, but on the 2.03 when this error occured: baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] The dumps where written again on vtape-7, so that's the reason why /data/data0/share1 appears to pe on vtape-7 instead of /var/spool/mail/p (and the other DLE's) But why doesn't amadmin report that? Why doesn't Amanda make again a level 0 dump of /var/spool/mail/p? I've noticed that 12 vtapes where used in less than 10 days (the dumpcycle = 10 days) but is that an excuse for missing data? > > >> >> 2: the last level 0 dump of /var/spool/mail/p was on the 24.02, and the >> next incremental dump took place on the 27.02, so, though the level 0 dump >> of /var/spool/mail/p was missing, the incremental backup of >> /var/spool/mail/p should have had included all the new mails between 24.02 >> - 27.02. >> >> How is is possible for GNUtar to skip files that have a ctime newer than >> the last level 0 dump? > > Do you mean that the level 1 dump did not contain the expected files either? Did it contain anything at all? Level 1 dump didn't contain *all* of the expected files. Some of the mails received during the level 0 dump and level 1 dump, where not present. I should add that the volume /var/spool/mail (which is split in /var/spool/mail/[a-z]) is 130 GB big and has ~7 million inodes. Iulian Topliceanu
Re: Which is the correct way to backup windows servers using amanda? Is there one?
On Thu, Mar 09, 2006 at 02:43:19PM +0100, Moritz Both wrote: > > Which is the correct way to backup windows servers using amanda? Is > there one? > > First of all, I think this must have been discussed a lot of times on > the list - probably. Unfortunately, I did not have much luck searching > the archives, only random single statements - And here is another ;( (note, I'm pretty biased against windows, so read these comments with that in mind) Amanda is not a suitable solution, neither for "complete", nor for "production", backup of a windows environment. A major problem is that the only backup tool, smbclient, acts at the file and directory level in windows like tar does in an unix environment. To a reasonalble degree this works in the unix environment because there is an omnipotent user available and there are pretty consistant file access capabilities. In contrast, neither the admin user, nor the backup operator in windows is truely omnipotent. They both run into limitations while accessing files and directories. Files opened by an application can not be backed up, "system" files and dirs are not accessible, access rights can be specifically denied to admin and backup user ... BTW linux users, the new extended permissions capabilities can be used to deny file/directory access to root :) Another problem I see with backing up user data in windows is "where is the user data". In unix user foo's data is pretty much under /home/foo. It seems to this bigot not to be the case in windows. Applications like quicken, word, or firefox or ... may elect to put your data under their C:\Program Files installation directory. Or maybe under some "User Application" directory under \Windows. Or just maybe in And don't start on the Registry :) So is amanda totally unsuitable for backing up windows systems? No. But it must be used with an understanding of the limitations and recognition of what you can and what you are actually backing up. If you have a mostly windows environment, it probably does deserve its own backup solution. One that works at lower filesystem levels and can overcome the higher level restrictions. I.e. a backup solution sanctioned by M$. If you have a unix environment already being backed up by amanda and need some data backup and recover for a few windows clients (not system backups, specific data backup) then fine add them to your amanda disklist. Make sure to follow those warnings in the amanda report and see what is not being backed up in case something changes the access rights of some files or directories. If you want to backup the entire windows system rather than specific directories, and are willing to say "I might not get all of it back", then amanda works for that too. It is an approach I use in my home environment. And when a windows system died, I couldn't get it all back at the system level. Couldn't even reinstall apps. But I did recover the family photos, financial data, ... And that was able to be imported back to the apps, newly installed, on the rebuilt, from scratch, system. > > Recently, they has a headcrash on a non-mirrored disk and the tapes were > needed. As it turned out, all backups of the windows servers were > incomplete. smbclient thought 70-80 files per directory must be enough. > At backup time, it just went ahead to the next directory, and whenever a > directory contained more than this many files, they were simply ignored > without any warning or error message. This is a ludicrous defect if actually present in smbclient. I say "if" because I've not heard it before and certainly would expect to were it present. One hundred plus files in a directory is hardly an uncommon situation. I suspect something else is going on here. One thing is clear; the amanda administrators at your site were not following the reports very carefully nor were they trying periodic recoveries to ensure anything was actually being saved. Those are policy crimes of which I can also be accused. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Which is the correct way to backup windows servers using amanda? Is there one?
On 2006-03-09 14:43, Moritz Both wrote: Which is the correct way to backup windows servers using amanda? Is there one? Windows backup is indeed not handled first class, as you noted. Nor it is tested/used extensively either. I did use the smbclient way with Amanda for some time on some servers (and even was able to restore files too), but my main method of handling it is moving the data to a linux server instead. That works pretty good in our case. Many of my users aren't even aware that the fileserver is actually Linux and not some MS Windows version. YMMV... -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Which is the correct way to backup windows servers using amanda? Is there one?
Which is the correct way to backup windows servers using amanda? Is
there one?
First of all, I think this must have been discussed a lot of times on
the list - probably. Unfortunately, I did not have much luck searching
the archives, only random single statements -
We are running amanda for years now. For us, backup of windows servers
is a non-issue because we don't have production win servers. However, a
customer of us has several such servers. Backup is done through a debian
sarge linux server using amanda and SMB (samba 3).
Recently, they has a headcrash on a non-mirrored disk and the tapes were
needed. As it turned out, all backups of the windows servers were
incomplete. smbclient thought 70-80 files per directory must be enough.
At backup time, it just went ahead to the next directory, and whenever a
directory contained more than this many files, they were simply ignored
without any warning or error message.
The result is massive data loss. (Professional hardware data recovery
failed.)
We installed a samba update on the debian sarge server. Now, more files
make it to the tape, but some other bug in smbclient makes it fail after
it has run for a certain time. We have no clue why, but it would start
to write bad filenames to the tar archive with repeated equal names and
dozends of empty files... we came to the conclusion that smbclient it
not the correct way to do backups. At least not for the data volume in
question (~50 GByte compressed, > 100,000 files).
Now the question: How do folks make backups of windows servers? Is
cygwin a real solution - or is it just a hack as well? Does the native
Win32 amanda client ("beta") on sourceforge work? Or are you using
native windows backup software with its own tape drive?
Thanks for any hints!
Moritz
--
Moritz Both
aldebaran Daten- und Kommunikationssysteme GmbH
Im Moore 26, 30167 Hannover
Tel. +49 511 270 41 60 http://www.aldebaran.de
Fax +49 511 270 41 6 33
Re: Wrong amadmin reports and missing data
On 2006-03-09 13:25, Iulian Topliceanu wrote: I'm using AMANDA server 2.4.5p1 on a RH 9 having DLT tapes and vtapes as well. All the backup clients are Linux machines using ext3 fs. I had two particular problem with a client running CentOS and using tar-1.14 and amanda-client 2.4.5p1. The CentOS tar-1.14 that I use does work fine AFAIK, and I also use Amanda 2.4.5p1 on the production server (and clients). 1: amadmin (and the mail reports as well) reported that /var/spool/mail/p level 0 dump, was on vtape-7, but for unknown reasons, vtape-7 didn't contain any data regarding /var/spool/mail/p, it contained other data that had no relevance. Here you talk about "vtape-7", below you talk about "vtapes-7", plural. Typing mistake in the mail, I presume... "other data"? amanda backups? or garbage? One other thing: is the /var/spool/mail/p a directory or a plain file? I wasn't able to find /var/spool/mail/p level 0 dump, on any of the vtapes. The backup was inconsistent. What do you mean with "inconsistent" here? Is that entry the only one that is missing, and seems the rest to be OK? I've checked the history of AMANDA, and /var/spool/mail/p level 0 dump, was reported to be on vtapes-7, and there wasn't any error during the backup procedure. ... "vtapes-7" ... The dump definition looks like this: dumpcycle 10 day# the number of days in the normal dump cycle runspercycle 8 day# the number of amdump runs in dumpcycle days tapecycle 12 tapes # the number of tapes in rotation seems fine. Can I still trust AMANDA reports or should I do a manual check? I trust them. But you don't have to believe me. If you have reason to not trust them, then extra checks are appropriate. However, would those extra checks have detected an error that Amanda was unable to? What kind of extra checks did you think of? 2: the last level 0 dump of /var/spool/mail/p was on the 24.02, and the next incremental dump took place on the 27.02, so, though the level 0 dump of /var/spool/mail/p was missing, the incremental backup of /var/spool/mail/p should have had included all the new mails between 24.02 - 27.02. How is is possible for GNUtar to skip files that have a ctime newer than the last level 0 dump? Do you mean that the level 1 dump did not contain the expected files either? Did it contain anything at all? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Wrong amadmin reports and missing data
Hi, I'm using AMANDA server 2.4.5p1 on a RH 9 having DLT tapes and vtapes as well. All the backup clients are Linux machines using ext3 fs. I had two particular problem with a client running CentOS and using tar-1.14 and amanda-client 2.4.5p1. 1: amadmin (and the mail reports as well) reported that /var/spool/mail/p level 0 dump, was on vtape-7, but for unknown reasons, vtape-7 didn't contain any data regarding /var/spool/mail/p, it contained other data that had no relevance. I wasn't able to find /var/spool/mail/p level 0 dump, on any of the vtapes. The backup was inconsistent. I've checked the history of AMANDA, and /var/spool/mail/p level 0 dump, was reported to be on vtapes-7, and there wasn't any error during the backup procedure. The dump definition looks like this: dumpcycle 10 day# the number of days in the normal dump cycle runspercycle 8 day# the number of amdump runs in dumpcycle days tapecycle 12 tapes # the number of tapes in rotation Can I still trust AMANDA reports or should I do a manual check? 2: the last level 0 dump of /var/spool/mail/p was on the 24.02, and the next incremental dump took place on the 27.02, so, though the level 0 dump of /var/spool/mail/p was missing, the incremental backup of /var/spool/mail/p should have had included all the new mails between 24.02 - 27.02. How is is possible for GNUtar to skip files that have a ctime newer than the last level 0 dump? Thanks for your support, Iulian Topliceanu
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 12:05 -0500, Jon LaBadie wrote: > So, rather than use "listed-incremental" to recognize > it is a renamed directory, gnutar's behavior is to > consider then entire directory tree "changed" and > back up the entire tree. > > Reading this thread reminded me of another one where > the poster was complaining about this "feature" of > gnutar. That poster has a lot of rotating log dirs > that were quite large. They were rotated by renaming > them each night (log.2 becomes log.3, log.1 -> log.2 etc.) > Their complaint was that the data in the directory WAS > being backed up each night though it was unchanging. > > Be nice if gnutar could deal with both needs. Indeed, that very issue had occurred to me too :-) However, directory renames are fairly rare and IMO if there is an 'error' it should be "back up too much but making sure it's complete" rather than "keep the backup size small but occasionally miss something important". Of course, supporting both Would Be Nice, as you say... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
