Date: Sun, 04 Jan 1998 18:45:19 +0100 From: Palle Girgensohn <girgen@partitur.se> To: Jason Hudgins <jasonh@cei.net> Cc: questions@FreeBSD.ORG Subject: Re: Good backup hardware for FreeBsd? Message-ID: <34AFCAAF.17DDFD41@partitur.se> References: <005401bd1887$d6308ec0$7a76b4cc@thanatosis>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Jason, I too get it to work from cron as long as dump (run from a script) doesn't require user interaction. dump want's some answers when an error or tape-end, for example, occurs, and fails with "fopen on /dev/tty" when it doens't have a tty attached. Try running your script from the console. I would strongly recommend using the 'a' option with a DAT or cartridge tape driver. dump needs some kind of info as to what kind of tape it uses. I'm using dump 0uabBf 64 4000000 /dev/nrst0 /usr The 'b 64' is for rdumps, they get painfully slow otherwise, and I find it easy to have the same buffer size for all dumps, wheather local or remote. 'B 4G' solves my problem of not getting proper end-of-tape signal. You probably don't need these two, but do use the 'a' option. This might not help for you, though. There shouldn't be a problem using a DAT as long as it is SCSI. You do rewind tapes between uses? maybe you should try retension (mt ret)? Sorry I can't more helpful. Regards, Palle Jason Hudgins wrote: > > >I'm in a similar situation. What happens for you is that the tape has > >reached the end (my guess; I get write errors when I reach > >end-of-tapes), and is trying to tell you this on the tty; "fopen on > >/dev/tty" means that it cannot talk to a console, probably because > >you're running it from cron, or detached the dump process from the >tty. > > I don't think this is the case, because some of the time it actually works, > just > not often. And it dies at random times, sometimes at say 25% sometimes at > 85%, ...etc...etc. > > >AFAIK, you can't run dump from cron, at least not directly. (I'd like to > >hear from you folks! How do you make automated dumps?) Dump needs >user > interaction when an error or end-of-tape occurs, or it will get > >suspended or fail. > > Again, I've gotten it to work from cron, though I've never tried to call > dump > from cron directly. My cronjob calls a perlscript that first rewinds the > tape, and > then does a dump of /usr to /dev/nrst0. The perl script redirects the > output > of dump and logs it into a PostgresSQL database, which I then can > examine from some web pages.. Its a pretty nice setup, but then again, I > only get a successful backup about 15% of the time. When I originally > had it setup, for the first two weeks, it was working 100% everyday, but > then it started failing, and now it hardly ever works. I use a different > tape every day of the week, and they are 4 gig cartridges. My whole /usr > filesystem maybe has about 2 gigs of data on it.. > > >What does your dump command look like? If your tape can swallow no more > >than 2GB, you've reached the end-of-tape. Using the B option, yuo can > >tell dump about the tape lenght, and get "tape-end" instead of > >"write-error". If you expect hardware compression, are you sure it is > >switched on? Probably not? > > something like this, (from memory) > dump -0uf /dev/nrst0 /usr > > I'm not opposed to purchasing new backup hardware if anyone has any solid > suggestions. Of course I still haven't completely determined if its a > hardware > failure, but that my best guess.. > > Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34AFCAAF.17DDFD41>