December 12, 2006 at 8:38 pm
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/topry/2756.asp
January 3, 2007 at 6:49 am
I think white boxes often overlooked as a solution, especially for end user machines. I think your note about having the appropriate internal knowledge was right on target, might not be the right solution for a business where the receptionist doubles as the network admin. Im sure some will disagree, but computers are just expensive toasters now. When it breaks, buy a new one!
Kudos for building a strategy and executing it successfully (and for writing it up).
January 3, 2007 at 7:02 am
Well thought out, well written, concise and to the point. I enjoyed and learned from this article. I can usually say only one or the other about technical articles I read.
From punch cards to CDP in one career - quite a journey!
Thanks,
Carter (also in the Atlanta area)
But boss, why must the urgent always take precedence over the important?
January 3, 2007 at 10:15 am
Good informative article. thanks. But one question, how do you send files to ftp server. Can we create a batch file (or may be different approach) to send backup file to this ftp server once backup is done. If its one time full backup, thats ok as its only once in a day job and we can use some software like Filezilla to transfer file. I am thinking of how to transfer Tlog backups which we take every 15 minutes and file size is around 30 - 40 MB. and don't want to waste time with filezilla. need an automated solution.
Any solutions?
SQL DBA.
January 3, 2007 at 10:30 am
For FTP (as in the entire process) - nothing fancy.
I use WS_FTP Pro from IPSwitch, it is installed on a whitebox PC (low end) with an hourly schedule. It does a diff on the files that are the current weeks backup folder (which is the base images and the hourly incrementals). The incrementals and base images have different file extension, so it downloads only the incrementals. The offsite uses a cable modem which has 8.5MB (theoretical ) downstream - which is more than my internal bandwidth in total, so I throttle that down a bit on the FTP server. The incrementals are password protected and encrypted, but without the base image they are useless. SQL transaction logs do contain easy to read data, so I would recommend some form of encryption. I use a freeware Blowfish utility - there are plenty of options in the public domain.
Since the weekly incremental images are 'included' in the weekend base image, the start of each week the offsite deletes the prior week incrementals and starts anew.
January 3, 2007 at 11:23 am
An interesting article, but for the prejudice against name-brand servers.
While I appreciate that technical experience can make a 'white-box' solution more palatable, you run a huge risk of discovering that Microsoft won't talk to you about your Windows bug because you're not running hardware on their HCL. We were warned about that in MCSE classes, but I never took it seriously until the first (only!) time it happened to me. It's great to save 20% on a server, but if that means you're on your own re-building an Exchange database, well... I'd rather spend my weekends with my family than in the server room, surfing web forums.
That, added to the prospect of risking your enterprise on Symantec... He has faith in different companies than I do, I guess. I just spent about 20 minutes on the Symantec website looking for v2i. While I can find press releases from 2003 and technical bulletins discussing it, either they don't sell it anymore, or they really don't want you to buy it.
January 3, 2007 at 11:34 am
I've never had an issue with MS Support based upon any whitebox solution. Actually, I've never had them query the hardware components when I've called them for support. Still, your point is well taken and something to consider.
As for 'risking your enterprise on Symantec' - like many large companies, Symantec did not originally create any of the products that we use, they simply acquired them. I am not a fan of Symantec, but I have tested (and will continue to test/verify) all components of our disaster recovery plan - regardless of the vendor. Don't knock something you have not tried simply because of the logo currently stuck to the box.
January 3, 2007 at 11:36 am
WARNING: Side Issue.
I've thought about using the type of drives you discuss as a near real-time backup/dr system: Running a SQL server on a virtual windows box whose os image is stored on a cheap external ide drive that's running somewhere offsite. (my main db is in the 700 gb range, so something like ~1 tb.) Then use SQL replication to keep that server in sync with the real thing. It seems to me that something like a cable modem (~6 mb downstream) might just provide enough bandwidth to do ~hourly replication. If it works, you get very near real time backup, and you even have a hot spare sql server, albeit a slow one.
The idea is very appealing to me.
What am I missing?
Bob
January 3, 2007 at 11:51 am
Bob - other than the performance issues, the only one that comes to mind is security/authentication. If the offsite box is connected via VPN and a member server of the same or trusted domain, then it sounds technically feasible. (I do not use SQL Replication, so I am not familiar with any idiosyncrasies it may have) Test the inevitable disconnect/reauthenticate scenarios as well as power loss, so that you are not faced with making trips to resolve issues - that along with remote access to the device (UltraVNC, GotoMyPC, etc). That is how I manage our remote FTP backup machine.
January 3, 2007 at 12:13 pm
Well done AND well thought out!
January 3, 2007 at 2:26 pm
Tim, I don't know if this would be within your SMB budget (I work for a "SMB" but we're on the large side of "M").
Do you have more than one location, and are they well networked? If so, look into putting some of your white boxes at the other location and using a product like XOSoft. (A great little company, but recently bought out by CA. So far, aside from the loss of the personal touch, still OK).
Without too much trouble you can set your files, SQL Servers, and Exchange servers to have hot failovers in the other office. The file servers just copy files when they change, the SQL and Exchange versions do block copies and understand the transactional integretity issues of each.
There's a few ways to set this up, but what we do is let XOSoft do dynamic DNS update on failover. So if you fry your Exchange server, the spare (which should be within a few seconds of the original) can update DNS so that it becomes the Exchange server (apps still need to reconnect, so it isn't totally seamless, but you can do this in a couple of minutes). Then you can start a reverse scenario so that when you get your main server rebuilt, it will get it in sync and you can switch back. This is also useful just for maintanance, but I think the price (far from free, but doable for some SMBs depending on how expensive you consider downtime to be) needs to be justified as disaster recovery: if something happened to the main office, you could keep running from the other office.
Of course, if you don't have the second office, or you don't have the bandwidth on the network between the offices, this is a non-starter. But it is very simple and affordable and easy to do as compared to Clustering.
Roger Reid
Database Garage
Roger L Reid
January 3, 2007 at 2:38 pm
Thanks for the suggestion - unfortunately (or fortunately depending on ones point of view), we have but one location. The offsite I use for the FTP incrementals is not an office location, just a co-lo site. Plus, our bandwidth would not make this possible (along with ordinary budgetary constraints as we are on the low side of the 'S'). However, limited downtime for us is currently not a major issue. Still just a M-F, 9 to 5 shop, so we have lots of time to break stuff
DNS redundancy has never been an issue, but DHCP has (is). That's one area where I think MS has dropped the ball. That issue is a separate topic in and of itself!
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply