I think here might be a misunderstanding. I was talking about a reliable backup
solution whereas you guys are all the time talking about mirroring and
replication type solutions. Since you cant be thinking that mirroring and
replication can replace backup, there must be a misunderstanding?
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?
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!
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.
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.
About VRRP etc. I already told that I am not talking about redundancy here. You
are talking about totally different things. I need data protection.
This actually works rather well if you do your research. Database
replication is possible at all kinds of different link speeds and
distances. Database replication also allows you to control your data
better --- you know more about your data than a block replicator would.
It means that your backup is already live and it means that, with the
right scripts, invoking a backup on primary failure is simple. Database
replication on some databases even allows you to preserve transactions
--- which is important in some cases.
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.
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.
Actually... as some obligatory positive content, the time travel
features of Hammer should be straightforward to implement in ZFS... are
ZFS modules supported on FreeBSD yet? It would seem to be a logical module.
Those features work within the filesystem, you there is no mention of mirroring
to a remote hard drive, if you could mirror to a remote hard drive, you couldnt
easily mirror 10 machines into 1 remote hard drive, even if you could do that,
it would require total disk space of all those 10 drives to exist in that 1
backup server. Even if you could overcome that, this would mean that all FreeBSD
users wanting to take advantage of such system to convert their filesystems.
Even if it was easy enough, there is no GUI tools to allow users exist in those
systems to restore files by themselves easily.
As you can see, none of the solutions you are suggesting is anywhere near simple
solutions which can replace near continous backup solutions.
Thanks,
Evren
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
