continuous backup solution for FreeBSD - FreeBSD

This is a discussion on continuous backup solution for FreeBSD - FreeBSD ; Hello, As far as I can see, there is no continuous backup solution for FreeBSD at the moment. I talked with R1Soft and they seem to not be able to support FreeBSD and need help. Does anybody have free time ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: continuous backup solution for FreeBSD

  1. continuous backup solution for FreeBSD

    Hello,

    As far as I can see, there is no continuous backup solution for FreeBSD at the
    moment. I talked with R1Soft and they seem to not be able to support FreeBSD and
    need help.

    Does anybody have free time and skills to give a hand? Please see:
    http://forum.r1soft.com/showpost.php?p=3414&postcount=9

    I know people who want to switch to using FreeBSD but cant do that because their
    backup solution (R1Soft) does not support FreeBSD

    Thanks,
    Evren
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  2. Re: continuous backup solution for FreeBSD

    On Tue, Oct 07, 2008 at 12:31:58AM +0300, Evren Yurtesen wrote:
    >
    > so FreeBSD could be supported also. As you can imagine, it is not only
    > important that data can be restored when a box hardware failure etc. it is
    > also important that data can be restored if deleted by accidents etc. While
    > traditional backup programs provide this functionality, you cant really go
    > back to 10 min or 1h ago, often they take daily backups and have to scan
    > whole filesystem for changed files every time the backup is taken which
    > stresses out the systems.
    >


    This can (more or less) be achieved with snapshots: you can cheaply
    maintain old versions of the file system, and mount an old snapshot at
    any time. Hourly is about as fine-grained as you can expect though.

    --
    Shaun Amott // PGP: 0x6B387A9A
    "A foolish consistency is the hobgoblin
    of little minds." - Ralph Waldo Emerson
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  3. Re: continuous backup solution for FreeBSD

    On Tue, Oct 7, 2008 at 4:13 AM, Evren Yurtesen wrote:

    >
    > Zaphod Beeblebrox wrote:
    >
    >
    >> From my reading, Hammer is much more than a filesystem, but then you
    >> probably havn't read about it yet. By my reading, Hammer hits all their
    >> feature points and does it better _because_ it's a filesystem.
    >>

    >
    > I glanced through these actually:
    > http://www.dragonflybsd.org/hammer/
    > I didnt see anywhere that it will replace backup programs?
    >


    You need to read the PDF on that page. On the first page of the PDF the 4th
    point is "queue-less incremental mirroring" If you read the PDF to
    determine what this phrase means, you'll find it describes the filesystem as
    a database indexed by a B+ tree of radix 64. It mentions that you can
    easily select all changes newer than a certain time. The problem with
    backup solutions that run on raw blocks is that you need meta-data to queue
    up the blocks that have changed faster than you can ship them out. Hammer
    solves this by allowing you to select changes based on when you shipped out
    the last batch of changes. The granularity of this will be dependent on how
    fast you can do this.


    >
    > It's relatively simple. Database replication solves the data backup
    >> problem (I don't store application data outside the database). Database
    >> replication for both MySQL and PostgreSQL is relatively straight forward.
    >> As for the configuration of code and servers --- that is taken care of with
    >> configuration management (it's really a bigger issue than just backing up a
    >> filesystem) and installing a new server to take a place in the cluster is a
    >> straight forward checkout from the CM system. For things I really care
    >> about staying up, add VRRP and an application design that is fault tolerant.
    >>

    >
    > Have you ever tried to restore data from MySQL replication logs? Even if
    > you use binary logging, when you want to go back in time. You will need to
    > first restore the whole database first from normal backups then replay the
    > logs until the point that you wanna be. There is no simple way to go back in
    > time. That is of course you have backups. If you dont have backups because
    > you think replication is a backup solution, you would be screwed. Totally
    > more complicated that clicking from the web to select data and time and
    > table and restore!



    Largely why I use PostgreSQL.


    > Also, you are thinking about a very small sized system. While replication
    > might work if you are relatively small sized company (like 1-2 servers). If
    > you have many independent servers with different databases inside you just
    > cant use it. Even if you could replicate multiple boxes into one box, there
    > would eventually be problems such as same named databases etc. and even
    > then, you cant just easily restore the data if the user deletes all his data
    > in his tables.



    Again, this is application design. I know of rather large organizations
    that use PostgreSQL replication to deliver very serious and onerous SLAs.
    Several of them have sponsored the Slovney (sp? russian for elephan --- the
    PostgreSQL multi-master replication thing).


    > Also that is not practical for users at all. For example I cant give an
    > option to the user to restore his data by himself. While that is possible
    > with most backup software easily.



    Well... if we're talking about a random samba servers for windoze users, ZFS
    is the tech you want. Users can retrieve their own snapshots, etc. ZFS was
    designed with generalized fileserver duties in mind.


    > And how do you propose that I restore a table in the database to of 1h
    > before status? like you can do with a data backup solution? You are talking
    > about a spare server solution not backup solution. Replication IS NOT
    > backup. If you look at articles and information about database replication,
    > almost all mention that it DOES NOT replace backups.
    >


    I use differential backups to give old database restore functionality. I
    use replication to give me a live alternative database for failures
    (different risks, different solutions).


    > Well... no. Backup software and strategies are just one available tool
    >> for risk mitigation. To know what tools you require, you must define your
    >> risks. Then with your list of risks you look at the cost of each tool and
    >> find the toolset that suits you. By the responses in this thread, it seems
    >> like the set of FreeBSD developers and the set of people who desire this
    >> solution are disjoint.
    >>

    >
    > Right, I just cant use the tool I require. There is no way to take near
    > continuous backups of FreeBSD filesystems.
    >


    You're free to pay anyone you'd like to implement this solution. I'd be
    happy to work for hire. I can provide a quote if you're serious about it.
    But if I was doing it for free, I'd want it to be fun and interesting. I'd
    be imlementing a server as well as a client. In fact, if I were doing this
    as my own open source project, I'd be looking at a better way of achieving
    it. FreeBSD is, after all, about doing things right. But --- as I said ---
    regardless of what I'd do if I were doing it for free, I will achieve the
    goals set out for me if I'm paid.
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


+ Reply to Thread