Re: Is it possible: using ftp share as holding disk/diskbackup ?
On Tuesday 04 January 2005 20:05, [EMAIL PROTECTED] wrote: >Hi everybody! > >We have recently rented a root server in germany and installed > debian sarge on it. A ftp share as large as the install HD is > included in the server package accessable authenticated. > >My question is: Is it possible at the time now to write the amanda > backup directly onto the ftp share (AKA as holding disk)? Are there > any options (usermount programs) to mount the ftp share as a > "virtual" holding disk and has this whole procedure ever been > executed successfully and documented? > >I'd like to use this kind of "tapes"... > >Greeting from Austria > >Vlad Popa If that share is mountable with the std mount command, I believe it can work as a vtapes like repository. However, if its to be mounted as a samba share, probably not, mainly because samba throws away so much information about the attributes of a file. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Is it possible: using ftp share as holding disk/diskbackup ?
Title: Is it possible: using ftp share as holding disk/diskbackup ? Hi everybody! We have recently rented a root server in germany and installed debian sarge on it. A ftp share as large as the install HD is included in the server package accessable authenticated. My question is: Is it possible at the time now to write the amanda backup directly onto the ftp share (AKA as holding disk)? Are there any options (usermount programs) to mount the ftp share as a "virtual" holding disk and has this whole procedure ever been executed successfully and documented? I'd like to use this kind of "tapes"... Greeting from Austria Vlad Popa
Re: A question regarding backing up Window machines
On Tue, Jan 04, 2005 at 02:42:13PM -0800, Joe Rhett wrote: > On Mon, Dec 20, 2004 at 04:02:49PM +0100, Paul Bijnens wrote: > > - You can exclude only one pattern. > > Um, hello -- can you clue me in on this? I am trying (lazily) to figure > out why my excludes are ignored during backups, but work just fine when I > run the same tar command by hand. I need to add some debugging code, and > just haven't found the time. Have you clued into something I've missed? > Joe, could you give us your example exclude (note it is singlular) pattern that fails with amanda dumps but works with smbclient. Also the path to file(s) on the window machine that is excluded properly by smbclient but gets included by amanda. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: parse of reply message failed?
Steve Wray wrote: Hi there, I've been reading this thread; http://www.mail-archive.com/amanda-users@amanda.org/msg27491.html which is interesting because we've been experiencing a very similar problem since upgrading 2.6.8 to 2.6.9 on a small cluster here. The amanda connection tracking is all built into the kernel, not modules; but it was like that when the backups worked. CONFIG_PACKET_MMAP was disabled in both the amanda-working and non-working kernels. In fact, there don't seem to be a lot of differences between these kernels. I'll attach the diff here in case it helps! The ones prefixed wth '-' is the non-amanda-working config, the ones with the '+' are the amanda-working config. I'm hoping that we can get this going without having to install a new kernel... Any ideas? Following up to my own post, it turns out that with kernel 2.6.8 the interaction between the amanda 2.4.2p2 'server' (in debian woody) and the amanda 2.4.4p3 client (in debian sarge) works, whereas when the client is running 2.6.9 this interaction breaks down in the manner described. I found a woody backport of amanda 2.4.4p3 here; http://www.localguru.de/debian/woody/amanda/ and applied this to the backup server; everything now works.
Re: A question regarding backing up Window machines
On Mon, Dec 20, 2004 at 04:02:49PM +0100, Paul Bijnens wrote: > - You can exclude only one pattern. Um, hello -- can you clue me in on this? I am trying (lazily) to figure out why my excludes are ignored during backups, but work just fine when I run the same tar command by hand. I need to add some debugging code, and just haven't found the time. Have you clued into something I've missed? -- Joe Rhett Senior Geek Meer.net
Re: OT: which tape technology/drive to use
On Tue, 4 Jan 2005 at 6:48pm, Eugen Leitl wrote > I'm looking at DLT for a successor (40/80 GB DLTVS from IBM, or a PV > 110T 80/160 GB DLT VS160 from Dell. > > Is DLT a sensible choice at this day and age? Any caveats with above > drives, if any? Sorry for the dumb questions, but I have only very > limited experience with tape backups. If I were looking these days, I'd look hard at LTO or LTO2. I don't know what the cost is vs. DLT, but LTO has some nice features (like a hardware compression algorithm that actually recognizes incompressible data and doesn't try to compress it (and waste tape)). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: OT: which tape technology/drive to use
On Tue, 2005-01-04 at 18:48 +0100, Eugen Leitl wrote: > Is DLT a sensible choice at this day and age? Any caveats with above > drives, if any? Sorry for the dumb questions, but I have only very > limited experience with tape backups. I'm not real experienced either. but I just went from DDS4 to DLT (VS160 from Quantum), and I like it a whole lot. The drive is expensive and the tapes cost a fortune, but I had the same complaint about DDS longevity you do, and from my research, I'm expecting DLT to be a significant improvement. The VS160 is also a whole lot faster. On my system, IDE disks (DMA, idebus=66) couldn't stream it -- SCSI and SATA can. One note: If you go with DLT anything like mine, be *sure* to keep a decent airflow on it or it will get awfully hot. -- Glenn English [EMAIL PROTECTED]
OT: which tape technology/drive to use
Sorry for an off-topic question, but I figure this is the forum where I would get the best reponses. My employer's backup server has bitten the dust after some 5-6 years of faithful use, so I'm currently shopping for a replacement system(s; plural since we're getting an identical couple to minimize downtime). We've been using DAT (DDS3) systems, which were not very satisfactory in regards to cartrige and drive longevity both (the server room is unfortunately quite dusty, for time being). I'm looking at DLT for a successor (40/80 GB DLTVS from IBM, or a PV 110T 80/160 GB DLT VS160 from Dell. Is DLT a sensible choice at this day and age? Any caveats with above drives, if any? Sorry for the dumb questions, but I have only very limited experience with tape backups. TIA, Eugen Leitl
Re: level insensitivity for iso images
On Tuesday 04 January 2005 08:01, Benjamin Lewis wrote: >Gene, > >> I'm noting this in the email reports amanda sends me, where it >> doesn't make any diff what the runlevel is, its backing up the >> whole iso image for all levels. > >[...] > >> coyote -sc/FC3/FC3-i386-SRPMS-disc1.iso 1563563 -- >> 3:1 3005.2 2:3 3787.3 > >[...] > >Am I interpreting this correctly: you have individual files listed > in the disklist? If so, I'm not sure how else GNUtar could respond. > A level 1 backup of an individual file doesn't make much sense to > me. I did that at one point so I could add them one by one without spoiling the schedueling that badly, but I see your point and I'll reduce it to the directory itself. >Reading between the lines of the incremental archive format >description in the GNUtar info pages, it seems to me that the >incremental options to GNUtar are likely to depend on having a >directory entry in the tar file. > >I would expect that you might see small incrementals if you > specified the FC3 directory in the disklist rather than the > individual files themselves. > >-Ben Thanks Ben, one more time the forest got in the way of seeing the trees... :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: re-labelling or duplicating a tape?
In a message dated: Tue, 04 Jan 2005 09:17:19 +0100 Gerhard den Hollander said: >2) even easier and cheaper >when you store the tape, in the tape box (and on the tape and on the paper >insert that comes with the tape) simply write that this set only has one >tape. This is what my fall back plan was :) Thanks, -- Seeya, Paul GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE If you're not having fun, you're not doing it right!
Re: re-labelling or duplicating a tape?
In a message dated: Mon, 03 Jan 2005 16:49:47 EST Jon LaBadie said: >As an alternative, couldn't you change the human aspect of the problem? Sure, and that was my fall back plan in case a techical solution wasn't feasible. But I felt it was at least worth asking about :) Thanks! -- Seeya, Paul GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE If you're not having fun, you're not doing it right!
Re: level insensitivity for iso images
Gene, > I'm noting this in the email reports amanda sends me, where it doesn't > make any diff what the runlevel is, its backing up the whole iso > image for all levels. [...] > coyote -sc/FC3/FC3-i386-SRPMS-disc1.iso 1563563 --3:1 > 3005.2 2:3 3787.3 [...] Am I interpreting this correctly: you have individual files listed in the disklist? If so, I'm not sure how else GNUtar could respond. A level 1 backup of an individual file doesn't make much sense to me. Reading between the lines of the incremental archive format description in the GNUtar info pages, it seems to me that the incremental options to GNUtar are likely to depend on having a directory entry in the tar file. I would expect that you might see small incrementals if you specified the FC3 directory in the disklist rather than the individual files themselves. -Ben -- Benjamin Lewis <[EMAIL PROTECTED]> Security Analyst, Identity and Access Management IT Security and Privacy Purdue University
level insensitivity for iso images
Greetings; I'm noting this in the email reports amanda sends me, where it doesn't make any diff what the runlevel is, its backing up the whole iso image for all levels. As an iso image thats been laying there for months isn't going to change unless the file attribs say it has, why is amanda doing this? >From the email: coyote -sc/FC3/FC3-i386-SRPMS-disc1.iso 1563563 --3:1 3005.2 2:3 3787.3 coyote -sc/FC3/FC3-i386-SRPMS-disk2.iso 1563563 --2:2 3960.9 2:3 3778.4 coyote -sc/FC3/FC3-i386-SRPMS-disk3.iso 0562562 --2:3 3624.3 2:2 3965.6 coyote -sc/FC3/FC3-i386-SRPMS-disk4.iso 0562562 --2:3 3708.1 0:4 11858.3 coyote -lds-misc/FC3/FC3-i386-disc1.iso 1617617 --2:4 3729.3 2:4 3941.5 coyote -lds-misc/FC3/FC3-i386-disk2.iso 1638638 --3:1 3368.0 2:5 3665.4 coyote -lds-misc/FC3/FC3-i386-disk3.iso 1637637 --2:5 3682.6 3:3 3084.0 coyote -lds-misc/FC3/FC3-i386-disk4.iso 1386386 --1:4 3865.6 0:3 10250.7 coyote --misc/FC3/FC3-i386-rescuecd.iso 1 76 76 --0:2 3790.3 0:0 80085.2 Its effectively wasteing around 4Gb of a 9GB virtual tape every night. Nothing in the specified dumptype should be restricting it to always-full. For this, it should be happy with one level 0 per dumpcycle with incrementals of zero bytes. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
