Author Archive: Stanley Soman

October 13, 2016

Backup any Linux box on SoftLayer

The safest copy is an offline copy. In this article, we’ll cover how to backup entire partitions in Linux systems. It'll utilize the tar command in Softlayer's unique rescue environment and showcase the simplicity and flexibility of the process.

We begin by quickly identifying and becoming familiar with our filesystems.

1. Log into your server as the root user type: df -h

Log into your server as the root user type: df -h



2. Take note of the filesystem column and note the / mount has the filesystem /dev/sda2.

This is our root partition. Make note of it as it'll be needed once our system is in the rescue layer. Our rescue layer is our diagnostic layer where customers can troubleshoot and backup files.



3. Once you are sure you want to make backups of files, initiate the rescue layer. It will not wipe your data but it will reboot your server and unmount your existing partitions.

Follow these steps to initiate the rescue layer:

http://knowledgelayer.softlayer.com/procedure/launch-rescue-kernel



4. After you initiate rescue layer, wait five to six minutes for the rescue layer to finish loading. Then login to the server using SSH. You can find the rescue layer password by going into your Customer Portal (http://control.softlayer.com). Navigate from the Device tab to the Devices List. Select and click on your device name. Click the Passwords tab. Click on the asterisks to reveal your password.

5. Once you’re logged into the rescue layer, you’ll need to mount your partitions.

6. Now mount the root (/) partition in the rescue layer:

    mount /dev/sda2 /mnt

7. Then we’ll need to quickly mount the rest of the partitions under /mnt. You can do this by running the command below:

cat /mnt/etc/fstab | grep UUID | egrep -v 'swap|/ *ext' | awk -F= '{print $2" /mnt"$3}' | awk '{print $1" /mnt"$2}' | xargs -I {} echo mount -U {}

This results in mount commands to mount the rest of the filesystems. Simple, right? Be sure to save that command; it'll expedite your rescue layer troubleshooting next time.

This results in mount commands to mount the rest of the filesystems. Simple, right? Be sure to save that command; it'll expedite your rescue layer troubleshooting next time.

8. Triple left-click each line to select the full line, then right-click to paste and run that command to mount each partition.

9. If you want to see all your previously mounted filesystems, we can access them by chrooting as follows: chroot /mnt

  1. Browse to the main folder (aka root folder /):

    cd /

     
  2. Before we finish, make a backups folder to contain your backups:

    mkdir backups

Now make backups using the tar command in the compressed format tar.gz. To make backups using tar.gz, we’ll make a backup of a very common and important partition: /home

1. Browse to root:

    cd /

2. Run the following

    tar -pzcvf /backups/fullbackup.tar.gz --directory=/home --exclude=backups .

 

A quick explanation of the flags:

  • -p tells us to preserve file permissions
  • -z tells us to compress the files
  • -c tells us to create the tar.gz file
  • -v gives us visible output
  • -f lets us know the filename we're working with
  • -directory=/ tells us where the backups should start. Be sure to include the "." In the tar command as shown above.


It is always recommended that you test your backups to make sure they have the files you need and data's integrity is preserved. Once you've made the backup file, you can reboot the machine and download the file to restore it on another server.

3. To restore that file, upload it via SFTP to your root directory, then in SSH run the following:

    tar -pzxvf fullbackup.tar.gz -C /home



A quick explanation of the flags:  -c /home tells us to first browse to the /home directory and then begin to extract the .tar.gz file. By default, the restoration will overwrite any file with the same name. There are flags such as "--keep-old-files," which prevent you from replacing existing files on the disk, and "--keep-newer-files" when you don't want to replace newer existing files, e.g. tar -pzxvf fullbackup.tar.gz -C /home --keep-newer-files.

 

-Stanley

Keywords: 
September 19, 2016

Speed up your WordPress with SoftLayer

WordPress is one of the most popular content management systems available—lots of websites and blogs use it. But one of its biggest problems is speed. As users install plugins and add blog content, site speed decreases over time. There are many factors contributing to this, from PHP execution time, database load, CPU load, memory, and of course, website traffic. This, in turn, can lead to revenue loss, traffic bounce, and decreased conversions and click-throughs.

To combat these issues, the team at Prime Strategy created the Kusanagi Ready Project. Kusanagi is a compilation of images of server-side configurations that sets up the perfect environment for any WordPress installation. The images come with an easy-to-setup GUI that allows users to select multiple configurations, carefully prescreened for an optimized WordPress experience. The customized image not only benefits WordPress installations but your general site as well. You can select between Nginx or Apache. You can take advantage of PHP5, PHP7, or Facebook's ultra-fast HHVM PHP handlers and optionally add APCu or OPCache.

If that sounds interesting, you'll be excited to learn that the team at Prime Strategy compiled this on the latest centOS, centOS 7! Some of the few reasons why you'd want to try out Kusanagi include increased caching, optimized PHP handlers, and custom configurations for both Apache and Nginx, offering a stable OS with long-term support.

In tests conducted by the Kusanagi team using the ab benchmark, the optimized WordPress loaded an impressive 1,000 percent faster than a regular installation. Now that is performance! What's even better is that SoftLayer now offers Kusanagi images for our customers to order servers from. You can choose between monthly or hourly virtual servers and have blazing fast servers without wasting too much time at your fingertips.

The steps to deploy Kusanagi through SoftLayer can be found here.

 

-Stanley

Categories: 
June 10, 2015

Work Life of a Customer Support Technician

My day as a customer support technician begins very early. I leave home at 6 a.m. to start my shift at 7 a.m., relieving the overnight shift. Customers start calling, opening tickets, and chat sessions almost immediately after I log into one of our systems, either LivePerson Agent Console, Cisco Phone Agent, or SoftLayer’s ticket management system, which is dependent on employee scheduling, specialty, or customer traffic.

Should our customers ever need help, we are prepared and up-to-date as possible on what’s going on with our internal systems. Every morning I check for any notices received via email from different internal teams about updates to the network, server upgrades, or emergency maintenances that could be relevant to the tickets and questions of the day. Besides current update notifications we use to address customer questions and concerns, we also use our external wikis (also known as the KnowledgeLayer) for existing information should we need it. As customer support technicians, we also have unprecedented access to troubleshooting, managing, and restoring customers’ various services to the peak of their performance.

Thank you for calling SoftLayer. How can I help you?
At the beginning of the week, the phone starts ringing around 7:30 a.m., and then it starts to pick up—Monday’s are usually the busiest.

When a phone call comes in, I verify the caller and then try to get a grasp on the nature of the situation. Sometimes, for example, it’s a customer needing help troubleshooting an eVault backup solution. In most situations, I ask if they have checked the official tutorials posted by SoftLayer on how to set up eVault (or other topic at hand). Whether they have or not, I then walk the customer through the steps. Some topics can be a little confusing, and depending on the level of technical difficulty and the customer’s knowledge, I sometimes take care of the job for them. Some issues can be difficult, but that’s why we’re here. In regards to the eVault solution, thankfully, it comes with a help file containing screenshots to help customers of any technical level grasp the configuration process.

We also receive calls that aren’t one-on-one, but rather from an entire IT department of a company. In one particular instance, I received a call asking for help to change the boot order on a couple of production servers. Rebooting without permission can have catastrophic effects on any live data being written to servers. We need permission first. After receiving approval via ticket, I worked with the IT team as they turned off applications safely on their respective servers so that I could in turn reboot one-by-one and change the boot order from the BIOS as needed. (SoftLayer's customer support technicians change the boot order because the BIOS on servers are protected to prevent manual tampering with server hardware.)

One last example—hard-pressed system administrators working against the clock to deploy their load balancers need VIPs set up as soon as possible, so they can handle the traffic to their blooming social media website. In this case, depending on the type of load balancer, I first check with sales on the pricing. Then I open a ticket to get customer approval for the costs of the IPs. If it’s a Netscaler VPX load balancer, we inform the customer to order portable IPs within the same VLAN as their load balancer. Once confirmed, I get to work. Thankfully, Citrix Netscaler has a very easy to use interface that allows migrating portable IPs for use plus they take effect almost immediately.

No matter the customer or the situation, we always practice working in a professional demeanor to make sure we efficiently address the problem. Once I finish helping a customer, I follow up with a summary of what had been done and then make sure everything is working as needed. A summary of my actions is also posted on the ticket for customer future reference.

Opening a Ticket
We aim to give an initial response within 15 minutes of each ticket being opened. Tickets not only provide a great way to follow up with a customer, but they also provide a platform for directly sending the customer helpful guides, steps, screenshots, and explanations that would have not have sufficed over the phone call.

Tickets allow customers to specify the queue and title of the ticket, which narrows the issue to the department they feel would best answer their question. For example, if a customer opens a ticket saying they can't see all their devices in their device list with a title “devices not listed,” it gives us clues about the nature of the problem. By opening a ticket with the support group, instead of, say, the sales group, we know that this isn't an issue with ordering servers or ordered servers.

To troubleshoot the devices-not-listed above, I would check if the user who opened the ticket is a master user for the account. If not, then it is without a doubt a permissions issue or limited permissions set by the master user. To resolve an issue like this, the master user on the account would need to update permissions.

But that’s not always the case. If it’s not a permissions issue, then as customer support technician I'd be limited in the support I can offer. The issue for the devices not being listed could potentially be an internal bug, which is a job for SoftLayer’s development team. Once escalated to them, they would oversee the problem. During the escalation, the customer support team keeps the customer informed. We also work as the “go-to" between SoftLayer’s internal teams and customer.

Once the devices-not-listed issue has been resolved, SoftLayer’s development team would mark the escalation resolved. My team would then follow up with the customer to verify that the issue is resolved. This multi-step, inter-department interaction (depending on the severity of the problem) can take as little as a couple of hours to sometimes days. Regardless of the length of time, the customer is always kept in the loop of any changes or updates.

After ensuring the issue is resolved, we inform the customer that if there are no more replies within four days, the ticket automatically closes. This provides ample time for the customer to review the conversation and join in later if need be.

Quitting Time
As a customer support technician, I never know what question or concern might arise, but we try our best to always help the customer as best we can.

My shift begins to wind down around 3 p.m. when the next shift takes over. Our customer support technicians work late into the night and into the morning, 24x7x365.

-Stanley

Subscribe to Author Archive: %