fileserver "best practice" - Unix

This is a discussion on fileserver "best practice" - Unix ; hi, i am setting up a nfs/netatalk2 fileserver (debian) for about 50 clients. the system is up and running, as it won't be rebooted too often, i wrote a script, executed weekly by cron, that does a "stop daemons / ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: fileserver "best practice"

  1. fileserver "best practice"



    hi,

    i am setting up a nfs/netatalk2 fileserver (debian) for about 50 clients.

    the system is up and running, as it won't be rebooted too often, i wrote
    a script, executed weekly by cron, that does a "stop daemons / umount
    volumes / e2fsck -fy / mount volumes / start daemons" as well as an
    "acleandir" (remove orphan adouble files) for all exports.

    apart from all the security/backup/redundancy-issues (solved well, i
    hope i would like to ask for some opinion of more experienced admins
    than i am:

    - is this solution sufficent to "guarantee" the consistency
    of the strored data?
    - are there other checks, that make sense to be performed
    regularly?
    - is there something like a "fileserver best practice"?

  2. Re: fileserver "best practice"

    rolf randen wrote:
    >
    > hi,
    >
    > i am setting up a nfs/netatalk2 fileserver (debian) for about 50 clients.
    >
    > the system is up and running, as it won't be rebooted too often, i wrote
    > a script, executed weekly by cron, that does a "stop daemons / umount
    > volumes / e2fsck -fy / mount volumes / start daemons" as well as an
    > "acleandir" (remove orphan adouble files) for all exports.
    >
    > apart from all the security/backup/redundancy-issues (solved well, i
    > hope i would like to ask for some opinion of more experienced admins
    > than i am:
    >
    > - is this solution sufficent to "guarantee" the consistency
    > of the strored data?
    > - are there other checks, that make sense to be performed
    > regularly?
    > - is there something like a "fileserver best practice"?


    If you trust your file system / operating system,
    then you don't do an fsck at all.


    --
    Michael Tosch @ hp : com

  3. Re: fileserver "best practice"

    In article <4725E5D5.5090905@gmx.net>, rolf randen wrote:
    >the system is up and running, as it won't be rebooted too often, i wrote
    >a script, executed weekly by cron, that does a "stop daemons / umount
    >volumes / e2fsck -fy / mount volumes / start daemons" as well as an
    >"acleandir" (remove orphan adouble files) for all exports.


    Why? Is something broken that this cleans up? If you really need to do this
    weekly, you've got serious problems. Do it by hand once a year, or whenever
    you need to bring the system down for other reasons.

    Also, I STRONGLY advise against automated fsck -y. If your system is
    corrupted, you want to know it BEFORE fsck tries to help and makes it worse.
    If you must, you can do e2fsck -fn, and call for help if it exits nonzero.

    >- is this solution sufficent to "guarantee" the consistency
    > of the strored data?


    No. In a well-functioning system this will do nothing. In a b0rked system,
    it will not fix the problem, though it may hide it for awhile until it gets
    bad enough to not recover at all.

    >- is there something like a "fileserver best practice"?


    I wish. Far too much is trial-and-error on small systems, and just trusting
    the base install until it blows up. Honestly, the base install on most modern
    systems is pretty good, but things like backup, log rotation, system
    monitoring, etc. can never be complete or easy enough.
    --
    Mark Rafn dagon@dagon.net

  4. Re: fileserver "best practice"

    Mark Rafn wrote:
    > No. In a well-functioning system this will do nothing. In a b0rked system,
    > it will not fix the problem, though it may hide it for awhile until it gets
    > bad enough to not recover at all.


    i think, cron will tell me about fixed fs's (as the script should return
    non-zero) but your suggestion to look at the problem before fixing the
    symptoms sounds reasonable, thank you!

    with best regards,

    rolf

+ Reply to Thread