Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What is the most efficient way to organize the duplication of a server with the backup of the same server?
What I mean is that the data on a server has to be backed up and the same data has to be copied to another server in case the first server goes down, this is doing the same thing twice but each copy can only be used in one circumstance, not two.
Or am I missing something?
In my case, making a backup is a fluid thing because the data changes all the time. To collect the data, forms are used, so one of my questions is:
is it more efficient to send the contents of the form to one server and duplicate that server with "rsync" or can the contents of the form be sent to 2 servers (or more)?
Is there a conventional way to deal with this sort of problem (have one or more copies of the server and one or more backup)?
You need to be clear about what you are trying to duplicate - if you are trying to sync data in a database then you can use master-slave replication, and simply use the slave if the master goes down. If you are trying to duplicate files then you can write a script or service that copies files as required to wherever they need to go, using whatever programming language you prefer. IIRC, there is a Linux feature called inotify which lets programs find out when a change occurs in the filesystem - this is used by desktop search; I once saw a Perl script that used it.
It is the duplication of data kept in flat files, not in a conventional database like mysql. I understand from your answer this scenario would require a script to copy the file (or probably sync it).
If this is correct, what would be the correct procedure to follow to determine if the new data goes to the master or to the slave for storage, if the master is down? Is pinging the destination server an efficient and fast solution?
At first glance, using rsync seems to be the solution to have the master/slave set up and this removes the need to use something like "inotify".
In such a situation, can a slave, or a second slave, be considered as a backup?
It is the duplication of data kept in flat files, not in a conventional database like mysql. I understand from your answer this scenario would require a script to copy the file (or probably sync it).
At the simplest level, a one line shell script to execute rsync lets you make as many extra copies of a given directory as you desire, and you can schedule it with cron. rsync integrates SSH, so whether the clones are local or remote is all the same. That's the base line, and you can add complexity from there to get to the solution that meets the requirements.
Quote:
If this is correct, what would be the correct procedure to follow to determine if the new data goes to the master or to the slave for storage, if the master is down? Is pinging the destination server an efficient and fast solution?
You probably need to draw your architecture (back of an envelope will do) to work this problem though. Each upload connection goes from one client to one server. Once you have received the upload you obviously have full control of that data, and can copy/sync/move it. If you have multiple servers you can get different clients to connect to different servers, but each connection is still one-to-one.
Quote:
At first glance, using rsync seems to be the solution to have the master/slave set up and this removes the need to use something like "inotify".
inotify lets a process know when the contents of a directory changes, rather than the process having to poll the directory periodically. It may or may not be useful for your particular problem, so I thought that I should mention it.
Quote:
In such a situation, can a slave, or a second slave, be considered as a backup?
An active slave is never a backup. It is only a second copy of something, taken at a particular point in time. It is useful for load-balancing, or rapidly restoring availability if your system can quickly detect a failure, but for genuine backup in the disaster recovery sense you need a means of retrieving "frozen" copies of the dataset from several previous points in time. If a live master copy corrupts the error can be replicated to any live slaves, which are then equally useless (been there, seen that).
FWIW, I suspect that you need to think in terms of how to handle the files, rather than servers. Again, once the the file have been received by your upload server you have full control.
If you want to keep a permanent copy of each file then perhaps do something like this... Have one "incoming" directory and seven "daily" directories. Use two scripts or programs: one that runs periodically to move new files from an "incoming" directory to the "daily" directory for that day, and a second that runs each day to write the daily directory for yesterday to tape or CD.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.