DEV Community: Meghna Meghwani

How to Use git reset to Revert to Previous Commit in Git

Meghna Meghwani — Sat, 29 Aug 2026 07:38:52 +0000

Have you committed too early, included the wrong files, or taken a local branch in a direction you no longer want? Git Reset to Previous Commit lets you move that branch back to an earlier commit using git reset. The difficult part isn’t typing the command. It’s choosing what should happen to the changes that came after the target commit.

This guide shows how to use git reset to revert to a previous commit while protecting the work you may still need. It is written for developers who are comfortable running basic Git commands but want a safer way to undo local commits. You’ll learn how Git’s three reset modes behave, practice them in a disposable repository, handle common scenarios, and recover when a reset goes farther than intended.

Quick safety rule: If the commits are already on a shared remote branch, pause before using git reset. In most team workflows, git revert is the safer choice because it preserves the published history.

TL;DR

Use git reset --soft HEAD~1 to remove the latest commit while keeping its changes staged.
Use git reset HEAD~1 to remove the latest commit while keeping its changes unstaged. This is the default --mixed behavior.
Use git reset --hard HEAD~1 only when you intentionally want to discard tracked changes as well as commits.
Inspect git status, git log, and git diff before and after resetting.
Prefer git revert for commits that teammates may already have pulled.
If you reset to the wrong place, use git reflog to locate the earlier branch position.

Before You Reset: Decide Whether History May Be Rewritten

The key question to ask first is not, “Which reset mode is right for me?” It is “Does anyone else depend on this branch history?”

git reset changes where the current branch points. A commit can disappear from the visible path of that branch even though Git may retain the underlying object for some time.

That is convenient on a private feature branch. On a shared branch such as main, however, rewriting the published sequence can leave another developer’s local history out of sync.

Use this decision table before running anything:

Git’s official documentation separates these jobs clearly: git reset moves a branch or updates the index, while git revert records a new commit that reverses an earlier commit.

If your team deploys from Git, history changes can also affect the commit a server expects to fetch. Review the deployment pipeline before rewriting any branch used in production.

Understand What git reset Actually Changes

A Git project has three working layers that matter during a reset:

HEAD and the current branch: HEAD normally refers to the branch you have checked out, and that branch points to a commit.
The index: Also called the staging area, it stores the snapshot prepared for the next commit.
The working tree: These are the files you can currently open and edit.

When you run:

git reset <target-commit>

Git moves the current branch to . The mode determines whether Git also changes the index and working tree.

If no mode is supplied, Git uses --mixed.

Two details prevent common surprises:

--hard can overwrite modifications to tracked files. Commit, stash, or back up anything you may need first.
A hard reset does not generally remove ordinary untracked files. Removing untracked files is a separate operation, commonly handled with git clean, which is outside the reset itself.

There are additional options such as --merge and --keep, but they solve narrower cases involving local changes and merge-like resets.

For the everyday task of returning a private branch to an earlier commit, soft, mixed, and hard are the modes worth understanding first.

Read Full Article: https://serveravatar.com/git-reset

How to Fix Error Establishing a Database Connection in WordPress

Meghna Meghwani — Thu, 27 Aug 2026 06:42:13 +0000

You’re working on your WordPress site. Everything looks fine one minute, and the next, a stark white page with a single line of text stares back at you: “Error Establishing a Database Connection”. This WordPress database connection error means your posts, pages, comments, user data, all of it lives inside that database. And WordPress is telling you it can’t reach it anymore.

I’ve been there. More importantly, I’ve fixed this error on dozens of sites, my own, client projects, and staging environments that somehow got into a bad state overnight. The good news is this: it’s almost always solvable, and it usually doesn’t take long.

This guide walks you through every real cause of this error and every real fix, ordered from the most common to the least common. I will explain what’s actually happening at each step, not just what to type, because understanding the “why” is what makes you faster the next time this happens.

TL;DR

Here’s the quick version before you dive in:

Most common cause: Wrong database credentials in wp-config.php
Second most common: Corrupted database tables from failed updates or plugin conflicts
Quickest test: Add WP_ALLOW_REPAIR to wp-config.php and visit the repair page
Always back up first, before touching anything
If multiple sites are down at once, it’s server issue, not a WordPress issue

What Triggers This Error?

Before reaching for fixes, it helps to understand the architecture. WordPress is a PHP application. Every time a visitor lands on your site, PHP code runs, asks your MySQL database for the content, and assembles a page to send back.

When that handshake breaks, you get the error. Here’s what typically causes it:

1. Incorrect Database Credentials

WordPress stores four critical pieces of information in your wp-config.php file, the database name, the username, the password, and the hostname. If any one of those is wrong, the connection gets refused. This is the single most common cause, responsible for the majority of cases I see.

2. Corrupted Database Tables

Over time, database tables can become corrupted, especially after a plugin fails mid-update, a theme install gets interrupted, or the server loses power at the wrong moment. When the table structure breaks, WordPress can’t read the data it needs, even if the credentials are perfect.

3. Database User Loses Permissions

A database user can exist with the right password but without the right privileges. MySQL permissions are managed separately from login credentials. If something strips those permissions, a bad migration script, a one-click “optimization” tool, or a hosting control panel glitch, WordPress gets locked out despite having correct-looking credentials.

4. The MySQL Server Itself Is Unresponsive

Sometimes the problem isn’t WordPress or your config, it’s that the MySQL service has stopped, run out of memory, or is being overwhelmed. This is a server-level problem, and it requires server-level attention.

5. Sudden Traffic Spikes Overwhelming the Database

A single plugin that goes viral on Hacker News, a social media mention from an influencer, these can flood your server with simultaneous connection requests. MySQL has a limit on concurrent connections, and when that limit fills up, new requests get refused.

6. Corrupted WordPress Core Files

This is rarer, but if a core WordPress file that handles database communication gets damaged, from a failed auto-update, for example, it can produce this exact error even when everything else is fine.

Step-by-Step: How to Fix the Error

Follow these steps in order. Each one eliminates a common cause. If step one doesn’t solve it, move to step two. By the time you reach step seven, you’ll have ruled out almost everything.

Step 1: Create a Backup Before Making Changes

Before troubleshooting database problems, create a backup of your website. Ideally, your backup should include:

WordPress files
WordPress database
Important configuration files

This gives you a recovery point if a repair operation or configuration change causes another problem.

Creating a Backup with ServerAvatar

If your WordPress website is managed through ServerAvatar, you can create website backup directly from the ServerAvatar dashboard.

ServerAvatar supports application backups that include the application’s files and associated database. It also provides options for storing backups to ServerAvatar storage or to your own cloud-storage provider from available options.

Important: Do not assume that a backup exists simply because backups were configured previously. Check that recent backups are actually available before proceeding.

Step 2: Verify Your Database Credentials in wp-config.php

This is one of the first things you should check. The wp-config.php file is normally located in the root directory of your WordPress installation.

Look for:

/** The name of the database for WordPress */
define( 'DB_NAME', 'your_database_name' );

/** MySQL database username */
define( 'DB_USER', 'your_username' );

/** MySQL database password */
define( 'DB_PASSWORD', 'your_password' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

For more information about the config file and its database-related settings, see the official WordPress wp-config.php documentation

Managing Database Details with ServerAvatar

If your server is managed through ServerAvatar, you can manage databases and database users through the ServerAvatar dashboard instead of relying entirely on command-line database administration.

Navigate to your server panel by clicking on the server dashboard icon.

Go to the Application section, and click on your WordPress application dashboard icon.

Navigate to the File Manager section from the left sidebar, and navigate to the public_html folder.

Open the wp-config.php file.

Check each mentioned value carefully:

DB_NAME : Make sure the database exists and that the name matches the database assigned to your WordPress installation.
DB_USER : Confirm that the database user exists.
DB_PASSWORD : Make sure the password matches the password configured for that database user.
DB_HOST : localhost is common when the database is running on the same server, but the correct value depends on your server architecture.

Do not automatically replace DB_HOST with localhost unless you know that the database is running locally.

After confirming the correct credentials, make sure the values in wp-config.php match your database configuration.

Read Full Article: https://serveravatar.com/wordpress-database-connection-error

How to Secure PHP Web Application: Best Security Practices

Meghna Meghwani — Wed, 26 Aug 2026 07:41:15 +0000

PHP remains one of the most widely used server-side technologies, powering around 70% of websites whose server-side programming language is known. That dominance also makes it a prime target. Every day, thousands of automated bots scan the web looking for vulnerable PHP applications, unpatched versions, insecure configurations, sloppy input handling. If you’re building or managing a PHP app today, learning how to secure PHP web application is essential to protect your application from potential security threats.

This isn’t a scare tactic. It’s the reality of deploying software on the internet in 2026. The good news: PHP has matured significantly, and modern PHP (8.x) offers security primitives that match any other server-side language. The bad news: security still depends almost entirely on how you write, configure, and maintain your code. Language-level protections only go so far.

This guide covers the essential layers of PHP application security, from php.ini hardening to SAST tooling, from SQL injection prevention to Content Security Policy headers. Whether you’re running a Laravel app, a WordPress site, or a custom PHP project, these practices apply.

TL;DR

Lock down php.ini before deploying, disable dangerous functions, hide PHP version headers, restrict file uploads
Use PDO prepared statements for every database query, no exceptions
Escape every variable at output time with context-aware encoding, htmlspecialchars() for HTML, json_encode() for JavaScript
Use CSP headers (Content Security Policy) to add an XSS defense layer beyond output encoding
Hash passwords with PASSWORD_ARGON2ID or PASSWORD_BCRYPT , never MD5 or SHA1, ever
Harden PHP sessions: HttpOnly, Secure, SameSite=Lax, strict mode, and session ID regeneration on login
Add CSRF tokens to every state-changing form using hash_equals() for timing-safe comparison
Run composer audit in CI on every push, dependency vulnerabilities are low-effort attack vectors
Integrate SAST tools (Psalm, PHPStan) into your development workflow to catch security issues before they reach production
Set HTTP security headers on every response: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Permissions-Policy

Why PHP Security Still Matters

PHP has changed considerably over the years. Many security problems associated with older PHP releases came from outdated features, weak defaults, poor development practices, or obsolete libraries.

Modern PHP applications can be highly secure when they are:

Properly configured
Regularly updated
Developed using secure coding practices
Protected by multiple security layers
Continuously monitored for vulnerabilities

The bigger challenge is PHP’s enormous ecosystem. Attackers can automatically search the internet for applications containing:

Outdated WordPress components
Vulnerable Composer dependencies
Exposed .env files
Debug mode enabled in production
Weak authentication
Unsafe file upload functionality
Poorly validated input
Known vulnerable PHP versions

Security Is Also a Business Issue

A compromised application can cause more than technical problems. A successful attack may result in:

Customer data exposure
Account takeovers
Website defacement
Malware distribution
Search engine reputation problems
Loss of customer trust
Downtime
Regulatory or compliance problems
Financial losses

The goal isn’t to make an application completely immune to attacks. Instead, build multiple security layers so that a single mistake doesn’t automatically become a successful compromise.

Let’s get into the actual hardening steps.

Read Full Article: https://serveravatar.com/secure-php-application

GitHub Explained: What It Is, How It Works, and How to Use It

Meghna Meghwani — Mon, 24 Aug 2026 07:28:56 +0000

If you’ve ever joined a development team and felt lost when someone said “push to main,” “open a pull request,” or “what branch are you on,” you’re not alone. GitHub is one of those tools that developers take for granted, they assume everyone knows it, but the reality is that most newcomers stumble through it at first.

This guide is for those people: anyone who wants to understand what GitHub actually is, why it matters, and how to put it to work when deploying web applications through a platform like ServerAvatar.

We will cover everything from the raw concept of version control to actually connecting your GitHub account to ServerAvatar and getting your code live on a server without touching a command line. No prior experience needed.

TL;DR

Git is a distributed version control system that tracks every change made to your project files
GitHub is a cloud platform that hosts Git repositories and makes collaboration practical
Branching lets you work on features in isolation; merging combines those changes back in
Pull requests create a formal review process before code is merged
ServerAvatar connects directly to GitHub and can clone, deploy, and auto-update your PHP and Node.js applications
For private repos, you’ll add an SSH key to GitHub; for public repos, a simple HTTPS URL works
Webhooks let GitHub notify ServerAvatar automatically whenever you push new code
Deployment scripts let you run framework commands (cache clears, migrations, builds) after every pull

Before understanding GitHub, it helps to understand Git itself.

What Is Git?

Git is a distributed version control platform introduced by Linus Torvalds in 2005 to help developers efficiently manage and track changes in their code. It records changes made to a project’s files, allowing developers to track, compare, restore, and collaborate on different versions of their code.

What Git Does

Tracks code changes: Records what was added, modified, or removed.
Maintains project history: Keeps a detailed record of previous versions and commits.
Creates restore points: Lets you return to an earlier working version when something breaks.
Supports experimentation: Developers can work on new features without changing the stable version of the project.
Works offline: Git runs locally, so you can commit and manage changes without an internet connection.
Supports collaboration: Multiple developers can work on the same codebase and combine their changes.
Keeps a complete project copy: Every Git clone contains the repository’s files and history, reducing dependency on a single server.

Git Is Distributed

Git is called a distributed version control system because every developer who clones a repository gets a local copy of the project and its history.

This means developers can:

Create commits without an internet connection.
Review previous commits locally.
Create and switch between branches.
Compare changes.
Continue working even when a remote Git server is unavailable.

Once an internet connection is available, local changes can be pushed to a remote repository such as GitHub.

Git Is Not GitHub

Git and GitHub are closely related, but they are different:

Git is the version control software.
GitHub is an online platform that hosts Git repositories and provides collaboration tools.

You can use Git without GitHub. GitHub simply makes it easier to store Git repositories remotely and work with other developers.

If Git isn’t installed on your Ubuntu system yet, follow our guide on how to install Git on Ubuntu before using Git commands locally.

What Is GitHub?

GitHub is a web-based platform for hosting Git repositories and collaborating on software projects. It combines Git’s version control capabilities with tools for code review, project management, automation, and team collaboration.

Read Full Article: https://serveravatar.com/what-is-github

How to Fix HTTP 503 Service Unavailable Error (Complete 2026 Guide)

Meghna Meghwani — Sat, 22 Aug 2026 07:00:00 +0000

You refresh your website. Instead of loading, you get a blank white page with four words: HTTP 503 Service Unavailable Error. No explanation. No timeline. No next step. Whether you’re managing a WordPress site, an eCommerce store, or a web application, the HTTP 503 Service Unavailable Error can instantly make your website inaccessible to visitors and impact your business.

I’ve been there. Not just as a user, but as someone responsible for the server when that message started appearing for hundreds of real visitors. The 503 error is frustrating because it tells you something is wrong but gives you almost nothing to work with.

Here’s the good news: it almost always has a fixable cause, and you can usually identify it in under ten minutes if you know where to look. This guide walks through everything, what the error actually means, why it happens, how to diagnose it systematically, and how to fix it. Let’s get into it.

TL;DR

HTTP 503 means your server can’t handle requests right now, temporarily or otherwise
The most frequent causes include server overload, scheduled maintenance, application process failures, incorrect firewall configurations, and DNS-related problems.
Diagnosis starts with checking server resource usage and reading logs
Most 503 errors clear within minutes; persistent ones usually need manual intervention
ServerAvatar’s dashboard gives you resource monitoring, process management, and log access in one place, no CLI required for most diagnoses

What Is HTTP 503, Really?

503 is a status code in the 5xx range, which means something went wrong on the server side. Unlike 404 (not found) or 403 (forbidden), a 503 isn’t telling you the resource doesn’t exist; it’s telling you the server exists but can’t respond right now.

Here’s the part most people skip: 503 is a signal, not a diagnosis. It doesn’t tell you why the server is unavailable. That ambiguity is what makes it tricky. The cause could be as simple as a background service that crashed or as complex as a database server running out of memory.

On the user’s end, the only real option is to wait a bit and attempt it again later. From a developer or sysadmin perspective, you’ve got work to do.

One important distinction: 503 can be temporary or permanent, depending on what’s causing it. A server under a DDoS attack might recover once traffic normalizes. A misconfigured firewall rule, on the other hand, will keep throwing 503 indefinitely until someone fixes it.

HTTP 503 vs Other Common HTTP Errors

Why 503 Errors Happen: The Real Causes

Let me group these by where the problem originates, because that’s how you actually troubleshoot.

Read Full Article: https://serveravatar.com/fix-http-503-service-unavailable-error/

How to Find Large Files and Directories in Linux

Meghna Meghwani — Fri, 21 Aug 2026 06:33:55 +0000

Disk space doesn’t vanish, it accumulates. One day your server is fine; the next, find large files and directories in Linux to uncover what filled your storage.

This is one of the most common scenarios I encounter in day-to-day server management. And on Linux, unlike desktop operating systems, there’s no friendly animation telling you where space went. You have to find it yourself.

The good news: Linux ships with powerful built-in tools for exactly this. And there are lightweight third-party utilities that make the process much less painful. I’ve used these tools across dozens of servers, development boxes, production VPS instances, and everything in between. Some of them have saved me hours of detective work.

This guide walks you through how to find large files and directories in Linux, from quick one-liners to interactive analyzers, and explains the nuances that documentation rarely covers.

Why Disk Space Management Matters on Linux

Running out of disk space can affect much more than file storage. A nearly full filesystem can prevent applications from writing data, break database operations, interrupt deployments, and cause system services to fail.

Common sources of unexpected disk usage include:

Log files that continuously grow because of application errors or verbose logging.

Learn more about Linux logging, common log locations, and how log files are used in our guide to Linux logs.

Database backups and snapshots that are never removed.
Compressed backup archives such as .rar, .zip, and .tar files can also consume significant storage when old copies are retained.

If you need to work with RAR archives on Linux, see our guide on How to Open, Extract and Create RAR Files in Linux.

Container images and volumes left behind after testing.
CI/CD build artifacts that accumulate over time.
Package caches containing outdated packages.
Temporary files created by applications and system processes.
Old application releases that are no longer required.
Backup jobs writing files to an unexpected location.

Why regular disk checks are important

A simple disk-space monitoring routine can help you:

Detect storage problems before they become critical.
Identify which filesystem is filling up.
Find unusually large directories and files.
Discover deleted files that are still consuming space.
Prevent applications from failing because of insufficient storage.
Keep production servers healthy and predictable.

Tip: Don’t wait until a filesystem reaches 100%. Investigate sustained usage above 80% and treat 90%+ as a warning that requires attention.

Check Overall Disk Usage First

Before searching for individual files, determine which filesystem is consuming the most space.

The df command provides a summary of disk usage for mounted filesystems.

df -h

The -h flag gives you human-readable output, gigabytes and megabytes instead of raw block counts.

You can also review the official GNU ‘df’ documentation for additional options such as -i, -T, and -x.

Here’s what the output typically looks like:

Filesystem     Size   Used   Avail   Use%   Mounted on
/dev/sda1      100G    78G     22G    78%   /
/dev/sdb1      500G   450G     50G    90%   /mnt/backup
tmpfs          2.0G      0    2.0G     0%   /tmp

Pay particular attention to:

Size: Total filesystem capacity.
Used: Space currently occupied.
Avail: Remaining available space.
Use%: Percentage of the filesystem in use.
Mounted on: Location where the filesystem is accessible.

In the example above, /mnt/backup is at 90%, making it the first location to investigate.

For more details about df, du, and other filesystem utilities, see the GNU Coreutils documentation.

Check inode usage

Disk space isn’t the only resource that can run out. Linux filesystems also have a finite number of inodes, which store metadata about files.

Check inode consumption with:

df -i

Here’s what the output typically looks like:

Inode exhaustion can occur when a server contains millions of small files, even when plenty of disk capacity remains.

For example:

A server may have 100 GB of free disk space.
But all available inodes may already be consumed.
Creating a new file can then fail despite the available storage.

For a deeper explanation of what an inode stores, see the Linux ‘inode(7)’ manual page.

Read Full Article: https://serveravatar.com/find-large-files-directories-linux

What Is Laravel Octane? Benefits, Features & How to Use It

Meghna Meghwani — Thu, 20 Aug 2026 06:00:00 +0000

If you’ve been working with Laravel Octane for a while, you’ve probably noticed something: every time a user hits your site, Laravel has to boot itself from scratch. Service providers load, the container registers, middleware fires, all for a single request that might take 50 milliseconds. Multiply that by a thousand concurrent users, and you’re asking PHP to do an enormous amount of repeated work. Laravel Octane addresses this bottleneck by keeping your application in memory between requests, reducing repeated bootstrapping and helping improve application performance.

That’s the exact problem Laravel Octane was built to solve.

In this guide, I’m going to walk you through what Laravel Octane is, how it changes the way your PHP application handles requests, which server options you have, and whether it’s worth adding to your stack. I’ve been running Laravel applications for a few years now, and I’ve tested Octane on both small side projects and production apps handling real traffic. I’ll share what actually matters, not just the marketing version.

TL;DR

Laravel Octane keeps the framework booted in memory, eliminating 30–100ms of boot overhead on every request
Traditional Laravel handles 300–600 requests/second; Octane pushes 1,800–3,000+ requests/second on the same hardware
Choose RoadRunner for easy setup and broad compatibility, or Swoole for maximum performance and advanced features
Key features include persistent workers, concurrent task processing (Swoole), ticks/intervals (Swoole), Octane cache, and Octane tables
Requires PHP 8.0+ and a server where you control the PHP environment
Not suitable for shared hosting or teams unfamiliar with stateful PHP patterns
Test thoroughly before production deployment, particularly around memory usage and global state

What Laravel Octane Actually Is

Laravel Octane is an official Laravel package (created by Taylor Otwell) that dramatically speeds up your Laravel application by keeping the framework booted in memory between requests.

Think of it like this: a traditional Laravel app is like a restaurant where the kitchen staff has to set up all their ingredients, turn on every burner, and prep every dish from zero every time someone orders. Laravel Octane is like a kitchen where everything stays hot and ready, you just plate and serve.

Technically, Octane runs your Laravel app on top of a high-performance PHP server, either Swoole or RoadRunner, instead of the traditional PHP-FPM approach. This lets PHP hold the framework in memory across multiple requests, eliminating the boot-time overhead that happens on every single page load.

One important thing to know: Octane requires PHP 8.0 or higher. If you’re on an older version, that’s the first thing to sort out before even thinking about Octane.

The Performance Problem with Traditional Laravel

Here’s what actually happens when a request hits a standard Laravel app running on Nginx and PHP-FPM:

PHP-FPM spins up a worker process
That worker loads your Laravel app
All service providers register themselves
The framework boots
Middleware runs
Your controller does its work
A response goes back
The worker sits idle or gets recycled

This cycle repeats for every single request. On a low-traffic site, you won’t notice. But when you’re handling even a few hundred requests per second, you’re wasting server resources booting the same framework over and over instead of doing actual work.

The numbers add up fast. A typical Laravel app spends 30–100ms just on framework boot, before your controller even runs. That’s a massive tax on every request.

How Octane Fixes It

Instead of booting fresh for each request, Octane boots the framework once and keeps it in memory. When a request comes in, a worker picks it up, runs it through the already-booted framework, and sends the response back, without ever re-booting.

The result? Your application spends its CPU cycles on your code, not on Laravel’s boot process. For I/O-heavy applications, API endpoints hitting databases, external APIs, and queue workers, this is a game-changer.

Read Full Article: https://serveravatar.com/laravel-octane

How to Open, Extract and Create RAR Files in Linux

Meghna Meghwani — Wed, 19 Aug 2026 07:33:31 +0000

Picture this: You’ve been handed SSH access to a client’s production server. Your job is to pull logs, create RAR Files in Linux, and bring them for analysis. Simple enough, until you realize the directory you need to archive contains hundreds of files, and the upload limit on the client’s portal only accepts archives under 50 MB.

You could zip everything. But the logs total 200 MB uncompressed, and you need the archive to split cleanly into parts so each chunk uploads independently. That’s when someone on the team says: “Just use RAR”.

If you’ve heard of RAR but never quite understood when or why you’d reach for it on a Linux server, this guide is for you. We’re going to walk through everything from what the RAR format actually is, to extracting your first archive, creating password-protected archives, splitting large files, and knowing when RAR is the right tool versus when something like ZIP or tar would serve you better.

By the end, you’ll be comfortable working with RAR files on any Linux machine, and more importantly, you’ll know when to reach for a different tool altogether.

TL;DR

RAR is a compressed archive format that handles large file splitting and optional encryption well
On Ubuntu/Debian, install with sudo apt-get install unrar rar
Extract with unrar x archive.rar or unrar x archive.rar /destination/
Create with rar a archive_name.rar files_or_folder
Add -p flag for password protection; use -v[size] to split archives
Test archives before sharing with unrar t archive.rar
For most Linux use, ZIP and tar.gz are more widely compatible, but RAR wins for split archives and Windows cross-compatibility

What Is the RAR Format? Why Does It Still Exist?

RAR stands for Roshal Archive, named after its original developer Eugene Roshal. It is a compressed archive format used to store one or more files in a single archive. It first appeared in the early 1990s as a Windows-native format designed to compress files more efficiently than the prevailing options at the time.

The format gained massive popularity on Windows through WinRAR, the de facto tool for handling .rar files on that platform. Even today, you’ll frequently encounter RAR archives when downloading software, game mods, or shared project files from the internet. It’s everywhere, which is precisely why Linux server administrators need to know how to handle them.

Over time, RAR developed several capabilities that set it apart:

Solid compression: RAR groups similar files together during compression, which can produce smaller archive sizes compared to compressing the same files individually.
Recovery records: Optional built-in error recovery data lets RAR reconstruct minor archive corruptions.
Split archives: You can break a large archive into multiple smaller files (like archive.part1.rar, archive.part2.rar, etc.), which is genuinely useful for circumventing upload size limits or fitting files onto smaller storage media.
Password protection: AES-256 encryption is available, keeping archive contents private.

For technical details about RAR’s encryption, recovery records, and archive structure, see the official RAR 5.0 format documentation.

That said, RAR is a proprietary format. The official tools (rar and unrar) are closed-source, which matters in some enterprise or open-source-first environments. This is one reason you will see many Linux admins defaulting to ZIP or tar.gz instead.

You can learn more about the RAR file format it’s work from RARLAB.

A Quick Comparison With ZIP and tar.gz

Before we go further, let’s look at how RAR stacks up against the two most common alternatives you’re likely to encounter on Linux.

RAR tends to squeeze out a bit more size reduction than ZIP, especially with mixed file types. Its split archive feature is genuinely harder to replicate with ZIP without a workaround. That said, if you’re working in a purely Linux environment, tar.gz is far more integrated, you’ll find it in cron jobs, backup scripts, and system tooling across virtually every distribution.

Before You Start: Installing the RAR Utilities

Here’s something that trips up a lot of beginners: Linux doesn’t ship with RAR support out of the box. Ubuntu, Debian, and most other distributions don’t include these tools in the base installation, you have to add them yourself.

The good news? It’s a quick install from the default repositories.

sudo apt-get update
sudo apt-get install unrar rar

That’s it. Two commands and you’re ready.

If you need the official RAR package for Linux, you can also find it on the RARLAB download page.

Read Full Article: https://serveravatar.com/rar-files-in-linux

How to Fix Too Many Authentication Failures Error in SSH

Meghna Meghwani — Mon, 17 Aug 2026 07:23:38 +0000

Picture this: you’re in the middle of a deployment, and suddenly your SSH connection refuses to connect. The server returns a Too Many Authentication Failures error like:

Received disconnect from host: 2: Too many authentication failures for root

You have entered the correct password. You have the correct SSH key. Nothing appears to be wrong with your credentials, yet the connection keeps failing. This error can be confusing because “Too many authentication failures” doesn’t necessarily mean that you entered the wrong password too many times.

One of the most common causes is that your SSH client is offering multiple identities, often from your SSH agent, before it gets to the correct key. The server reaches its MaxAuthTries limit and closes the connection before successful authentication can occur.

In this guide, we will explain why this happens, how to diagnose the exact cause, and several ways to fix it, from the quickest command-line solution to a permanent SSH configuration. We will also cover how to prevent the problem in CI/CD environments and some additional SSH security practices.

Let’s dig in.

TL;DR

A common cause of “Too many authentication failures” is that the SSH client offers multiple identities before successful authentication.
OpenSSH’s MaxAuthTries controls how many authentication attempts are permitted per connection. Its default is commonly 6.
Having many keys loaded into ssh-agent does not automatically mean there is a problem. The important question is which identities SSH actually offers during the connection.
Quick fix: Specify the correct key and use IdentitiesOnly=yes:

ssh -o IdentitiesOnly=yes -i ~/.ssh/your_specific_key user@hostname

Recommended long-term fix: Configure IdentitiesOnly yes and IdentityFile for the host in ~/.ssh/config.
Increasing MaxAuthTries can be useful in specific environments, but it should generally be a last resort.
For automation and CI/CD, explicitly specify the intended SSH identity instead of allowing the client to try multiple keys.

         SSH Client
             │
             ├── Work Key
             ├── GitHub Key
             ├── AWS Key
             ├── Old Key
             └── Correct Server Key
                    │
                    ▼
                SSH Server
                    │
                MaxAuthTries = 6
                    │
                    ▼
        Too many authentication failures

What Does “Too Many Authentication Failures” Actually Mean?

The error message can make it sound like you’ve simply entered an incorrect password too many times. That’s not necessarily what happened.

A common scenario looks like this:

Your SSH client has multiple identities available.
Some of those identities may come from ssh-agent.
SSH offers identities to the server during authentication.
The server rejects identities that aren’t authorized for the target account.
The number of authentication attempts reaches the server’s MaxAuthTries limit.
The server terminates the connection before the correct identity is successfully used.

OpenSSH’s MaxAuthTries setting controls the maximum number of authentication attempts permitted per connection. The default is commonly 6. The exact value can be changed by the server administrator.

You can refer to the OpenSSH sshd_config documentation for the current behavior and default values.

For example, imagine your SSH agent contains several keys:

work-key
github-key
aws-key
old-project-key
personal-key
server-key

Your intended server-key may be valid for the destination server, but if SSH offers several other identities first, the server may reach its authentication-attempt limit before the correct key gets a chance to authenticate.

This is why you can have a perfectly valid SSH key and still receive:

Too many authentication failures

Important clarification: Having more than six keys in your SSH agent does not automatically mean you will get this error.

The important thing is how many authentication attempts are actually made during the connection and how your SSH client and server are configured.

That’s why checking the verbose SSH output is important before changing server-side settings.

Why this matters for your fix: Most quick fixes just tell you to specify the key with -i. That’s not wrong, but it’s incomplete. The real fix is telling SSH to stop offering other keys entirely, which is what IdentitiesOnly yes does.

How SSH Agent Can Contribute to the Problem

An SSH agent such as ssh-agent can store multiple private-key identities so you don’t have to repeatedly enter passphrases.

You can check which keys are currently loaded with:

ssh-add -l

You might see something like:

256 SHA256:xxxx work-key (ED25519)
256 SHA256:xxxx github-key (ED25519)
256 SHA256:xxxx aws-key (ED25519)
256 SHA256:xxxx old-project-key (ED25519)
256 SHA256:xxxx personal-key (ED25519)

Having multiple keys isn’t inherently bad. The problem occurs when SSH offers identities that aren’t appropriate for the target server and consumes the server’s available authentication attempts before the correct identity succeeds.

This is one reason IdentitiesOnly yes is so useful. It allows you to tell SSH to use only the identity I explicitly configured for this host.

OpenSSH documents IdentitiesOnly specifically for situations where ssh-agent offers multiple identities.

Read Full Article: https://serveravatar.com/fix-too-many-authentication-failures-ssh

How to Set Up Amazon Lightsail Server with ServerAvatar

Meghna Meghwani — Sat, 15 Aug 2026 06:30:00 +0000

If you have been poking around AWS to host a website or web application, you’ve probably heard of Amazon Lightsail. An Amazon Lightsail Server is AWS’s simplified VPS offering, the short version of EC2 that strips away the most confusing parts while still giving you the reliability of Amazon’s infrastructure.

But here’s the catch: AWS itself isn’t simple. Even with Lightsail being the “easy” entry point, connecting it to a server management panel like ServerAvatar and actually getting a working server takes a few steps. You have to set up IAM permissions, create API credentials, navigate two dashboards, and then figure out what on earth to do during the installation process.

That’s exactly what this guide is for. I have walked through this process a few times, both on Amazon Lightsail and ServerAvatar. The AWS IAM setup is the part that trips most people up. Not because it’s complicated, but because the documentation assumes you already know what IAM is and why you’re creating a separate user instead of using your root account.

Let me walk you through it step-by-step. By the end of this guide, you’ll have a fully configured Amazon Lightsail server managed through ServerAvatar, ready to host your PHP or Node.js application.

TL;DR

What is Amazon Lightsail, and Why Use It with ServerAvatar?

Amazon Lightsail is a simplified cloud hosting service from AWS that makes it easier to launch and manage virtual private servers without dealing with the complexity of a full AWS infrastructure setup. It is well suited for developers, agencies, small businesses, and teams that need a straightforward VPS environment.

Why Choose Amazon Lightsail?

Lightsail provides a simpler way to get started with AWS while still benefiting from its underlying cloud infrastructure.

Simple VPS deployment: Launch a server with minimal configuration.
Predictable pricing: Plans include compute, SSD storage, and data transfer.
Flexible resources: Choose a server size based on your workload.
AWS infrastructure: Benefit from AWS’s cloud infrastructure and ecosystem.
Multiple use cases: Suitable for WordPress, PHP applications, APIs, and websites.

Where ServerAvatar Fits In

Lightsail provides the server, but server administration can still require SSH and command-line knowledge. ServerAvatar adds a graphical management layer that simplifies everyday tasks.

With ServerAvatar, you can:

Deploy and manage multiple websites.
Install and switch between PHP versions.
Create and manage databases.
Configure SSL certificates.
Manage Nginx, Apache, and OpenLiteSpeed.
Monitor server performance.
Manage cron jobs and backups.
Handle common server tasks from a centralized dashboard.

Why Combine Amazon Lightsail with ServerAvatar?

Using both services brings together the infrastructure capabilities of AWS with a more user-friendly server management experience.

Lightsail provides the VPS and cloud infrastructure. ServerAvatar handles server and website management.

Result: less command-line work and an easier way to manage production websites and applications.

Why Create an IAM User Instead of Using the Root Account?

Using your AWS root account for API access can create unnecessary security risks. The root account has unrestricted access to your AWS environment, so its credentials should be protected and used only when absolutely necessary.

Why Use a Dedicated IAM User?

Create a separate IAM (Identity and Access Management) user for ServerAvatar and grant it only the permissions required to manage your Lightsail resources.

Limits access: Give the user only the permissions needed for Amazon Lightsail.
Protects the root account: Avoid exposing root credentials to third-party platforms or applications.
Reduces security risks: If the IAM credentials are compromised, the potential impact is more limited than exposing root credentials.
Easy to revoke: You can disable or delete the IAM user’s access without affecting your main AWS account.
Better team management: Keep ServerAvatar’s credentials separate from those used by other developers or administrators.
Improves accountability: Dedicated credentials make it easier to identify which access belongs to ServerAvatar.
Safer third-party integration: ServerAvatar can connect using dedicated credentials instead of your unrestricted AWS root account.

Use the AWS root account for account-level administration, and create a dedicated IAM user with the required Lightsail permissions for ServerAvatar.

Read Full Article: https://serveravatar.com/set-up-amazon-lightsail-server-with-serveravatar

Website Load Testing Guide: Test Performance at Scale

Meghna Meghwani — Fri, 14 Aug 2026 06:15:00 +0000

If you’ve managed web servers or applications for any length of time, you’ve probably seen this happen: a new feature or campaign goes live, traffic suddenly spikes, and Website Load Testing becomes critical when your website starts returning 503 errors at exactly the moment you need it to perform.

What happens next is usually a scramble, SSH into a server you haven’t checked in months, inspect running processes, restart services, and make infrastructure changes based on guesswork. Eventually, the traffic settles, the site recovers, and the immediate crisis is over.

But that kind of incident is often preventable. Load testing helps you find your website’s limits before your users do.

In this guide, we will cover what load testing is, why it matters at every scale, how to run your first test using loader.io (the most accessible free tool available), what your results actually mean, how to find and fix bottlenecks, and how to make load testing a normal part of how you ship software.

TL;DR

Load testing answers one critical question: how many concurrent users can your server handle before it falls over?
Without it, you’re guessing about capacity, and guessing wrong right when it matters most
loader.io is the simplest free tool to get started: no install, browser-based, generous free tier
Your three essential numbers: concurrent user target, response time threshold, and peak traffic window
Run load tests before every major deployment, not after your site goes down

What Load Testing Actually Is

Let me clear up some confusion first, because “load testing” gets thrown around interchangeably with a few related terms that mean different things.

Load testing is specifically about simulating concurrent users hitting your site and measuring how your server behaves under a expected load. You’re asking: “When 500 people are on this site at the same time, what happens?”

Stress testing pushes beyond that, you keep adding users until something breaks, then you figure out exactly where the ceiling is. Soak testing holds a sustained load over hours or days to catch memory leaks or database connection pool exhaustion that only shows up over time.

Most small teams skip all of this and call it “load testing” when they open the site in three different browsers and hit refresh a few times. That’s not load testing. That’s optimism.

This distinction is important because each testing approach is designed to answer a specific performance question:

Load test: “Can the website reliably handle its expected peak traffic?”
Stress test: “At what point does this fall over, and what breaks first?”
Soak test: “Can the system maintain stable performance during prolonged, normal traffic without gradual degradation?”

A complete performance testing strategy should consider load, stress, and soak testing. For this guide, we’ll focus on load and stress testing since those are where most teams see the biggest gap in understanding.

Why Most Teams Skip It

I get it. Load testing feels like a luxury. You have a small server, modest traffic, and a product that’s still finding its feet. Why simulate load when you barely have any real load to speak of?

Here’s the uncomfortable truth: load testing is most valuable precisely when you can’t afford for things to go wrong. A startup that goes down during a product launch doesn’t get a second impression. A growing SaaS that crashes right when a customer is about to upgrade has just handed that customer a reason to reconsider.

The teams that skip load testing aren’t avoiding work, they’re accumulating risk. VPS that handles your blog fine today might handle 10x traffic fine too, or it might fall over at 3x. You genuinely don’t know until you test.

What load testing gives you that nothing else can:

A real number for capacity. Not a guess. Not a “probably fine.” An actual number of concurrent users your setup can handle before performance degrades past an acceptable threshold.
The location of your bottleneck. Is it the database? The application code? The web server config? The network? A load test with proper instrumentation tells you where things back up.
A baseline before you change anything. If you optimize your database queries and then run a load test, you have before-and-after data.
Confidence to scale. When you know your current ceiling, you know exactly when to provision more resources, and you can do it before an incident, not during one.

Setting Your Performance Targets: The Three Numbers That Matter

Before you run any test, you need to define what “passing” looks like. This is where a lot of teams get stuck, they run a load test and get a wall of graphs and don’t know what any of it means.

Here’s what you’re actually looking for:

1. Your concurrent user target

This is the number of simultaneous active users your site needs to handle at peak. Not total daily visitors, active users. Someone who has the page open and is interacting with it.

A practical way to estimate this: take your peak hour’s pageviews, divide by 60 to get per-minute, then multiply by your average session duration in minutes. If you get 6,000 pageviews in your busiest hour and sessions average 3 minutes, that’s roughly 300 concurrent users at peak.

If you don’t have analytics that can give you this, err on the side of 2x what you’ve seen. You can always calibrate after your first real test.

2. Your response time threshold

What response time is acceptable for your application? Define it in milliseconds and be specific.

For a static blog, 3 seconds might be perfectly fine. For a SaaS dashboard where users are actively working, anything over 1 second feels sluggish. For an e-commerce checkout flow, 2 seconds is a reasonable ceiling. For an API, you might need sub-200ms.

Write this number down before you test. It becomes your pass/fail criterion. Without it, any result can be interpreted as either a pass or a failure depending on your mood that day.

3. Your peak traffic windows

Map when your traffic actually spikes. Email campaigns, social posts, scheduled jobs, and API batch processes create load patterns. A test that runs at 3 AM when traffic is low tells you nothing about your morning peak.

Once you know these three things, your concurrent user target, your response time threshold, and your peak windows, you have a test brief. Everything else is execution.

Why loader.io Is the Best Starting Point

There are a dozen load testing tools. k6, Apache Benchmark, Locust, JMeter, Gatling, Blitz, each has strengths. For teams getting started, loader.io is the right choice for one reason: friction.

It runs in a browser. There’s nothing to install. You don’t need a separate machine, a command-line interface, or a paid subscription to get meaningful results.

That’s the free tier has limits: enough to establish your baseline, not enough for daily regression testing in production. For that, you would eventually have to move to another tool or paid plan. But as a starting point, loader.io removes every excuse to not test.

Now that we understand what load testing is and why it matters, let’s put it into practice. In the following steps, we’ll use loader.io to create a test, configure realistic traffic, run the test, and analyze the results to understand how your website performs under load.

Read Full Article: https://serveravatar.com/website-load-testing

How to Create Website Backups with ServerAvatar for Disaster Recovery

Meghna Meghwani — Thu, 13 Aug 2026 06:00:00 +0000

You have heard that Website Backup is important multiple times. And yet, talking to developers and sysadmins even years into their careers, the story is almost always the same: backups were set up once, never tested, and when something broke, the restore either didn’t work or nobody knew how to trigger it in the first place.

A server update goes wrong. A misconfigured cron job overwrites a database. A client accidentally deletes their WordPress plugin folder. In every one of these cases, the difference between a five-minute restore and a full-day rebuild is whether you actually have a working backup strategy in place.

This guide is about ServerAvatar's backup system, but more importantly, it’s about thinking through your disaster recovery approach before you are staring at a broken site at two in the morning.

We will cover the three backup types ServerAvatar offers, how to actually use them in practice, what restore looks like, and the operational habits that make backups reliable rather than just theoretically existent. If you’re running applications on ServerAvatar and haven’t touched the backup system yet, this is the guide that will get you set up properly.

TL;DR

ServerAvatar offers three distinct backup types: File System, Application, and Database
Instant Backups are for right-now; Scheduled Backups handle recurring protection automatically
Archive Backups let you recover backups from applications you have deleted
Cross-server restore is available, you can pull a backup from one server and spin it up on another
Cloud storage integration (Google Drive, Amazon S3, S3 Compatible Storage, Wasabi) keeps your backups off-server
Retention policies determine how long backups live, set these consciously, not at the default
Test your restores. A backup you haven’t verified is a liability, not an asset

Why Website Backups Should Be Part of Your Disaster Recovery Plan

A backup is simply a copy of your data. Disaster recovery is the larger process of using that copy to recover your website after an incident. That distinction matters.

Imagine a WordPress application loses its database after an unexpected server problem. Having a backup from three months ago technically means the site has a backup, but it may not be sufficient to recover recent orders and customer information.

Similarly, having hundreds of backup files doesn’t help much if:

The newest backup is incomplete.
The database wasn’t included.
Backup copies stored on the same server hosting the website.
Nobody knows which backup should be restored.
The restoration process has never been tested.
Backup retention is too short.
The backup exists but cannot be accessed during an outage.

A useful disaster recovery strategy therefore needs to answer three questions:

What needs to be backed up?
How often should it be backed up?
How quickly can the website be restored?

These questions form the foundation of a reliable backup plan.

Understanding Backup Types in ServerAvatar

Before you create your first backup, it helps to understand what you’re actually backing up. ServerAvatar separates backups into three types, and choosing the right one depends on your recovery goal.

File System Backup

This captures only the files belonging to your application, your code, uploads, configuration files, everything sitting in the application directory. No database is included.

You’d reach for this when you know your application database is safe but something happened to the files themselves, maybe a deployment went sideways and overwrote the wrong directory, or a malicious script got dropped into your uploads folder.

Application Backup

This is the comprehensive option. It backs up your application files and the associated database together as a unit. If you want one backup that represents the complete state of your site at a given moment, this is the choice.

For most WordPress, Laravel, or Node.js sites in production, Application backup is what you default to.

Database Backup

Some workloads change files frequently but keep databases relatively stable. Others modify the database constantly but rarely touch files. Database-only backup lets you capture just the database on its own schedule, separate from how often you snapshot the file system.

You might run database backups hourly while file system backups run daily. That’s a valid and sensible approach.

Choosing the Right Backup Type

The best backup type depends on what you need to recover:

Need to restore application files? Use a File System Backup.
Need files and database together? Use an Application Backup.
Need to protect frequently changing database data? Use a Database Backup.
Need different backup schedules for files and databases? Use separate File System and Database Backups.

Understanding Backup File Formats

Server backups can contain different types of data, so the format used for the backup also matters. Common formats include:

.tar – Creates an archive containing multiple files without compression.
.tar.gz – Creates a compressed archive, reducing the amount of storage required for application files.
.sql – Stores a database dump as plain SQL statements.
.sql.gz – Stores a compressed SQL database dump, making it smaller and easier to transfer.

For most website backup scenarios:

Use .tar.gz for application or file backups.
Use .sql.gz for database backups.

Why Compression Matters

Compression can make a noticeable difference when you are storing or transferring backups. Compressed backups can:

Require less disk space
Reduce storage costs
Take less time to transfer
Make remote backup storage more efficient
Reduce the amount of data that needs to move between your server and backup destination

Combining the right backup type, schedule, and file format helps create a reliable disaster recovery plan, rather than simply storing backups without a clear recovery strategy.

Read Full Article: https://serveravatar.com/website-backup