RE: moved to new disk, now amanda wants to do level 0's on whole system
> either. To copy directory trees, I usually use "( cd /fromdir ; tar > cf - . ) | ( cd /todir ; tar xpf -)", which preserves modification > times, and permissions. I definitely am a fan of tar copying, but wouldn't recommend the above (as written). The brief explanation is that you really want to replace the ';' inside of the parens with '&&'. Below is the more complete example of why it matters: ## set up the test scenario [EMAIL PROTECTED] tmp]# cd /tmp [EMAIL PROTECTED] tmp]# mkdir foo1 foo2 [EMAIL PROTECTED] tmp]# cp /etc/hosts foo1 ## make sure there is no /tmp/hosts [EMAIL PROTECTED] tmp]# ls -al hosts ls: hosts: No such file or directory ## execute the command, but with a typo in the second 'cd' command [EMAIL PROTECTED] tmp]# (cd /tmp/foo1; tar -cf - *) | (cd /tmp/f002; tar -xf -) bash: cd: /tmp/f002: No such file or directory ## check to see if /tmp/hosts exists now? Oops. [EMAIL PROTECTED] tmp]# ls -al hosts -rw-r--r--1 root root 153 Nov 14 13:10 hosts [EMAIL PROTECTED] tmp]# ls -al foo2 total 2 drwxr-xr-x2 root root 1024 Nov 14 13:10 . drwxrwxrwt8 root root 1024 Nov 14 13:10 .. For folks new to unix-- replacing the semi-colon after the 'cd' command with '&&' causes the command following to not get executed. Logically speaking, it's a way of saying: Execute this command AND THEN this other command. If the first command fails, don't execute the second command. -ron
InterScan NT Alert
Receiver, InterScan has detected virus(es) in the e-mail attachment. Date: Fri, 14 Nov 2003 20:18:23 - Method: Mail From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> File: readnow.zip Action: clean failed - deleted Virus: WORM_MIMAIL.F-1
AWARD WINNING NOTIFICATION!!!!
LOTERIAS Y APUESTAS DEL ESTADO BONOLOTTO Y PRIMITIVA-ELGORDO C/GUZMAN EL BUENO,137 280009,MADRID,SPAIN TEL:+34-670-545-282/ FAX:+34-645-564-045. E-mail: [EMAIL PROTECTED] FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD AWARD NOTIFICATION We are pleased to inform you of the release today, 14th Octobere 2003,of the ELGORDO SWEEPSTAKE LOTTERY/INTER-NATIONAL PROGRAMS held on the 6th September ,2003. Your name attached to ticket number 025 11464992-750 with serial number 2113-05 drew the lucky number 3-18-19-30-32-39, which consequently won the lottery in the 3rd category. You are therefore been approve for the lump sum pay out of ?uros 1,547,000.87 (One Million Five Hundred And Fourty Seven Thousand Eighty Seven cents.) in cash credit to the file REF: LP/26510460037/03. This is from a total prize of ?uros 26,299,000.00 share among the seventeen (17) International winners in this category. CONGRATULATION Your fund is now deposited with a finance and insurance company, MAPFRE SEGUROS. Due to the mixed up of some numbers and names, we ask that you keep this award a top secret from the public notice until your claim as been processed and your prize money remitted to your account as this is a part of our Security protocol to avoid double claiming award or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 25,000 names from Australia, USA, Europe, Asia ,New Zealand, Middle-East and South-North America .As part of our international promotions program, which we conducted once in a year. We hope with a part of your prize, you will take part in our end of the year high stake ?uros 300 Million International Lottery. To file claim over your winning, please contact the issuing authority, your prize claim agent, Mr. Julio Romero, (Foreign Service Manager) for processing and remittance of your prize money to a designated account of your choice. Tel: +34 -606-71-29-63. .Email: [EMAIL PROTECTED] ..Remember, all prize money must be claimed not later than the 14th January, 2004. After this date all funds will be returned as unclaimed. Note: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondence with your agent. Furthermore, should there be any change of address do inform your claims agent as soon as possible. Please remember to ask for your prize claim certificate. Congratulation again from all members and staff for being part of our promotion program. Regards, Anna Lopez.
InterScan NT Alert
Receiver, InterScan has detected virus(es) in the e-mail attachment. Date: Fri, 14 Nov 2003 20:41:18 - Method: Mail From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> File: readnow.zip Action: clean failed - deleted Virus: WORM_MIMAIL.F-1
chg-zd-mtx, tape library, multiple tape drives, "driveslot"
Explanation: Our tape library has multiple LTO drives, we have multiple amanda configs, but all of the amanda configs are sharing a single "database" (all of the chg-zd-mtx.* files). Each amanda config (by name: dailyset, archive, tapemgr) is using it's own tape drive, and there is also a local dds drive in the amanda server. The following table might explain it a bit better: Use:Device: incidental dds /dev/nst0 dailyset (amanda) /dev/nst1 archive (amanda)/dev/nst2 tapemgr (amanda)/dev/nst3 The labelstr for tapemgr is very loose, and allows us to read tapes from either of the other two configs. Because we have a shared chg-zd-mtx "database", we could not put the driveslot variable into our chg-zd-mtx.conf file, as that caused all the configs to try to use that specific drive. (Actually, it was a bit worse than that. The tape would eject out of the correct drive, but the changer script would always send the robot arm to the first drive in the library.) The following patch successfully resolves that problem for us. In order for this patch to be of use to you, you will just need to set a "drivenumoffset" in your shared chg-zd-mtx.conf file. In our situation (described above), drivenumoffset=1 because /dev/nst0 is not used for amanda. NOTE: Works for us, might work for you. We think we're not adding any bugs. BTW, we like amanda. Thanks for all the work! -ron *** chg-zd-mtx.orig Thu Nov 13 14:45:07 2003 --- chg-zd-mtx Fri Nov 14 11:55:36 2003 *** *** 631,636 --- 631,637 varlist="$varlist driveslot" varlist="$varlist poll_drive_ready" varlist="$varlist max_drive_wait" + varlist="$varlist drivenumoffset" for var in $varlist do *** *** 646,656 eval $var=\"$val\" done # Deal with driveslot first so we can get DBGFILE set if we are still # using the old amgetconf. if [ -z "$driveslot" ]; then ! driveslot=0; fi # Get DBGFILE set if it is not already. --- 647,665 eval $var=\"$val\" done + # If drivenumoffset is not set, default to 0 so that it doesn't break + # any later calculations + + if [ -z "$drivenumoffset" ]; then + drivenumoffset=0 + fi + # Deal with driveslot first so we can get DBGFILE set if we are still # using the old amgetconf. if [ -z "$driveslot" ]; then ! drivenum=`echo $tape | sed -n "s/\/dev\/\(.*\)\([0-9][0-9]*\)\(.*\)/\2/p" ` ! driveslot=$[$drivenum-$drivenumoffset]; fi # Get DBGFILE set if it is not already.
Infected E-Mail
>> O e-mail enviado para você <<< De / Assunto [EMAIL PROTECTED] / don't be late! rahrohao foi encontrado um vírus no arquivo Anexado, e este vírus, não foi enviado para você. Informações sobre o Vírus: +++ Virus Scanner : readnow.doc.scr : W32/Mimail-F Se você tiver futuras questões, por favor, consulte o nosso especialista de E-mail: Para a sua informação, nós incluímos uma parte filtrada da mensagem original do E-mail. * -- A mensagem original segue abaixo: -- * Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. rahrohao
don't be late! rahrohao
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. rahrohao readnow.zip Description: Zip compressed data
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Fri, 14 Nov 2003, Eric Siegerman wrote: > But all of those -- tar, cpio, rsync -- are kludges. Is it just > me, or do other people also find it ludicrous that 30+ years on, > UNIX still doesn't have a proper copy command? Huh? You just showed there are enough flavors to suit just about any taste. The only obvious one I see missing is dd, which is great for copying a whole partition. -Mitch
Infected E-Mail
>> O e-mail enviado para você <<< De / Assunto [EMAIL PROTECTED] / don't be late! oikomnam foi encontrado um vírus no arquivo Anexado, e este vírus, não foi enviado para você. Informações sobre o Vírus: +++ Virus Scanner : readnow.doc.scr : W32/Mimail-F Se você tiver futuras questões, por favor, consulte o nosso especialista de E-mail: Para a sua informação, nós incluímos uma parte filtrada da mensagem original do E-mail. * -- A mensagem original segue abaixo: -- * Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. oikomnam
don't be late! oikomnam
Will meet tonight as we agreed, because on Wednesday I don't think I'll make it, so don't be late. And yes, by the way here is the file you asked for. It's all written there. See you. oikomnam readnow.zip Description: Zip compressed data
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Fri, Nov 14, 2003 at 09:20:23AM -0500, Jay Fenlason wrote: > Also, cp/fr may not have correctly reset the modification times of the > files when it copied them. Oh, and they may not handle links well > either. To copy directory trees, I usually use "( cd /fromdir ; tar > cf - . ) | ( cd /todir ; tar xpf -)", which preserves modification > times, and permissions. I've had problems with tar, too. Unfortunately, that was so long ago that I forget what they were. Maybe it stores only mtime in the tarball, and on extraction sets both mtime and atime to the saved mtime value. Oh, and I think it likes to (try to) copy the contents of special files, FIFOs, and the like, instead of recreating them in the destination tree. Until recently, I used the cpio variant of your suggestion: cd /fromdir find . -depth -print0 | cpio -padmu0 /todir (You need GNU find and cpio for the "0" part to work. -depth is to get the directories' mtimes copied properly. It makes each directory come *after* its contents in the file listing. Without -depth, the directory would come first; cpio would properly set its mtime, and then stomp on it by creating the directory's contents.) But then I discovered rsync. Rsync rocks. "rsync -aH" copies everything the kernel lets you copy (i.e. not ctimes, and not inumbers). The only problem with rsync is the weird way it gives meaning to a trailing slash; these two are *not* equivalent: rsync -aH srcdir/ destdir rsync -aH srcdir destdir Then again, I'm not sure whether either cpio or rsync can deal with a username that's changed its numerical userid, or similarly for groups. I think some tar's can. Or maybe it's cpio that can handle that; can't remember. And gtar probably doesn't have any of those problems -- people are using it for backups after all :-) -- but it's not always available, and even non-GNU cpio's do everything but the "0" trick. But all of those -- tar, cpio, rsync -- are kludges. Is it just me, or do other people also find it ludicrous that 30+ years on, UNIX still doesn't have a proper copy command? -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau
thanks
MR. WILLIAMS LAWAL PACIFIC BANK OF SOUTH AFRICA, 9TH FLOOR, HEERENGRACHT TOWER, STANDARD BANK CENTER, CAPE TOWN, SOUTH AFRICA. DEAR SIR, I am Mr Williams Lawal, the Branch Manager Pacific Bank of South Africa, Cape Town .I have urgent and very confidential business proposition for you. On June 6,1999, an American Oil consultant/contractor with the South Africa Mining Corporation, Mr. Charles Anderson made a numbered time (Fixed) Deposit for twelve calendar months, valued at US$20,000,000.00 (Twenty Million Dollars) in my branch.Upon maturity, I sent a routine notification to his forwarding address but got no reply.After a month, we sent a reminder and finally we discovered from his contract employers, the South Africa Mining Corporation that Mr. Charles Anderson died from an automobile accident. On further investigation, I found out that he died without making a WILL, and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr. Charles Anderson did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$20,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one will ever come forward to claim it. According to South Africa Law, at the expiration of 5 (five) years, the money will revert to the ownership of the South Africa Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you as a foreigner to stand in as the next of kin to Mr. Charles Anderson so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the service of two Attorneys for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 70% for me and 30% for you. There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address [EMAIL PROTECTED] Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please observe utmost confidentiality, and rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. Awaiting your urgent reply via a return email Thanks and regards. Mr. Williams Lawal [EMAIL PROTECTED]
Re: backup lasts forever on large fs (fwd)
On Fri, Nov 14, 2003 at 07:15:07PM +0100, Zoltan Kato wrote: > > /home is not NFS mounted and the directories are not transient (they are > the actual home dirs of individual users). runtar is seduid root. I tryed > to run the gtar command from the log file manually as root, and found that > it ONLY works when I run it from /home: > > [EMAIL PROTECTED] cd /home/ > [EMAIL PROTECTED] /opt/sfw/bin/gtar --create --file /dev/null --directory /home This is NOT related to the problem you are seeing. However note that the version of gnutar that Sun supplies to install in /opt/sfw/bin/gtar, or /usr/sfw/bin/gtar in later releases, is not a suitable version for use with amanda. It is only 1.13 and what is needed is 1.13.25. Get and build it from alpha.gnu.org. To avoid name confilicts, install it as something like "amgtar". and recompile amanda to explicitly use the newly installed version. jon -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: backup lasts forever on large fs (fwd)
/home is not NFS mounted and the directories are not transient (they are
the actual home dirs of individual users). runtar is seduid root. I tryed
to run the gtar command from the log file manually as root, and found that
it ONLY works when I run it from /home:
[EMAIL PROTECTED] cd /home/
[EMAIL PROTECTED] /opt/sfw/bin/gtar --create --file /dev/null --directory /home
--one-file-system --listed-incremental
/usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_home_h0_0.new
--sparse --ignore-failed-read --totals --files-from
/tmp/amanda/sendsize._home__h0.20031113235902.include 2>&1|less
But then how is it possible that sendsize (or whatever other program) can
collect the filenames in
/tmp/amanda/sendsize._home__h0.20031113235902.include but gtar fails
unless started from /home (note that the --directory /home is present on
the command line which should cd to /home). Any idea? How should I
specify the include/exclude directives in the disklist entries?
Regards,
Zoltan
__
http://www.inf.u-szeged.hu/~kato/ -- research in computer vision
http://www.cameradigita.com/ -- photography (online gallery)
__
On Fri, 14 Nov 2003, Paul Bijnens wrote:
> Zoltan Kato wrote:
>
> > Still doesn't work. I've split the /home partition into several pieces as
> > recommended in an earlier message (my disklist entries are included at
> > the end). Since I havent' received the usual email report from amanda
> > (why??), I went to /tmp/amanda to see the logs. It looks like sendsize
> > is run with non-root privileges hence it cannot stat/read individual
> > home directories (quite normal as they are restricted to the owner). This
> > is what I found:
> >
> > sendsize: debug 1 pid 5628 ruid 103 euid 103: start at Thu Nov 13 23:59:01
> > 2003
> ...
> > sendsize[5630]: time 0.041: getting size via gnutar for /etc level 0
> ...
> > sendsize[5630]: estimate time for /etc level 0: 0.897
> > sendsize[5630]: estimate size for /etc level 0: 3650 KB
>
> estimate for level 0 for /etc succeeded fine in less then a second.
>
> ...
> > sendsize[5630]: estimate time for /etc level 1: 0.050
> > sendsize[5630]: estimate size for /etc level 1: 120 KB
>
> the same for level 1 even faster.
>
> Next amanda tries /home_h0:
>
> ...
> > sendsize[5633]: time 1.051: calculating for amname '/home_h0', dirname
> > '/home', spindle -1
> > sendsize[5633]: time 1.051: getting size via gnutar for /home_h0 level 0
>
> The runtar is the program that needs to be suid-root. Verify this
> please. /home isn't an nfs-mount by accident? On a normal nfs-mounted
> directory, root on the cleint becomes "nobody" on the server.
> You have to specify special mount options on the nfs-server to get
> root==root. See the "no_root_squash" option in the exports file.
>
>
> > sendsize[5633]: time 1.139: spawning /usr/local/libexec/runtar in pipeline
> > sendsize[5633]: argument list: /opt/sfw/bin/gtar --create --file /dev/null
> > --directory /home --one-file-system --listed-incremental
> > /usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_home_h0_0.new
> > --sparse --ignore-failed-read --totals --files-from
> > /tmp/amanda/sendsize._home__h0.20031113235902.include
>
> Try to execute the above command line interactively, as root.
> Does that work?
>
> > sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h0: No such
> > file or directory
> > sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h01: No
> > such file or directory
> > sendsize[5633]: time 1.173: /opt/sfw/bin/gtar: Cannot stat ./h02: No
> > such file or directory
> > sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h03: No
> > such file or directory
> > sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h039963: No
> > such file or directory
> > sendsize[5633]: time 1.175: /opt/sfw/bin/gtar: Cannot stat ./h039966: No
> > such file or directory
> >
> > ... (similar messages repeated) .
>
> Do these directories/files actually exist? Or are they shortlived,
> and between the time amanda expanded the "./h[0]*" in the file
> /tmp/amanda/sendsize._home__h0.20031113235902.include and the time
> that gtar was started. It's only a second (1.172 sec to be precise),
> but these days computers can get really fast.
>
> Also the message is "No such file or directory" instead of "Permission
> denied". Usually I believe those error messages in Unix.
>
>
> ...
> > My disklist:
> >
> > rozi.cab.u-szeged.hu/etcroot-tar
> > rozi.cab.u-szeged.hu/home_h0/home { # h0*
> > user-tar
> > include "./h[0]*"
> > }
> ...
> > rozi.cab.u-szeged.hu/home_rest /home { # the rest
> > user-tar
> > exclude "./h[0-9]*"
> > }
>
>
> --
> Paul Bijnens, XplanationTel +32 16 397.511
> Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Fri, Nov 14, 2003 at 05:26:26PM +0100, Christopher Odenbach wrote: > > Hi, > > > The times reported by an ls -l seem to be sane, and of those perms I > > checked, they were preserved ok. The major hiccup I had was that cp > > doesn't do ".name" files > > Of course "cp" does copy dot-files. I think you may have stumbled over > the shell asterisk. > > If you say "cp -rp * /somewhere", the shell expands the "*" to all files > and dirs in that directory except those beginning with a dot! > > Try "echo *" - you get a list of the files in the current directory but > without the dot files. > > You may use "cp * .??*" as a workaround (.??* means all filenames that > begin with a dot but excludes ".." which would be too much), but that > won't cover files like ".a" or similar dot-and-one-letter filenames. > If you really want/must to use cp, you can get all the entries with the -A option of ls. It is like -a except it omits the "." and ".." directories. cp -rp `ls -A` dstdir # or ksh/bash: cp -rp $(ls -A) dstdir Have to be done as root to preserve ids and permissions with the "-p" option and as noted, does have a symlink problem. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: backup lasts forever on large fs (fwd)
Zoltan Kato wrote:
Still doesn't work. I've split the /home partition into several pieces as
recommended in an earlier message (my disklist entries are included at
the end). Since I havent' received the usual email report from amanda
(why??), I went to /tmp/amanda to see the logs. It looks like sendsize
is run with non-root privileges hence it cannot stat/read individual
home directories (quite normal as they are restricted to the owner). This
is what I found:
sendsize: debug 1 pid 5628 ruid 103 euid 103: start at Thu Nov 13 23:59:01
2003
...
sendsize[5630]: time 0.041: getting size via gnutar for /etc level 0
...
sendsize[5630]: estimate time for /etc level 0: 0.897
sendsize[5630]: estimate size for /etc level 0: 3650 KB
estimate for level 0 for /etc succeeded fine in less then a second.
...
sendsize[5630]: estimate time for /etc level 1: 0.050
sendsize[5630]: estimate size for /etc level 1: 120 KB
the same for level 1 even faster.
Next amanda tries /home_h0:
...
sendsize[5633]: time 1.051: calculating for amname '/home_h0', dirname
'/home', spindle -1
sendsize[5633]: time 1.051: getting size via gnutar for /home_h0 level 0
The runtar is the program that needs to be suid-root. Verify this
please. /home isn't an nfs-mount by accident? On a normal nfs-mounted
directory, root on the cleint becomes "nobody" on the server.
You have to specify special mount options on the nfs-server to get
root==root. See the "no_root_squash" option in the exports file.
sendsize[5633]: time 1.139: spawning /usr/local/libexec/runtar in pipeline
sendsize[5633]: argument list: /opt/sfw/bin/gtar --create --file /dev/null
--directory /home --one-file-system --listed-incremental
/usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_home_h0_0.new
--sparse --ignore-failed-read --totals --files-from
/tmp/amanda/sendsize._home__h0.20031113235902.include
Try to execute the above command line interactively, as root.
Does that work?
sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h0: No such
file or directory
sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h01: No
such file or directory
sendsize[5633]: time 1.173: /opt/sfw/bin/gtar: Cannot stat ./h02: No
such file or directory
sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h03: No
such file or directory
sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h039963: No
such file or directory
sendsize[5633]: time 1.175: /opt/sfw/bin/gtar: Cannot stat ./h039966: No
such file or directory
... (similar messages repeated) .
Do these directories/files actually exist? Or are they shortlived,
and between the time amanda expanded the "./h[0]*" in the file
/tmp/amanda/sendsize._home__h0.20031113235902.include and the time
that gtar was started. It's only a second (1.172 sec to be precise),
but these days computers can get really fast.
Also the message is "No such file or directory" instead of "Permission
denied". Usually I believe those error messages in Unix.
...
My disklist:
rozi.cab.u-szeged.hu/etcroot-tar
rozi.cab.u-szeged.hu/home_h0/home { # h0*
user-tar
include "./h[0]*"
}
...
rozi.cab.u-szeged.hu/home_rest /home { # the rest
user-tar
exclude "./h[0-9]*"
}
--
Paul Bijnens, XplanationTel +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, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***
Re: moved to new disk, now amanda wants to do level 0's on whole system
Hi, > The times reported by an ls -l seem to be sane, and of those perms I > checked, they were preserved ok. The major hiccup I had was that cp > doesn't do ".name" files Of course "cp" does copy dot-files. I think you may have stumbled over the shell asterisk. If you say "cp -rp * /somewhere", the shell expands the "*" to all files and dirs in that directory except those beginning with a dot! Try "echo *" - you get a list of the files in the current directory but without the dot files. You may use "cp * .??*" as a workaround (.??* means all filenames that begin with a dot but excludes ".." which would be too much), but that won't cover files like ".a" or similar dot-and-one-letter filenames. The better solution is the indicated "tar cf - ." which takes every file in the current directory (excluding the parent dir ".."). > and once went wild and copied the whole 2.5 > gig /root directory into /root/.ymessenger/root when I tried to make > it do it with a different wild card pattern. Maybe something like "cp * .*" which also includes ".."? ;-) > And links definitely weren't a problem that I've run into since the > drive switch. Maybe you haven't realized the problem yet. An ordinary "cp" will copy the file a symbolic link points to instead of the link. So it can happen that your copy becomes larger than the original as you create additional copies of files that had symbolic links pointing to them. You can run into serious trouble if you have users who use symlinks. To sum it up: Use tar. :-) Christopher -- == Dipl.-Ing. Christopher Odenbach HNI Rechnerbetrieb [EMAIL PROTECTED] Tel.: +49 5251 60 6215 ==
Re: backup lasts forever on large fs (fwd)
Still doesn't work. I've split the /home partition into several pieces as recommended in an earlier message (my disklist entries are included at the end). Since I havent' received the usual email report from amanda (why??), I went to /tmp/amanda to see the logs. It looks like sendsize is run with non-root privileges hence it cannot stat/read individual home directories (quite normal as they are restricted to the owner). This is what I found: sendsize: debug 1 pid 5628 ruid 103 euid 103: start at Thu Nov 13 23:59:01 2003 sendsize: version 2.4.4p1 sendsize[5628]: time 0.040: waiting for any estimate child sendsize[5630]: time 0.040: calculating for amname '/etc', dirname '/etc', spindle -1 sendsize[5630]: time 0.041: getting size via gnutar for /etc level 0 sendsize[5630]: time 0.063: spawning /usr/local/libexec/runtar in pipeline sendsize[5630]: argument list: /opt/sfw/bin/gtar --create --file /dev/null --directory /etc --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_etc_0.new --sparse --ignore-failed-read --totals . sendsize[5630]: time 0.959: Total bytes written: 3737600 sendsize[5630]: time 0.961: . sendsize[5630]: estimate time for /etc level 0: 0.897 sendsize[5630]: estimate size for /etc level 0: 3650 KB sendsize[5630]: time 0.961: waiting for /opt/sfw/bin/gtar "/etc" child sendsize[5630]: time 0.961: after /opt/sfw/bin/gtar "/etc" wait sendsize[5630]: time 0.971: getting size via gnutar for /etc level 1 sendsize[5630]: time 0.987: spawning /usr/local/libexec/runtar in pipeline sendsize[5630]: argument list: /opt/sfw/bin/gtar --create --file /dev/null --directory /etc --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_etc_1.new --sparse --ignore-failed-read --totals . sendsize[5630]: time 1.037: Total bytes written: 122880 sendsize[5630]: time 1.038: . sendsize[5630]: estimate time for /etc level 1: 0.050 sendsize[5630]: estimate size for /etc level 1: 120 KB sendsize[5630]: time 1.038: waiting for /opt/sfw/bin/gtar "/etc" child sendsize[5630]: time 1.038: after /opt/sfw/bin/gtar "/etc" wait sendsize[5630]: time 1.049: done with amname '/etc', dirname '/etc', spindle -1 sendsize[5628]: time 1.050: child 5630 terminated normally sendsize[5628]: time 1.051: waiting for any estimate child sendsize[5633]: time 1.051: calculating for amname '/home_h0', dirname '/home', spindle -1 sendsize[5633]: time 1.051: getting size via gnutar for /home_h0 level 0 sendsize[5633]: time 1.139: spawning /usr/local/libexec/runtar in pipeline sendsize[5633]: argument list: /opt/sfw/bin/gtar --create --file /dev/null --directory /home --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_home_h0_0.new --sparse --ignore-failed-read --totals --files-from /tmp/amanda/sendsize._home__h0.20031113235902.include sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h0: No such file or directory sendsize[5633]: time 1.172: /opt/sfw/bin/gtar: Cannot stat ./h01: No such file or directory sendsize[5633]: time 1.173: /opt/sfw/bin/gtar: Cannot stat ./h02: No such file or directory sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h03: No such file or directory sendsize[5633]: time 1.174: /opt/sfw/bin/gtar: Cannot stat ./h039963: No such file or directory sendsize[5633]: time 1.175: /opt/sfw/bin/gtar: Cannot stat ./h039966: No such file or directory ... (similar messages repeated) . sendsize[5633]: time 1.752: /opt/sfw/bin/gtar: Cannot add file ./h076564: No such file or directory sendsize[5633]: time 1.753: Total bytes written: 10240 sendsize[5633]: time 1.754: /opt/sfw/bin/gtar: Error exit delayed from previous errors sendsize[5633]: time 1.754: . sendsize[5633]: estimate time for /home_h0 level 0: 0.615 sendsize[5633]: estimate size for /home_h0 level 0: 10 KB sendsize[5633]: time 1.754: waiting for /opt/sfw/bin/gtar "/home_h0" child sendsize[5633]: time 1.754: after /opt/sfw/bin/gtar "/home_h0" wait sendsize[5633]: time 1.766: done with amname '/home_h0', dirname '/home', spindle -1 sendsize[5628]: time 1.768: child 5633 terminated normally sendsize[5628]: time 1.769: waiting for any estimate child sendsize[5635]: time 1.769: calculating for amname '/home_h1', dirname '/home', spindle -1 sendsize[5635]: time 1.769: getting size via gnutar for /home_h1 level 0 sendsize[5635]: time 1.868: spawning /usr/local/libexec/runtar in pipeline sendsize[5635]: argument list: /opt/sfw/bin/gtar --create --file /dev/null --directory /home --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/rozi.cab.u-szeged.hu_home_h1_0.new --sparse --ignore-failed-read --totals --files-from /tmp/amanda/sendsize._home__h1.20031113235903.include sendsize[5635]: time 1.894: /opt/sfw/bin/gtar: Cannot stat ./h141676: No such file or directory sendsize[5635]: time 1.895: /opt/sfw/bin/gtar: Cannot stat ./h141677: No such file or directory ... etc. ...
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Friday 14 November 2003 09:20, Jay Fenlason wrote: >On Fri, Nov 14, 2003 at 01:23:12AM -0500, Gene Heskett wrote: >> Greetings all; >> >> See subject, Which of course is leading to a 90% failure rate as >> the whole system has around 40Gb, but the tapes are only 4Gb's. >> >> What happened is that I put in a new 120 Gb drive, 2x the size of >> the one I took out, mainly because the root partition was full, >> and no room to readjust things was available. >> >> Although the /dev/whatevers have changed, the mountpoints have >> not. I used cp to copy some of the data, and fr to do some, seems >> cp cannot see a .file! >> >> I missed one run while the disk was being configured. One person >> said he had never swapped disks without doing a re-install, but I >> just did, and everything seems to be working just fine. Its >> tedious for sure, but it can be done. >> >> I have expanded the dumpcycle and runspercycle from 8 to 10 >> because it seemed amanda was having a hard time hitting its best >> balance point. tapecycle is still 28, but I can add more. >> >> So the disklist is unchanged. Why does amanda want to do a level >> 0 on the whole system? > >When you copied the files, the inode numbers for each file changed. >When gtar sees the inode number of a file change, it assumes the >contents of the file have changed too (it doesn't store md5sums of >file data or anything clever like that). Amanda sees that an >incremental is the same size as a level 0, so it tries to do a level >0. > >Also, cp/fr may not have correctly reset the modification times of > the files when it copied them. Oh, and they may not handle links > well either. To copy directory trees, I usually use "( cd /fromdir > ; tar cf - . ) | ( cd /todir ; tar xpf -)", which preserves > modification times, and permissions. Neat. I'll try to remember that. Looks like its pure memory for buffer usage. The times reported by an ls -l seem to be sane, and of those perms I checked, they were preserved ok. The major hiccup I had was that cp doesn't do ".name" files, and once went wild and copied the whole 2.5 gig /root directory into /root/.ymessenger/root when I tried to make it do it with a different wild card pattern. And links definitely weren't a problem that I've run into since the drive switch. >Hmm. How clever do you feel like being? If you can somehow get a >list of the files which have actually changed, you could edit the > last listed-incremental data file and update the inode numbers of > all the files you don't want to re-dump. It'd probably be an > amusing perl script. . . Chuckle... "Perl Script?" Doesn't she live in some town in New Mexico? :-) I have the utmost respect for Larry Wall, but I don't comprehend that language at all. Shell scripts, sometimes old basic, and plain old C, I've poked around in the kernel a few times, but perl? Nuh-huh... Its got voodoo spells in it I swear. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Fri, Nov 14, 2003 at 01:23:12AM -0500, Gene Heskett wrote: > Greetings all; > > See subject, Which of course is leading to a 90% failure rate as the > whole system has around 40Gb, but the tapes are only 4Gb's. > > What happened is that I put in a new 120 Gb drive, 2x the size of the > one I took out, mainly because the root partition was full, and no > room to readjust things was available. > > Although the /dev/whatevers have changed, the mountpoints have not. I > used cp to copy some of the data, and fr to do some, seems cp cannot > see a .file! > > I missed one run while the disk was being configured. One person said > he had never swapped disks without doing a re-install, but I just > did, and everything seems to be working just fine. Its tedious for > sure, but it can be done. > > I have expanded the dumpcycle and runspercycle from 8 to 10 because it > seemed amanda was having a hard time hitting its best balance point. > tapecycle is still 28, but I can add more. > > So the disklist is unchanged. Why does amanda want to do a level 0 on > the whole system? When you copied the files, the inode numbers for each file changed. When gtar sees the inode number of a file change, it assumes the contents of the file have changed too (it doesn't store md5sums of file data or anything clever like that). Amanda sees that an incremental is the same size as a level 0, so it tries to do a level 0. Also, cp/fr may not have correctly reset the modification times of the files when it copied them. Oh, and they may not handle links well either. To copy directory trees, I usually use "( cd /fromdir ; tar cf - . ) | ( cd /todir ; tar xpf -)", which preserves modification times, and permissions. Hmm. How clever do you feel like being? If you can somehow get a list of the files which have actually changed, you could edit the last listed-incremental data file and update the inode numbers of all the files you don't want to re-dump. It'd probably be an amusing perl script. . . -- JF
Re: moved to new disk, now amanda wants to do level 0's on whole system
On Friday 14 November 2003 04:37, Sven Rudolph wrote: >Gene Heskett <[EMAIL PROTECTED]> writes: >> What happened is that I put in a new 120 Gb drive, 2x the size of >> the one I took out, mainly because the root partition was full, >> and no room to readjust things was available. >> >> So the disklist is unchanged. Why does amanda want to do a level >> 0 on the whole system? > >Amanda does not want anything, it is the tar (or dump) below. > >GNU tar uses (among other things) the inode numbers in order to find >out whether a file has changed. So all files are detected as > changed. > > Sven I see. And its an hour past due to be done, and I have a report from the wrapper script indicating that it has run to completion, but no report from amanda herself. Odd indeed. There are still 4 files sitting in /dump, so I'd assume I need to run amflush. After I fix a couple of typo's in some additions I made to the disklist last night after amanda was up and running. I'd said leo for the interface, not le0. Running amcheck to see that the right tape is loaded, somehow its image of the slot number got munged and it reported this: - [EMAIL PROTECTED] amanda]$ amcheck DailySet1 Amanda Tape Server Host Check - Holding disk /dumps: 15096592 KB disk space available, using 14072592 KB amcheck-server: slot 3: date 20031114 label DailySet1-25 (active tape) amcheck-server: slot 0: date 20031114 label DailySet1-25 (active tape) amcheck-server: slot 1: date 20030815 label DailySet1-26 (exact label match) NOTE: skipping tape-writable test Tape DailySet1-26 label ok etc, etc -- A run of amreport /config/ by the user amanda returns empty! And also does as root, not even a blank line. Things are getting curiouser and curiouser... Ahh, that log file is a new one started by amflush. The log.20031114.0 ends with this, and is about 4 kilobytes shorter than a normal log: --- INFO taper tape DailySet1-25 kb 3957824 fm 13 writing file: No space left on device FAIL taper coyote /usr/bin 20031114 0 [out of tape] ERROR taper no-tape [[writing file: No space left on device]] WARNING driver going into degraded mode because of tape error. FINISH driver date 20031114 time 11716.522 --- So it appears I should rerun my indices saver script and let it append that to this next tape since there was not room for it in the normal run. Humm, I got a report from amflush at 6:06 saying there was nothing to flush, and another at 6:13 indicating it had cleaned up in /dumps, writing about 283 megs. I only ran it once! A du of /dumps shows that it overshot the tapesize by 290,272 blocks. This will be a week+ getting straightened out. :( I'm gonna tell it to use 2 tapes (whats left in the magazine) for tonights run. But I don't think my indices saver script can handle that. We'll see what I might have to do it it to handle that situation I guess ): But, I really, really think I've got snilmerg. Sigh -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Amdump Mail Report - Description
Just to pull the attention I reply to my own posting ... Any infos on this topic? on Dienstag, 11. November 2003 at 15:38 I wrote to amanda-users: SGW> Hi, amanda-users, SGW> I just talked to a customer about the various "times" in the Amanda SGW> Mail Report. SGW> There is the Estimate Time, Run Time, Dump Time, Tape Time SGW> I understand them pretty well, but I would like to know if and where SGW> the listed entries are described. (Would not hurt to see all the other SGW> entries described as well, even if most of them are no-brainers) SGW> For example, I only found out the meanings of Dump Time and Run Time SGW> via web research (which lead me to some mail of Jon LaBadie asking a SGW> similar question ... ;-) ). SGW> I looked through some manpages, but could not find it ... SGW> Thank you, SGW> Stefan G. Weichinger SGW> mailto:[EMAIL PROTECTED] best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
RESOLVED: was: Odd configuration error
> Hi, > > My amanda server for my DMZ ate its HDD today so i've been busy rebuilding > it - It has a HP autoloader and a single AIT-2 drive in it to run 2 > different a,anda configs. > > The single drive seems fine - I'm having issues with the changer. > > when i run an amcheck on this config i get.. > > amcheck-server: could not get changer info: no slots available > > and so i look in my config and i have my changer as sg2 > > i do > > $ mtx -f /dev/sg2 status > cannot open SCSI device '/dev/sg2' - No such device > > and > > $ ls -l /dev/sg* > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg0 -> sga > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg1 -> sgb > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg2 -> sgc > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg3 -> sgd > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg4 -> sge > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg5 -> sgf > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg6 -> sgg > lrwxrwxrwx1 root disk3 Nov 13 16:15 /dev/sg7 -> sgh > crwxrwxrwx1 root disk 21, 0 May 5 1998 /dev/sga > crwxrwxrwx1 root disk 21, 1 May 5 1998 /dev/sgb > crwxrwxrwx1 root disk 21, 2 May 5 1998 /dev/sgc > crwxrwxrwx1 root disk 21, 3 May 5 1998 /dev/sgd > crwxrwxrwx1 root disk 21, 4 May 5 1998 /dev/sge > crwxrwxrwx1 root disk 21, 5 May 5 1998 /dev/sgf > crwxrwxrwx1 root disk 21, 6 May 5 1998 /dev/sgg > crwxrwxrwx1 root disk 21, 7 May 5 1998 /dev/sgh > > below is my dmesg - any thoughts? I'm running this on 2.4.4 > > thanks > > SCSI subsystem driver Revision: 1.00 > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 > > aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > > scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 > > aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs > > scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 > > aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > > Vendor: SONY Model: SDX-500C Rev: 010c > Type: Sequential-Access ANSI SCSI revision: 02 > (scsi1:A:0): 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > Vendor: HPModel: C5713ARev: H107 > Type: Sequential-Access ANSI SCSI revision: 02 > (scsi2:A:4): 40.000MB/s transfers (20.000MHz, offset 32, 16bit) > Vendor: HPModel: C5713ARev: H107 > Type: Medium Changer ANSI SCSI revision: 02 > st: Version 20020805, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs > 16 > Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0 > Attached scsi tape st1 at scsi2, channel 0, id 4, lun 0 > To answer myself i have sorted it - not _exactly_sure what the issue was but i decided to rebuild my fresh kernel to see if i missed anything out - Did not alter anything but this one seems to work a treat. Perhaps the build messed up somewhere. Note to self - check the obvious before posting! thanks Tom
Re: moved to new disk, now amanda wants to do level 0's on whole system
Gene Heskett <[EMAIL PROTECTED]> writes: > What happened is that I put in a new 120 Gb drive, 2x the size of the > one I took out, mainly because the root partition was full, and no > room to readjust things was available. > So the disklist is unchanged. Why does amanda want to do a level 0 on > the whole system? Amanda does not want anything, it is the tar (or dump) below. GNU tar uses (among other things) the inode numbers in order to find out whether a file has changed. So all files are detected as changed. Sven
Re: amanda article on sun.com
Jon LaBadie wrote: http://www.sun.com/bigadmin/features/articles/backups_amanda.html In the example config file we find these strange (wrong) values: > dumpcycle 3 weeks # the number of days in the normal dump cycle > > runspercycle 8 # the number of amdump runs in dumpcycle days > # (4 weeks * 5 amdump runs per week -- just weekdays) > > tapecycle 12 tapes # the number of tapes in rotation (as an excuse, they only have dumptypes where "dumpcycle 0" overrides the dumpcycle of 3 weeks - so everything is a full backup, and then "runspercycle" does not matter much any more.) I'm expecting to get a lot of questions about the meaning and relationships between these three parameters :-) And the comments don't help clarify this either. Just for the beginners, here are some more reasonable values: dumpcycle 1 week runspersycle 5 tapecycle 12 tapes -- Paul Bijnens, XplanationTel +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, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
