The Complete Geek

I wanted to give you a heads up that I will soon be changing formats for my blog, The new format will likely be wordpress  but I have to plan the import because of my wish to maintain the links as is.

This is because blogger announced the termination of FTP publishing support today and I wish to continue hosting my own blog

Thanks for your patience and hope to see you on the other side

A new book, Vsphere 4.0 Quick Start guide by Duncan Epping (as well as many other talented people). I have mine on order already!

If you are not familiar With Duncan check out his blog  He is one of the foremost virtualization bloggers and always has useful and concise information.

For those starting down the path of virtualization or veterans trying to expand their skills check out this book!

The simple answer is no, the more complex answer is it depends.

 Point in time copies (snapshots) can drastically increase your time to recovery. And can be incredibly useful for data restoration due to an application/operating system/ file system/ user problem.

That being said, really the idea of a true backup is to handle DR and the failure of systems, disks and other problems. Being that your data and copies reside in the same hardware/location it does not protect you against such failures.

Now the reason above I stated is "it depends" is because some vendors are offering the replication of existing point in time copies to a remote system. So the idea is that when it resides on the same system it is not fully useful as a backup media but once it gets transfered/archived and if that archive container the sum total of the original data as well (So a mirror or replication) it can act as a full backup.

Current Problems
There is some possibilities here,  If you are simply looking for a point in time to be able to restore to for DR for the short term you can fulfill this with a large archive of remote point in time copies (replicas) but with current vendors these technologies fall flat in two area's

1) Long term storage
A lot of vendors are trying to make improvements in this area but still fall short. While it may be feasible to store weeks or even months worth of daily snapshots is doable with some of todays vendors really keeping a lot of these around for years is non feasible. This storage space is also relativity expensive per GB compared tape and other media. At best it can be used as a "Mid Teir" place to store info to reduce your "race to daylight"

2) Archival, cataloging
No solution that I am aware of (and if you know any different please share!) really handles the cataloging on a file level that is available to some other server side tools. What happens when you have a user that asks "I deleted a very important document from 2 months ago, I don't remember its name exactly but it was financial something or other and was an excel spreadsheet" or "I have not looked at my important financial document in a year but someone changed it in the last year, I want the one that was modified in 2008"

With E discovery tools available to some backup solutions this is easy to do I just search for *financial*.xls?  but with block level point in time copies this is not as easy.

Some vendors are making strides (specially if they also do file level shares) and are going in the right direction but are not there yet.

Long term storage


A nice trend I am seeing in industry is the ability to ship point in time copies off to alternative media, this is a great idea. Quite a few vendors are making an effort to be able to do things like use standard NDMP to be able to export the data directly from the SAN to something like a data domain or a VTL or directly to tape. This makes long term storage more feasible and  economical.

My take on it
Point in time copies are a great way to prevent against many different types of non storage layer problems, and replicas can even help with that. But in the end without cataloging the usefulness and ability to do file level recovery and E-discovery is non existent. It may be perfectly fine for your industry but in some that is a challenge.

Labels: Backups, Point in time, SAN, Storage

A complicated idea that seems to have quite a bit of merit, their architecture sure seems to have lots of possibilities to provide a high performing very flexible architecture, has my interest piqued.

As a corollary to my last post I wanted to describe how to disable TCP forwarding.
You will want to add or uncomment the following line and make sure it is set to no in /etc/ssh/sshd_config

AllowTcpForwarding no

The default is “yes"

Note you will want to make sure that users do not have permissions to set their own forwarders, but this is the global disabling.

This can also be done on a per user basis with the enforce key-based authentication and use per-key directives in each user's authorized_keys file. This is further explained in "AUTHORIZED_KEYS FILE FORMAT" section of sshd http://man.he.net/man5/authorized_keys

I have not done this myself but maybe something you want to evaluate if you are hosting a shared resource.

Labels: Linux, Remote Administraton, SSH, Tunneling

This is another one of those old school tools that can make your administration life much easier.

What is it:
It is easiest to think of an SSH tunnel as software VPN from your computer (Client) To the server serving SSH. You can then forward any traffic to or from your PC through this tunnel. While not like a full VPN in operations it allows you to forward traffic securely through the tunnel like you are on the network.

Why this instead of a true VPN you ask?

Because it is free, does not require specific network equipment, often pre configured to be ON already on most linux distro's, and setup is easy.

How I have used it:
I have used this tool in many scenarios from my home network, where I want to be secure or access resources that are either impractical to share out individually or were of a type you do not normally publish to the internet (Like Windows File sharing, or NFS)

Also have used it when I need access to resources in networks where there are either overly concerned network guys or where it was impractical because of design to publish out needed resources to the public internet.

Example:
Here is an example of the data flow when it is configured, this example encompasses tunneling a VNC session of the SSH server back through the tunnel and tunneling data (Windows file share port 139 from server 2 back to the ssh server then through the tunnel

Figure 1


Configuration:

Linux:
Using standard open SSH simply use the following line

ssh -L localport:remotemachine:remoteport Targetaddress

So for our example of VNC in Figure 1

ssh -L 5900:localhost:5900 SSHserversaddress

In plain English this tunnels local port 5900 through the tunnel and loops it back to the local host of the SSH server also on port 5900

Following Figure 1 if we wanted to then configure port 139 (windows file share)

ssh -L 139:Server2Address:139 SSHserversaddress

What this says is listen on local port 139, forward it through the tunnel to server2's address also on port 139 at the far side of that tunnel

Windows:


Advanced Usages:


There are a couple of advanced cases that you can use this for, once you have the concept down it is easy

1) Forwarding different local ports to the same port different destinations on the remote side

Linux:
ssh -L 5900:localhost:5900 -L 5901:Server2Address:5900 SSHserversaddress


What this does is forwards port 5900 to the localhost address of the ssh server also port 5900, it also forwards local port 5901 to server 2 port 5900

In this way you can have a whole bunch of the same traffic to different machines on the far side of the wire without having to change VNC configuration on the far side to listen to a non standard port.


In addition the -N flag can be useful it launches the tunnel without starting a remote session so you can use a 2nd session to communicate through the tunnel
Windows:


Figure 3




What this does is forwards port 5900 to the localhost address of the ssh server also port 5900, it also forwards local port 5901 to server2 port 5900


2) Setting the tunnel to accept connections from other computers on your network to forward through the tunnel.

This one I am going to do in putty only, But putty is available for linux as well. I am unsure if it can be done with openssh

Figure 4

Just one more checkbox here, what this allows you to do is forward on requests from other machines through the tunnel to the far side, making this even more VPN like (Kind of like VPN + NAT through the tunnel)

*Note in all above screenshots replace server2 with the IP address of Server 2 or the host name if the ssh server knows it

Rather cool video I ran across on youtube

An interview with Dan Anderson, The designer behind vmworld 2009's data center.

Also get to see a bit of the hardware close up for those of us who could not attend this year.

Also an impressive amount of money for only 2 weeks (As stated in the video a rough estimate of 35 million dollars!)