mirror site on second server

[cmyksteve]

I've been looking over the cPanel Docs for tips on setting up a duplicate site on a separate server. I have accounts on servers 9 and 16 which are both in the GNAX center and I want to have a backup site ready to go in the event of another hardware failure.

I've noticed different cPanel skins don't use the same phrases. Xcontroller calls it "Today's Backup File" while in the monsoon skin (there it matches the cPanel tutorials) the same thing is called "home directory backup".

So if you're moving sites (without assistance from Page-Zone tech support) these are the backups you want. They don't contain the system files like the Full Site Backup but they'll work with cPanel's restore feature (on your second server) to create this mirror.

My Joomla sites also require a database move but the backups and restore of the database seems pretty clear to me. It was just the reference to a Home Directory Backup that had me puzzled because xcontroller's phrases didn't match the tutorials.

Other little things may need to be updated due to the new site location like- one of my servers uses /home2/ in the path and the other just /home/. My configuraton.php file in Joomla needed to change in 3 spots to check the backup site without pointing the domain name to the backup server.

To check my backup site on server 9, I used the server's ip and the cPanel username- http://216.180.242.146/~username/

There are also different phrases used for the email forward or filter backup (comparing xcontroller to monsoon) but I didn't use these for my duplicate site.

[SpringerPal]

Greetings Steve!

Nice job. Thank you! I see it didn't take you long to post this little "HOWTO".

Now getting a good and/or daily back up shouldn't take very long either, eh?

The real importance of this is protecting the MySQL databases which may be changing daily or even more frequently. That's precisely *WHY* that function is there. If you can't live without your data, than you better darn well protect it with current, even multiple, backups.

Also, consider the case where you can also upload local backups (say from your own personal PC) to a distant and/or distributed server(s) as a precaution against a local hard drive and/or other equipment failure, or any other disaster that you can imagine. It's just *ONE MORE* level or layer of protection, security, and redundancy.

What *IF* your office burns down and destroys your personal PC and perhaps any backups that you had?? Simply buy another PC, set it up in any other location of your choice, reconnect to the network, and download your most recent data backups from your standby site(s).

Having a "hot" alternative back up site providing protection for both your primary website(s) and your local equipment helps justify the expense of maintaining a separate, parallel site. And, as a necessary business expense, it's fully tax deductible and a form of really cheap business insurance.

The correct thinking or planning is to avoid any single point of failure by spreading out the risk over multiple machines and/or networks. That's precisely *WHY* hosting companies utilize multiple data centers.

Experiment, enjoy! Take care.

Cheers!

[cmyksteve]

A question's come up with my cPanel backups. It's obvious the Full Backup link starts the backup process- there's a pause between your notification email and starting the process. However the Home Directory Backup (same thing as Download today's backup file in the xcontroller skin) starts to download immediately so it can't be up to the minute fresh. Does anyone know when the Home Directory Backups are made or can the cPanel user force a Home Directory Backup right before they download?

[cmyksteve]

I ran into a time out limit with a cPanel restore around the 100 to 120MB range. I've had no problem restoring smaller archives this way. I figure this is probably a time restraint so a faster connection may not have this problem.

On the larger ones I decompressed the archive on my desktop, made a new tar archive of just those files and directories I needed for my public_html folder. Then I compressed that file into an archive.tar.gz and uploaded with my desktop ftp program. After this tarball was setting in the server's public_html I used cPanel's File Manager to "Extract File Contents".

I also ran across a 2004 forum post from Jim on transfering a site if you have SSH access.

[SpringerPal]

Hi Steve,

I have a question.

Originally Posted by cmyksteve

I ran into a time out limit with a cPanel restore around the 100 to 120MB range. I've had no problem restoring smaller archives this way. I figure this is probably a time restraint so a faster connection may not have this problem.
.

Am I correct to assume that this is over the wire rather than from a local disk?

Originally Posted by cmyksteve

After this tarball was setting in the server's public_html I used cPanel's File Manager to "Extract File Contents".
.

Are you referring here to the 100 to 120Mb file on the local disk?

TIA

Regards,
SpringerPal

[cmyksteve]

Hi Springer,

I used cPanel to downloaded my working site's Home Directory Backup. That compressed archive was 120MBs on my desktop.

The cPanel restore headed for my mirror site timed out. I just assumed since cPanel could get it down that it was time restraint, since my uploads are so much slower than the downloads on DSL.

Some of the files in that archive don't belong in the site's public_html directory, so I unStuffed it on my desktop and made my own archive.tar.gz of the appropriate files for my mirror site.

[edwurster]

Originally Posted by cmyksteve

I ran into a time out limit with a cPanel restore around the 100 to 120MB range. I've had no problem restoring smaller archives this way. I figure this is probably a time restraint so a faster connection may not have this problem.

On the larger ones I decompressed the archive on my desktop, made a new tar archive of just those files and directories I needed for my public_html folder. Then I compressed that file into an archive.tar.gz and uploaded with my desktop ftp program. After this ...[/url].

Could it be that the process is introducing something extraneous? Can you transfer the larger file server to server and restore that?

[SpringerPal]

Hi Steve!

Thanks for getting back to me. You wrote:

Originally Posted by cmyksteve

The cPanel restore headed for my mirror site timed out. I just assumed since cPanel could get it down that it was time restraint, since my uploads are so much slower than the downloads on DSL.

"Hey! Where are those darn engineers when you need them? Surely *THEY* tested it, right?" ;-)

You're right! I hadn't considered that. But there may also be many other factors at work here, too. For example, some system wide or account restriction on the size of uploads to prevent abuse?? It bears more testing.

Did you try to re-run the test from another machine and/or location? I'm aware of other people who have moved fairly large installations with few problems.

If I can get some free time (sigh!), I'll try to cruise over to the cPanel folks and see if there is anything there that might shed some light on this.

Also, there is command line FTP, WS_FTP, and cPanel's filemanager. I've even used the ftp function in some browsers to move stuff around. I can't really say, though, that I remember attempting to move any thing big that way.

It would be an interesting experiment to test the various methods one against the other. Perhaps one way may work better with larger files, eh?

Of course, actually *testing* one's disaster recovery (or preparedness) plan is always a good idea. "The fire truck is not much use if the engine won't start or the pump doesn't work or the hoses are rotten or the tires are flat or the......"

Originally Posted by cmyksteve

Some of the files in that archive don't belong in the site's public_html directory, so I unStuffed it on my desktop and made my own archive.tar.gz of the appropriate files for my mirror site.

Steve, I really like this idea! Disassemble the tarball, shuffle the component parts, and re-assemble. Or, perhaps prepare smaller chunks of an installation and then reinstall in smaller blocks, testing as you go along, or adding on as things smooth out. Great idea!

There may be definite advantages to reloading in smaller pieces, especially if any amount of troubleshooting is required. A form of the old "KISS" principle.

Also, sometimes the backups themselves don't work for some known or unknown reason. I remember spending hours and hours restoring from backup tape only to find out the tape was defective!! Multiple copies of smaller chunks would definitely get around the "all or nothing" problem of some types of restores.

Thanks!!

Regards,
Your humble guard dog ;-)

[SpringerPal]

Hi Ed!

You wrote:

Originally Posted by edwurster

Could it be that the process is introducing something extraneous? Can you transfer the larger file server to server and restore that?

I don't know whether anyone else has had this experience or not, but on occasion I've downloaded Linux tarballs to a Windows OS desktop (or directory) and then passed them to a Linux machine on our internal network. Occasionally the Linux OS refuses to open them or is unable to open (or process) them for some reason.

Sometimes this works and sometimes it doesn't.

However, if I download the same tarballs, from the same source directly to the Linux machine, they open just fine!?!?!

Any ideas? I've never had the free time to go back and investigate or dig any deeper into this. I'm curious why this may be. Perhaps someone with more Linux experience than myself may have an answer or an explanation.

Regards,
Your ever humble and obedient watch dog ;-)

[Jim]

I think rsync would be the way to go. It would require the account already be set up on both servers. Then a cron job set upto rsync the data from one server to another. It gets a little complicated with a cron job because you have to set up ssh keys to avoid the password prompt. Or a perl expect script, but then the password is sitting out there in plain text. Its always a good idea to have a backup ready, especially on any server with a single drive. Mirrored drives offer more protection, but even then it isn't a substitute for backups. It eliminates the risk of one hard drive dying but adds another point of failure (the raid card).

We are setting up new servers with Linux software raid just because of that fact. Software raid has the same or better performance without the extra point possible hardware failure. And yes, hardware raid fans always seem to knee jerk scorn on that statement , but none can show proof that hardware raid is better. Some have said the on board processor and ram of a hardware raid card helps the system, but how much help can it be? 100mhz helping dual core, dual cpu 2.8-3.5ghz system is a pitance. And the amount of cpu needed to direct parity is almost nothing anyway.

Anyway, this command should work in syncing data. Typing rsync --help will show all the available options and what they mean. Depending on whether or not ssh is on a non default port, one or the other will work

If ssh is on port 5205 it would look like this:

rsync -avogz -e 'ssh -p 5205' 192.168.0.1:/home/bob /home/bob

some of the options probably aren't needed (like -o [retain original ownership]) but wont hurt to leave in.

This command would be run from the server you are backing up TO. rsync order is always source, then destination. So the command is saying go to 192.168.0.1 and get everything in /home/bob, and bring it here and put in /home/bob.

The options are -a archive mode, -v print messages to screen, -o preserve ownership of files, -g preserve group, -z compress the file for the trip over. You can probably not use any of those except -a though. Not running the command as root would make those redundant because you can't do it on any files you don't already own, and -z isn't needed anyway.

That's my 2 cents, now it's time to take another server out to Indiana and bring it online.

[cmyksteve]

Originally Posted by edwurster

Could it be that the process is introducing something extraneous?

Hi Ed,

I don't think anything is being added on my desktop (Mac OS X)- the go between for the servers. All the smaller Home Directory Backups worked like I expected, just around the 100MB size, cPanels restore ran for 20 minutes or so then threw an error. I decompressed the backup it wouldn't take, broke that down and made the new tarball. Since my desktop ftp program has some resume features I thought I'd try to move it over to the new server that way- and it worked. Once the tarball was there, cPanel's File Manager could extract it.

If there were only a few files going to the new server I wouldn't have bothered making the tarball with Mac application Stuffit Deluxe. But my ftp program Cyberduck tends to time out if I try and move hundreds of files. If it's only one large file, it works fine.

Originally Posted by edwurster

Can you transfer the larger file server to server and restore that?

If you mean a cPanel's Full Backup, I'd read in on that old post from Jim that it required SSH and I'm not set up for that yet. I think cPanel will let you make a Full Backup and move it via ftp but I think you need tech support to run the restore after the backup is over on the destination server.

[cmyksteve]

Originally Posted by Jim

I think rsync would be the way to go.

Could be but I have this Old Guard Dog and New Tricks thing going on. :-)

Someday I'll add the Linux OS to my bag of tricks- if I live that long.