toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

chown behaviour on filer NFS mounts -- help!
by Jason Ruiter 14 Apr '00

14 Apr '00

Greetings, How should chown (or fchown) behave when used on an NFS mounted filer share? I'm trying to set up an anonymous FTP server, using an NFS mounted directory as my file space. It works fine, until I try to configure anonymous uploading. Whenever I try this, I get a "fchown: not owner" error. I look at the code (wu-ftpd 2.6) and it looks like it fails on a series of fchown calls. How can I expect fchown to work? Is this OS dependent? Does the filer respond to these calls in a predictable way? I have a 720 running DataOnTap 5.3.2R1. Thank you. Jason Ruiter Systems Administrator jruiter(a)erim.org

2 1

RE: chown behaviour on filer NFS mounts -- help!
by Fox, Adam 14 Apr '00

14 Apr '00

> Greetings, > > How should chown (or fchown) behave when used on an NFS > mounted filer share? > > I'm trying to set up an anonymous FTP server, using an NFS > mounted directory > as my file space. It works fine, until I try to configure anonymous > uploading. Whenever I try this, I get a "fchown: not owner" > error. I look > at the code (wu-ftpd 2.6) and it looks like it fails on a > series of fchown > calls. > > How can I expect fchown to work? Is this OS dependent? Does the filer > respond to these calls in a predictable way? > > I have a 720 running DataOnTap 5.3.2R1. By default, only root can chown files. There is an option called wafl.root_only_chown which is set to on by default. If you turn it off and have a client that allows non-root users to chown (most modern version of UNIX do, SunOS 4.x, for example does not), then the owner of the file can chown a file as well. Now, if your ftpd is running as root, you have to be sure that the filesystem is exported with root permissions to the ftp server. Otherwise, the filer (actually any NFS server) will map root (uid 0) to nobody. Nobody will probably never own files so the process would receive a "Not Owner" message even though the process is running with an effective UID of 0. I haven't looked at the ftpd code in a while, but this is my first guess based on the info you provided. Hope this helps. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

1 0

RE: Disk-to-disk backups? (was Re: Need new backup solution)
by Bond, Andrew 14 Apr '00

14 Apr '00

Hi Bruce, I'm not clear how a hacker could destroy data in snapshots - remember that they are read-only, and that's why they have proved useful in cases of virus attack. Anyone who has used tapes much will know that it's not that unusual to have problems retrieving the data, quite apart from the management of the tapes and backup software. I think the issue between use of tapes or disk for backup revolves mainly around archival. Snapshots will give you maybe a few weeks of backups, and SnapMirror can replicate this for disaster recovery, but if you need to archive for either legal reasons, or because your data is volatile (high rate of change) or needs to be kept for a long time, the amount of disk required may be too large for your computer suite, and removable media is still necessary. This issue is discussed further in a White Paper at http://www.netapp.com/tech_library/3066.html Regards, Andrew > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Bruce Sterling > Woodcock > Sent: 13 April 2000 22:58 > To: Fred Ab; toasters(a)mathworks.com; bet(a)rahul.net > Subject: Re: Disk-to-disk backups? (was Re: Need new backup solution) > > > Not only that, but if a hacker breaks in and all your backups > are online, they can just as easily destroy them too. Or they > can become corrupted due to a failure. Tapes are much more > stable (unless you pass a magnet over them) and you can > store them, as you said, offsite. > > Snapshots are great for near-term recovery, and mirrors > are even good for single-point disasters, but you always > want tapes available in the event of a catastrophe. > > Bruce > > >

1 0

How do I move /vol/vol0?
by Cliff Nadler 14 Apr '00

14 Apr '00

I'm in a situatio where we have one F760 with 4 shelves of 9Gb SCSI disk, and three shelves of 36Gb FC attached disks. The FC disks were added later, so the original install of vol0 was done to the SCSI disks. We'd like to get rid of the SCSI disks (and use one shelf of FC to hold it), but I'm concerned since we have /vol/vol0 on it. Has anyone moved /vol/vol0 off SCSI to FC before, and if so, what problems did you run into? Thanks, -- -------------------------------------------------------------------------- Cliff Nadler Collective Technologies, Inc. (a Pencom Company) cnadler(a)colltech.com (617)-443-1144 -------------------------------------------------------------------------- To win, you must treat a pressure situation as an opportunity to succeed, not an opportunity to fail Gardner Dickinson

1 0

Manual time change while using NTP...
by Eyal Traitel 14 Apr '00

14 Apr '00

Hi ! Just wanted to share with you that these steps seems to help when trying to change time manually (if you need to change time more than the timed.max_skew...) - 1. rsh toaster0 options timed.enable off 2. rsh toaster0 rdate timehost 3. rsh toaster0 options timed.enable on Pls. comment / whatever, Eyal.

2 2

Need new backup solution
by Brian Hostetter 14 Apr '00

14 Apr '00

Hi, We have been facing some explosive growth during the past 6 months and have grown past our current backup solution. We are currently backing up via a linux box that has our 740 nfs mounted. Backups are taking sometimes 24-30 hours for incrementals and all weekend for fulls. What I am looking for is info on how others are backing up 200G volumes on 740's or 760's. I just purchased a pair of 760's and am going to need a nice stable reliable backup system for them. Ideas? --Brian

8 10

Oracle Parallel Server on Filer?
by Dave Mills 14 Apr '00

14 Apr '00

Filer users, Has anyone implemented OPS on multiple NFS clients? Isn't this the product that would be required if multiple simultaneous updates to the same Oracle instance is needed? Is this a certified solution? How does file and record locking work in an OPS/Filer environment? Dave Mills Cypress Systems, LTD.

3 2

RE: Need new backup solution
by Ernst.Bokkelkamp＠mchh.siemens.de 14 Apr '00

14 Apr '00

Unfortunately this is all just theory. The reality is a bit different. You forgot that every packet on the network has to be processes and transported over multiple busses before it reaches the tape drive. These times add up to quite a bit. I have Gigabit ethernet, I have powerfull backup machines that perform at 20 Mbyte/sec on backup of ordinary Windows NT servers over LAN. These machines backup about 1.5 TB spread over 100+ servers in about 20 hours. But afte many tests the same machine with Gigabit Ethernet has only been able to backup a single filer with 4 volumes @ 139GB at a rate of about 48 GB/Hour.The Gigabit idles at that throughput. The equation that Gigabit is 10x Fast Ethernet does not work on a point-to-point situation. Bye Ernie > -----Original Message----- > From: Jay Orr [SMTP:orrjl@stl.nexen.com] > Sent: Thursday, April 13, 2000 11:22 PM > To: toasters(a)mathworks.com > Subject: RE: Need new backup solution > > On Thu, 13 Apr 2000, Schepers, Jan wrote: > > > Looking at the responses sofar, most of you agree on: > > o directly attached tape devices and > > o the use of NDMP software > > If I may put my 2 cents worth in... > > First of all as I understand NDMP (which isn't that well - feel free to > enlighten me if I'm mistaken) it's just a different standard of dump of > sorts, so other then being able to dump a netapp directly connected tape > drive there is no advantage to using it (i.e. if you're backing up over a > network, same performance of dump vs. NDMP backups). This would put the > two points above together as one. > > Second, direct connect isn't necessarly the fastest - for instance, many > tape drives have throughput of less then 10M Bytes/sec. If you have 100Mb > ethernet, thats ~11M Bytes/sec, so you're getting the same throughput and > the bottleneck is still the tape drive. If you have a seperate "backup" > network of 100Mb ethernet and backup through the network, time is saved if > you use a backup package that interleaves backups (i.e. combines backup > streams) - then the tape drive isn't waiting for one machie to feed it > data. Kick this up to Gigabit and you would outperform the tape drive. > Also, with this method you have less unused backup media and better media > inventory management. > > However, there are things that can affect throughput of networked backups > - NFS latencies, traffic on the ethernet, etc. > > SO, as I see it, there isn't really a quick-and-dirty rule of thumb on > this. The factors that would have to be considered are : > > 1) Tape throughput > 2) Network throughput > 3) Backup software methodology. > > all of these weigh close to equal in the equasion of "what's the best > way to do it", so unfortunately I don't see an easy rule of thumb.. > > Of course, I'm never one to trust an easy answer either - so maybe it's > just me ;p > > ----------- > Jay Orr > Systems Administrator > Fujitsu Nexion Inc. > St. Louis, MO

1 0

Re: Disk-to-disk backups? (was Re: Need new backup solution)
by Bruce Sterling Woodcock 14 Apr '00

14 Apr '00

Not only that, but if a hacker breaks in and all your backups are online, they can just as easily destroy them too. Or they can become corrupted due to a failure. Tapes are much more stable (unless you pass a magnet over them) and you can store them, as you said, offsite. Snapshots are great for near-term recovery, and mirrors are even good for single-point disasters, but you always want tapes available in the event of a catastrophe. Bruce

3 2

Re: Disk-to-disk backups? (was Re: Need new backup solution)
by Fred Ab 13 Apr '00

13 Apr '00

If your place burns down you are not just down but out of business. Tapes are tangible and can be stored offsite. ===}From: Bennett Todd <bet(a)rahul.net> ===}To: toasters(a)mathworks.com ===}Subject: Disk-to-disk backups? (was Re: Need new backup solution) ===}Date: Thu, 13 Apr 2000 13:13:15 -0700 ===}Mime-Version: 1.0 ===} ===}I'm curious about something here. ===} ===}First, some background. I recently set up a backup system I really, ===}really like. It's on a Linux fileserver, no netapps in this ===}picture. It's backing up c. 60GB of disk, a single root drive and a ===}50GB RAID-5 with a hot spare, to another RAID-5 set, about 130GB, ===}with no hot spare. I have a cronjob set to email me if a drive drops ===}out of the set. I backup with a script that replicates all the ===}data to be saved onto the backup raid set, using rsync, with the ===}--backup-dir option to save anything that's been changed or deleted; ===}then it takes all those changed-or-deleted files and bzip2s them ===}into timestamped archives. When the backup partition gets over ===}90% full it commences deleting those bzip2-ed archives, starting ===}with the oldest, until it's back down under 80% full. This gives me ===}months of coverage and I never have to change a tape, and the cost ===}of the drives is less than the cost of a suitable capacity tape ===}drive to back up 60GB of data. ===} ===}So anyway, enough with background, the question is, how come I don't ===}hear anyone advocating using Netapp's snapshots as a backup ===}strategy? Netapps don't lose data; it's not like WAFL or Netapp's ===}RAID or any other bits are so bug-ridden that they don't do their ===}job. ===} ===}And you can buy a _Load_ of drives for what a heavy-duty ===}industrial-strength DLT jukebox costs. Especially when you factor ===}in the setup time, and the re-setup time every time it breaks. The ===}Exabyte 8200 was the only tape drive I ever set up that didn't die ===}before I switched jobs; seems like MTBF for a drive writing a tape ===}a day is well under a year, at least in my experience in the last 6 ===}years or so. Bleech. ===} ===}-Bennett

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters