Professional Web Applications Themes

mksnap_ffs woes - FreeBSD

Andrea Venturoli wrote on Wednesday 30 March 2005 15:42 in the group list.freebsd.questions:   The firsts line of your script contains an error: mksnap_ffs mountpoint snapshot_name The mksnap_ffs utility creates a snapshot named snapshot_name on the file system mounted at mountpoint. The snapshot_name argument must be con- tained within the file system mounted at mountpoint. So it should be: mksnap_ffs /usr /usr/any_path...

  1. #1

    Default Re: mksnap_ffs woes

    Andrea Venturoli wrote on Wednesday 30 March 2005 15:42 in the group list.freebsd.questions:
     

    The firsts line of your script contains an error:

    mksnap_ffs mountpoint snapshot_name

    The mksnap_ffs utility creates a snapshot named snapshot_name on the file
    system mounted at mountpoint. The snapshot_name argument must be con-
    tained within the file system mounted at mountpoint.


    So it should be:

    mksnap_ffs /usr /usr/any_path


    Kees Guest

  2. #2

    Default mksnap_ffs woes

    Hello.

    I've got some scripts like the following:

    /sbin/mksnap_ffs /usr /tmp/snapshot
    /sbin/mdconfig -a -t vnode -f /tmp/snapshot -u 0
    /sbin/mount -r /dev/md0 /usr/local/etc/snapmnt
    .... (backup data, transfer data, do anything)
    /sbin/umount /usr/local/etc/snapmnt
    /sbin/mdconfig -d -u 0
    /bin/rm -f /tmp/snapshot



    This will sometimes more or less lock my system, since every write
    access to /usr gets stuck.

    ps or top show mksnap_ffs running, but apparently doing nothing, and
    every attempt to kill it will fail. Not even a clean shutdown is possible.



    Any hint?



    bye & Thanks
    av.
    Andrea Guest

  3. #3

    Default Re: mksnap_ffs woes

    On Wed, Mar 30, 2005 at 02:42:41PM +0100, Andrea Venturoli wrote: 

    mksnap_ffs may sometimes take a long time (order of tens of minutes)
    to generate the snapshot. During this time, other writes to the
    filesystem may be suspended. Are you sure this isn't what you're
    seeing?

    Kris

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.0 (FreeBSD)

    iD8DBQFCSqziWry0BWjoQKURAgVpAJ9VOChQGvDxG058YZjDrF o1/JizNQCeKgnc
    vlO1HpaIdd3FLskGsTVFFkA=
    =X/Ef
    -----END PGP SIGNATURE-----

    Kris Guest

  4. #4

    Default Re: mksnap_ffs woes

    Andrea Venturoli wrote on Wednesday 30 March 2005 17:39 in the group list.freebsd.questions:
     
    >
    > Ugh, yes, sorry.
    > While simplifying the script I removed the /usr part from the path.
    > The real scripts read as you say they should.[/ref]

    I should have known better, because it gives an error messages
    if you try it like that.

    In FreeBSD-5.2.1 the snap_ffs is a little corrupt.
    You should upgrade to 5.3


    Kees Guest

  5. #5

    Default Re: mksnap_ffs woes

    On Wed, Mar 30, 2005 at 05:08:24PM +0100, Andrea Venturoli wrote: 
    >
    > I am not sure, but I don't think so.
    >
    > First of all, while I would not expect an exactly deterministic
    > behaviour, I still find it strange that most of the times it works
    > within seconds, and occasionally it might need so long! Then again, I do
    > not have enough insight to explain why it would or why it shouldn't.[/ref]

    It's possible you're seeing deadlock bugs in the snapshot code; you'd
    need to compile your system with DDB support and obtain traceback
    information as described in the developers' handbook chapter on kernel
    debugging.
     

    The snapshot code was intended to support background fsck and that
    alone. It's also optionally used by the dump code, but it was not
    written as a general-purpose live filesystem snapshot service.
     

    Plenty, if you don't demand an instantaneous image of the backup
    image.
     

    The pros and cons of the snapshot code have been discussed on the
    mailing lists, and there is a (slightly outdated) information file
    here: /usr/src/sys/ufs/ffs/README.snapshot

    Kris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.0 (FreeBSD)

    iD8DBQFCSrS6Wry0BWjoQKURApazAJ9q9D562ygA6L9HrDMJkG 0YgGbzzACdGQdJ
    7gU8/2dKSsMgjdhXVSddfZw=
    =xQ8J
    -----END PGP SIGNATURE-----

    Kris Guest

  6. #6

    Default Re: mksnap_ffs woes

    Kees Plonsz wrote:
     

    Ugh, yes, sorry.
    While simplifying the script I removed the /usr part from the path.
    The real scripts read as you say they should.

    bye & Thanks
    av.
    Andrea Guest

  7. #7

    Default Re: mksnap_ffs woes

    Kees Plonsz wrote:
     

    Nevermind.


     

    I am using 5.3.



    bye & Thanks
    av.
    Andrea Guest

  8. #8

    Default Re: mksnap_ffs woes

    On Wed, Mar 30, 2005 at 06:59:22PM +0100, Andrea Venturoli wrote:
     
    >
    > Ok.
    > I just think that this, as well as the disclaimer about it being alpha
    > code and the access locks, should be mentioned in the Handbook. Reading
    > that chapter or mksnap_ffs's manual, I didn't get it and I suspect
    > people might get the idea that it is stable code, which provides some
    > functionality that it doesn't.[/ref]

    The 'alpha' part is what I meant about this file being out of date.
    It is stable and widely used, but that doesn't mean there are not
    bugs.
     

    Isn't this usually done by dumping the database state and then backing
    that up, instead of trying to back up the live database?

    Kris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.0 (FreeBSD)

    iD8DBQFCSs5kWry0BWjoQKURAs6bAJ9azLH9ZGyHqjK4JvKkDU VzF65JXgCeIY6u
    KADV5KtzuBfLPCmQk8cZea8=
    =L/HP
    -----END PGP SIGNATURE-----

    Kris Guest

  9. #9

    Default Re: mksnap_ffs woes

    Kris Kennaway wrote:
     

    I am not sure, but I don't think so.

    First of all, while I would not expect an exactly deterministic
    behaviour, I still find it strange that most of the times it works
    within seconds, and occasionally it might need so long! Then again, I do
    not have enough insight to explain why it would or why it shouldn't.

    I didn't always have the opportunity to check, but I did once: I'm sure
    the disks were not working, and the CPU was not under stress, so I can
    see no reason why it would take that long (I waited for more than an
    hour, then decided to reset).

    Lastly, if what you say is true, that "writes to the filesytem may be
    suspended" for that long, then I don't see much point in using this
    feature. At least, it is not one that suits *my* needs: our clients must
    be up 24/7; if that happens they will time out and someone will need to
    go there and powercycle them.

    Am I going in the wrong direction then?
    Are there other alternatives for live backups?
    Is there some sort of more detailed doentation (tutorials, howtos,
    ....) on this topic?

    bye & Thanks
    av.
    Andrea Guest

  10. #10

    Default Re: mksnap_ffs woes

    Kris Kennaway wrote:
     

    Ok. As soon as I get the chance, I'll do this (I cannot stop a whole
    network right away).




     

    Ok.
    I just think that this, as well as the disclaimer about it being alpha
    code and the access locks, should be mentioned in the Handbook. Reading
    that chapter or mksnap_ffs's manual, I didn't get it and I suspect
    people might get the idea that it is stable code, which provides some
    functionality that it doesn't.



     
    >
    > Plenty, if you don't demand an instantaneous image of the backup
    > image.[/ref]

    That depends on what you mean for instantaneous...

    I'll explain my needs briefly: I export (via Samba) a whole bunch of
    databases that 9 clients read and write. I do not have more details (I
    didn't write that app myself).
    The needs are:
    a) backup data so that in case of severe failure we can get it rapidly
    back (we are going to loose the last transactions, obviously);
    b) te everything to another machine (via rsync) so that a remote
    user can see a snapshot of the system status.

    We probably can live with some incoherent records in a) (after all,
    something will almost for sure need manual fix anyway); as for b) I fear
    it might be more prone to problems.

    So, if for instantaneous you mean at a specific time, I don't care at
    all wether the image is made an hour earlier or later. All I'd like is
    coherence.

    BTW, we have almost no room for changes on the client side :(




     

    I'm reading all this stuff; I might get back with some more questions
    later :)


    bye & Thanks
    av.
    Andrea Guest

  11. #11

    Default Re: mksnap_ffs woes

    On Wed, 30 Mar 2005, Andrea Venturoli wrote:
     

    What databases?
     

    In my experience databases DO NOT like file system backups unless the
    database is NOT running. The more heavily you use the database the least
    it will play nice with file system backups.

    Is using the database backup routines an option?
    Does the database has any type of tion?
     

    Depending on the database system you are using the copies may be totally
    useless if you do a filesystem backup/sync.
     

    What is the client side?

    Given that you said it is in Samba is seems it's some type of windowd
    database. Is it a workgroup type of DB like Access or Foxpro? SQL server?

    --
    http://stringsutils.com
    Utility for developers. Compute length, MD5, CRC and more.
    Francisco Guest

  12. #12

    Default Re: mksnap_ffs woes

    On Fri, 1 Apr 2005, Andrea Venturoli wrote:
     

    Not necessarily true. How about a web application?
    This would mean that the machines would only need to be able to run a web
    browser. IF they are very old you could install FreeBSD on them. Even a
    200MHZ machine can run FreeBSD semi decently with X on it.
     


    If you give me the extensions I can take a reasonable guess at what they
    are. You CAN copy them. You just need to write a simple program to open
    them and copy them. Should be near trivial once you have whatever they
    used.
     

    With DBFs that won't work.
    You will very likely have corrupted headers if you do a copy/sync/snapshot
    depending on how busy your system is and how often writes are done to it.
     

    And you say this system is 24/7? DBFs are not exactly very good at this..
    specially if you have many deletes. Is this mostly a read only or write
    once only type of system?
     

    Many times it's a matter of how much a client wants to pay. On the
    last server I setup given the option of getting a RAID controller (IDE)
    for under $200 the client said no. You can only educate and advice a
    client so much if they are not willing to listen. The cost of unforseen
    crashes is usually far off in a small business owner's mind.

    --
    http://stringsutils.com
    Utility for developers. Compute length, MD5, CRC and more.

    Francisco Guest

  13. #13

    Default Re: mksnap_ffs woes

    Francisco Reyes wrote:
     

    Unfortunately we have no choice.


     

    Nope.


     

    Nope again.


     
    >
    > What is the client side?[/ref]

    Some *old* PCs (need ISA slots) running an old DOS [wannabe] application
    (actually a plethora of .BAT files and some .EXEs) on Windows 95 or 98 :(
    Not even the firm who made that crap is willing to put their hands on it.
    Replacing the software would mean replacing the hardware (not only the
    PCs, but the attached machines too) at multiple sites, which would mean
    a HUGE amount of money; that's behind my power and is to be considered
    out of question.


     

    It's some bunch of DBFs with associated indexes and God only knows what
    else. Given the clients need to be up 24/7, I though of filesystem
    snapshots as the only solution.

    I'll keep trying a bit more, since it seems doing them on a daily
    schedule doesn't do any harm. The problems so far have only arisen when
    I manually started a backup script (possibly interrupting it, cleaning
    up, and starting again).


    bye & Thanks
    av.

    P.S. The firm who sold that crap, also implemented the file server
    before mine; just without any RAID and/or backup facility. These data
    are vital to that business.
    Andrea Guest

  14. #14

    Default Re: mksnap_ffs woes

     
    >
    > Unfortunately we have no choice.[/ref]

    Sorry if this has been mentioned before but have you considered a
    split-mirror-backup? It would involve some downtime but only a few minutes
    for each backup. It would be cheaper than replacing all the clients.
     
    >
    > Nope.

    >
    > Nope again.

    >>
    >> What is the client side?[/ref]
    >
    > Some *old* PCs (need ISA slots) running an old DOS [wannabe] application
    > (actually a plethora of .BAT files and some .EXEs) on Windows 95 or 98 :(
    > Not even the firm who made that crap is willing to put their hands on it.
    > Replacing the software would mean replacing the hardware (not only the
    > PCs, but the attached machines too) at multiple sites, which would mean
    > a HUGE amount of money; that's behind my power and is to be considered
    > out of question.

    >
    > It's some bunch of DBFs with associated indexes and God only knows what
    > else. Given the clients need to be up 24/7, I though of filesystem
    > snapshots as the only solution.
    >
    > I'll keep trying a bit more, since it seems doing them on a daily
    > schedule doesn't do any harm. The problems so far have only arisen when
    > I manually started a backup script (possibly interrupting it, cleaning
    > up, and starting again).
    >
    > bye & Thanks
    > av.
    >
    > P.S. The firm who sold that crap, also implemented the file server
    > before mine; just without any RAID and/or backup facility. These data
    > are vital to that business.[/ref]

    --
    Ean Kingston
    E-Mail: ean_AT_hedron_DOT_org
    PGP KeyID: 1024D/CBC5D6BB
    URL: http://www.hedron.org/


    Ean Guest

Similar Threads

  1. WSE 2 woes
    By Mark A. Deal in forum ASP.NET Web Services
    Replies: 0
    Last Post: March 9th, 07:52 PM
  2. PDF woes
    By Ken Kehl in forum Macromedia Freehand
    Replies: 0
    Last Post: April 1st, 02:46 AM
  3. Copyright woes
    By Bill in forum Macromedia Director Basics
    Replies: 0
    Last Post: January 30th, 03:25 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139