Category Archives: Server

Easy Steps to Network Troubleshooting | Part 2

Posted on by

In part 1 you have to prepare, create documentation, conduct a physical check, try to reboot and make the chronology of events. The following steps are the steps the next alternative.

 

Talking To User

Does the user have to change their system configurations? Installing new software? Do they use the new IP address? If the IP address that they take existing uses, then it could cause problems.

While identifying what is happening, try to think to happen outside the technical side. Human behavior may also be involved. For example, your colleague came after office hours with a laptop. Because no port is empty, he pulled out without telling. But he forgot to connect it back after the next day and you are shocked that the network be down. At first, of course you will consider this complex and mysterious.

 

Where Problems Arise?

Try to identify where problems arise. Is the problem appeared on only one application or all applications? Is the trouble only on one computer or all computers on the network also experienced the same problem? If only one computer, it stands to reason that the problem is the computer, instead of the network. Try restarting the system, and see if the troule still exists. What is the error message? Just look at the system log.

For example, suppose the NFS problem that we mentioned earlier. What just happened? Electrical surges so that all systems must be restarted. This means that the problem associated with all system restarts. Which applications are problematic? Only on NFS. All works fine. This means the problem is obvious NFS.

 

Use Ping

Still a problem? You do a physical check, it turns out all is fine. Among the network analysis tool, ping is the most useful tools. As you may already grasp, the ping can denote whether you can reach the connections on the other side, including computers, gateways, and printers. If you have, you will indeed be proficient to identify network problems and then find the solution.

 

Still Have a Problem?

The steps that have been done are adequate to conclude most of the problems, but not all. If you’re still having troubles, try to make sure the following points. Damage hardware: network cards, hubs, adapters and other components can be and sometimes are damaged. Try to identify the problem using ping and if necessary try to replace it with a hardware that is definitely working.

Networking Troubleshooting

Posted on by

Determining Troubleshooting Method.

Network troubleshooting is when you resolution troubles by identifying and resolving problems. Example if you treat the servers to send directories to the client. Since the power goes out, then a server and a client go down. When the power is on, reboot both devices. After logging in the client, you necessitate to access the directory on the server, but can not. What happened?  There are quite a few methods that you can apply:

I. OSI Model

The basis of each method of troubleshooting here is OSI Model reference. If you don’t grasp what the OSI model, in a nutshell it is a network model that consists of seven layers, where the structure of the uppermost layer is:

  1. Application
  2. Presentation
  3. Session
  4. Transport
  5. Network
  6. Data Link
  7. Physical

The workings of the OSI model is run from the Application to the Physical layer, then headed to the Physical layer receiver via an intermediary network with a physical medium (such as an Ethernet cable). From there, data goes to the upper application layer to the receiver.

When data has arrived, the receiver turn into the sender. And the sender to the receiver. The retort from the receiver goes back and forth the contradictory path, and retrace to the primary sender. Hence, but there is one layer that is not performing, then the data could not run. For case in point, if the Session layer does not function, then the data will not be able to proceed from the Network layer to Transport layer.

II. Bottom-Up

This method starts from the bottom layer, the Physical Layer, a new upward toward the Application Layer. Physical Layer includes a network cable and network card. So, if there is a network cable is disconnected, then do not always do the troubleshooting. You should fix the problem first before proceeding to the Physical Layer. Having solved the problem, check it whether there is still interference. If yes, continue troubleshooting to display the data links. For example, if for example there is an entry the same MAC on the switch MAC address table, then fix the problem first before checking on the network layer (eg. IP address or routing).

III. Top-Down

The same as the bottom-up method, only the top-down methods, troubleshooting starting from the uppermost layer, the layer of new Application heading down to the Physical Layer.

IV. Divide and Conquer

This method takes a bit of instinct. This method can be started from anywhere, if you get by the cause of the problem. From there, you can go up or down.

 

So which method is chosen? Follow your intuition, where about problems that occur. For example, if the user can not browse the internet, and you think it’s because of the many browser setting, afterward you be able to use a top-down method. In contrast, if the user has just connect the notebook to the network and can not browse the internet, you can use a bottom-up method because the user is most likely the network cable is damaged or because of similar problems.

Please Note: When Making a Backup | Part II

Posted on by

You have followed my tips on Part I and now it’s time to advanced tips.

 

Create Backups of your Backups!

Always remember that your backup is a safety net. If the server fails, the backup is the major solution (then occasionally only one) to make the server work again. Because backup is very important, do not just have one backup. If possible, make backups of your backups. You firmly do not want to be in a condition where you can not do the recovery because the only backup you have failed.

Do Anticipation of Change!

Suppose that every tree months you make backups that are resuscitated as an enduring documentation. However, with the time backup technology is change. Although modify is foreseeable, you should always ensure that you have the software and hardware to read old backup tape, to anticipate in occurrence you necessitate restoring data from tape archives.

Consider the Impact of Security Backups!

Sometimes recovery can not be done because no one recognizes the password on the backup tape. Sometimes there are also companies that use the encryption hardware and then upgrade to a new tape drive that doesn’t support encryption that is used before (which means, old backups can not be used). There is no rebuffing that secure backups are important, but it is as properly imperative to suppose the results of security measures. If you have to recovery data after a severe system failure, the last thing you need security mechanism, which turned out to obstruct the path of the recovery process.

Don’t Just Backing up Data!

If the server is problematic and should make an extensive recovery, you really can just reinstall the operating system and applications. After that you can restore the data. However, time is the most crucial thing when recovery from crashes. It will be much more rapidly to restore everything from backup instead of installing the operating system and applications. It’s often not easy to configure the server manually to match the prior configuration. By doing a totally backup then the configuration will be exactly alike before the crash.

Don’t Just Rely on Backup Server!

Backup server offers many advantages over traditional tape backup. However, do not just rely on backup solutions like this, because backup servers are susceptible to risks akin to a protected server. Fire, lightning, storms, or flood could wipe out the backup server along with another server. Therefore, move the contents of the backup server to tape on a regular basis.

Use the Long Tape Rotation System

Suppose that your workplace is doing a two-week tape rotation. This is not problematic, until one day you get corrupted data on the server. When trying to restore, it turns out the backup already contains data that is corrupt. It turned out that data corruption has occurred for some time and got worse. These is the reason for the necessity of testing backups on a regular basis, but also do a long rotation system or at least save some tape as a long-term archival backups.