Skip to main content

301 Redirect: a simple guide to setting it up with .htaccess or Nginx

· 2 min read
Customer Care Engineer

how-to-set-up-301-redirect-nginx-and-htaccess

Want to redirect users and search engines to a new website address? 301 redirect is your best friend! It helps you maintain SEO rankings and avoid 404 errors. In this article, we will show you how to set up 301 redirect in .htaccess and Nginx quickly and easily.


What is a 301 redirect and why do you need it?

A 301 redirect is a permanent redirect from one URL to another. It is used to:

  • Preserve a site’s search engine rankings after changing its address.
  • Combine multiple URLs into one.
  • Avoid traffic loss and 404 errors.

How to Set Up a 301 Redirect in .htaccess (Apache)

  1. Find or сreate the .htaccess

The .htaccess file is located in the root (primary working) directory of your site. If it doesn’t exist, create a new one.

  1. Add the following code for redirection
  • For a single URL:
Redirect 301 /old-page https://yoursite.com/new-page
  • To redirect an entire website:
RewriteEngine On

RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]

RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301]

Replace oldsite.com and newsite.com with your site’s old and new domains respectively. 

  1. Save the file

The changes will take effect immediately.


How to set up a 301 redirect in Nginx

  1. Open the nginx configuration file for your site

Connect to your server via SSH and open the necessary file in the nano text editor:

sudo nano /etc/nginx/sites-available/your-site.com.conf

Replace yoursite.com with your site’s domain. 

If you can’t find such a file, you can locate the configuration file with the following command:

sudo grep -irl name /etc/nginx
  1. Add redirect rules to the server block
  • For a single URL:
server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com/new-page;

}
  • To redirect an entire site:
server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com$request_uri;

}
  1. Save and apply the changes

Save the file using the shortcut "Ctrl + O" and exit nano with "Ctrl + X". Then apply the changes with:

sudo systemctl reload nginx

How to check if the redirect is working

After configuring, make sure your 301 redirect is active:

  • Open the old url in a browser.

Go to the old URL in your browser and make sure you are redirected to the new address.

info

It is best to perform this check in a private browser window (incognito) to avoid caching the results.

HTTP/2 and HTTP/3: Faster, but Is It worth enabling them? Pros, cons, and configuration

· 3 min read
Customer Care Engineer

http2-vs-http3-speed-pros-cons-configuration

Modern HTTP/2 and HTTP/3 protocols can significantly speed up site loading, improve user experience and increase search engine rankings. But not everything is so simple: they have both advantages and disadvantages. Let's understand what these protocols are, their pros and cons, and how to enable them on your server.


What are HTTP/2 and HTTP/3?

HTTP/2 is an updated version of the HTTP/1.1 protocol that allows multiple website resources to be loaded in parallel rather than one by one. This speeds up response times and reduces server load.

HTTP/3 is an even more advanced version that uses the QUIC protocol on top of UDP. It creates more stable connections, especially in poor network conditions.


Advantages

  1. HTTP/2
  • Parallel (multiplexed) loading of site resources.
  • Reduced latency through header compression.
  • Traffic savings.
  1. HTTP/3
  • Quick connection establishment with minimal delay.
  • Resilience to packet loss (especially important for mobile internet).
  • Excellent performance on unstable networks.

By enabling these protocols, you will speed up your site, make it more user-friendly, and gain an SEO advantage.


Disadvantages

  1. Compatibility
  • HTTP/2 and HTTP/3 are not supported by older browsers and devices. For example, certain Internet Explorer versions and older Android devices cannot take advantage of these protocols.
  • HTTP/3 depends on UDP, which can be blocked by some firewalls and network filters.
  1. Configuration complexity
  • Incorrect configuration of HTTP/2 can worsen performance (for example, if stream prioritization is not used).
  • HTTP/3 requires an up-to-date version of Nginx, OpenSSL, and QUIC support, which can be challenging on older servers.
  1. Resource consumption
  • HTTP/3 is more demanding on server resources, particularly with a large number of connections.
  1. Dependence on HTTPS
  • HTTP/2 only works over HTTPS, which increases the complexity and cost of certificate setup and maintenance.

 5. HTTP/1.1 and performance with HTTP/2/3

  • HTTP/2 and HTTP/3 do not exclude support for HTTP/1.1. This may slightly reduce performance, but it does not cause critical issues, since HTTP/1.1 is used only for clients that do not support more modern protocols.

How to Enable HTTP/2 and HTTP/3 in Nginx

info

If you are using a control panel, for example FASTPANEL, you can enable HTTP/2 and HTTP/3 for your site in the site settings without manually editing its configuration file.

  1. Checking compatibility

Connect to your server via SSH.

Check the current Nginx version:

sudo nginx -v

For HTTP/3, version 1.25.0 or higher is required.

Check the current OpenSSL version:

openssl version

To work with HTTP/3, you need OpenSSL version 3.0.0 or higher, as earlier versions do not support QUIC.

Additionally, before making changes to the nginx configuration, make sure there are no errors:

nginx -t

If everything is fine (you can ignore “warn” messages), you will see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

2.  Configure HTTP/2

Open your site’s configuration file in a text editor:

sudo nano /etc/nginx/sites-available/your-site.conf

Add the directive http2 to the listen 443 ssl line and add the line http2 on inside the server block, so it looks something like this:

server {

listen 443 ssl http2;

server_name example.com;



ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;



http2 on;


rest of your config file

}
warning

Note that a valid SSL certificate is required for HTTPS and HTTP/2 to function.

Restart the web server to apply the changes:

systemctl restart nginx
  1. Configure HTTP/3

Similarly to the previous step, open your site’s configuration file and modify it to look like this:

server {

listen 443 ssl http2;

listen 443 quic reuseport;

server_name example.com;



ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;



http2 on;



ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;

add_header Alt-Svc 'h3=":443"; ma=86400';


rest of your config file

}

Here:

  • listen 443 quic reuseport; — enables HTTP/3 (QUIC) on port 443 and improves performance under high connection loads. 
  • ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; — specifies TLS versions for encryption. For better security, it’s recommended to use only TLSv1.2 and TLSv1.3.
  • add_header Alt-Svc 'h3=":443"; ma=86400'; — this header tells browsers that the server supports HTTP/3 and stores this information for 24 hours. 
warning

The parameter reuseport can only be used once in the Nginx server configuration. Attempting to specify it multiple times for different listen directives will cause conflicts and improper server operation.

Then run an additional compatibility check for your nginx version with these directives, as well as a syntax check:

nginx -t

If everything is fine (you can ignore “warn” messages), you will see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart Nginx to apply the changes:

systemctl restart nginx

Conclusion

HTTP/2 and HTTP/3 are a step into the future, speeding up site load times, improving SEO and making your resource more usable. However, it is important to consider compatibility, resource consumption and configuration complexity.

If most of your users are on modern browsers, start by enabling HTTP/2. Then move on to HTTP/3 if you’re ready to update your server software and are confident in your infrastructure’s compatibility.

HDD, SSD, or NVMe: how to choose a storage type when renting a server

· 2 min read
Customer Care Engineer

hdd-vs-ssd-vs-nvme-storage-options-for-your-server

When renting a server, the choice of storage system directly affects the performance of your projects, storage reliability, and rental cost. It is important to understand the difference between HDD, SSD and NVMe to make the best choice for your needs.

HDD: durability and stability

Hard disk drives (HDD) are traditional storage devices that have served data centers for years, storing large volumes of data. They aren’t as fast as SSDs, but they provide long service life under moderate load.

HDD typically have a lifespan of around 20,000–25,000 hours. In practice, many HDD in data centers operate for about 3–5 years, depending on usage intensity.

HDD are highly sensitive to power outages because they use moving parts (e.g., read/write heads), which can lead to data damage. In the event of an abrupt shutdown, the risk of data loss is higher compared to SSD.

Advantages of HDD:

  • Durability: They operate for a long time under moderate load.
  • Cost: Cheaper than SSDs and NVMe, especially when calculated per TB of data.
  • Large storage capacity: Ideal for storing huge volumes of data at lower access speeds.

SSD: faster, but with limited lifespan

Solid-state drives (SSD) are fast and reliable devices for servers where speed is critical. However, SSD have a more limited write cycle lifespan. For SATA SSD, the endurance is about 300–500 full write cycles, which, under moderate usage, could theoretically last up to five years. Yet, if your workloads involve a lot of write operations—common for many websites—the lifetime of SSD can be significantly reduced.

SSD are more resistant to sudden power loss because they have no moving parts. However, intensive writes can quickly consume the drive’s write endurance, particularly in cheaper models.

Advantages of SSD:

  • High speed: Excellent for servers where performance is crucial.
  • Resistance to power outages: More resilient to hardware damage during abrupt shutdowns.

NVMe: maximum speed, but shorter lifespan

NVMe (Non-Volatile Memory Express) диски drives are a modern alternative to SATA SSDs, offering even higher performance. They provide significantly faster read and write speeds, which is ideal for servers handling large amounts of data or performing computationally intensive tasks.

However, NVMe drives tend to have a shorter lifespan than SATA SSDs. Due to their high write speeds, these drives can wear out faster under constant load.

Like SSD, NVMe drives are less prone to damage during abrupt shutdowns. However, they are still not as long-lasting as HDD due to the intense operational loads.

Advantages of NVMe:

  • Maximum speed: Ideal for servers that process large data volumes. 
  • High performance: Suitable for tasks with heavy workloads.

Which storage type should you choose?

  • If durability and cost matter more to you, and you don’t plan on heavy write operations, HDD is a great choice. It’s cheaper and will provide stable operation for years.
  • If you need fast data processing under moderate load, go for an SSD. It offers good speed and wears out less quickly compared to NVMe.
  • NVMe is suitable for servers with extremely high speed requirements, but keep in mind its shorter lifespan and higher price. 

Your choice of storage depends on your specific tasks: if longevity and affordability are the priority, choose HDD. If you need high performance, SSD or NVMe will be the optimal solution.

SSL certificates: what’s the difference between paid and free, and which should you choose?

· 3 min read
Customer Care Engineer

ssl-certificates-paid-or-free

SSL certificate is a must for any modern website. It ensures secure data transfer between the server and the user. There are several variants of certificates, including free (most often Let's Encrypt and ZeroSSL) and paid ones. Let's find out how they differ and when you should choose a paid certificate.

What is a free SSL certificate from Let’s Encrypt or ZeroSSL?

Let's Encrypt is a free and automated service that provides SSL certificates for websites. It’s ideal for most simple projects, whether it’s a blog or a small online store.

ZeroSSL is a similar tool that also offers free certificates but comes with some additional features.

Advantages of Free Certificates:

  1. No cost: The main advantage. Let’s Encrypt and ZeroSSL provide SSL certificates completely free of charge, which is perfect for most users who do not require an additional level of trust.
  2. Support in modern browsers: Certificates from Let’s Encrypt and ZeroSSL are accepted by all current browsers, so users won’t see any security warnings when visiting your site.
  3. Wildcard certificates: Both Let’s Encrypt and ZeroSSL support wildcard certificates, allowing you to protect all subdomains of a given domain.

Drawbacks:

  1. Limited support: If you encounter problems with your certificate, you’ll need to resolve them yourself, as free certificates do not come with support.
  2. Short-term validity: Let’s Encrypt and ZeroSSL certificates are only valid for 90 days. Although there are ways to set up automatic renewal, in most cases this requires command-line skills and a basic understanding of how a web server works.
  3. Level of trust and reliability: Unlike paid certificates, Let’s Encrypt and ZeroSSL do not offer Extended Validation (EV), which may limit the level of trust some users and search engines have in your site. 

Differences between ZeroSSL and Let’s Encrypt:

  • ZeroSSL offers a more user-friendly interface and paid certificate options with additional features (for example, extending validity up to one year).
  • Let's Encrypt is completely free but requires configuring automated renewals.

What are paid SSL certificates?

Paid SSL certificates are offered by many providers, such as DigiCert, GlobalSign, Comodo, and others. They include additional benefits and features that may be valuable for more complex projects handling sensitive personal data.

Advantages of paid certificates:

  1. Long-term certificates: Paid certificates typically last from 1 to 3 years. This is convenient if you don’t want to renew your certificate frequently and prefer a longer-term solution.
  2. Extended Validation (EV SSL): Paid certificates often include EV, which involves a more thorough vetting of the purchasing company. This increases the level of trust users have in your site.
  3. Technical support and warranties: Paid certificates usually come with support and insurance against any issues related to the certificate’s installation and operation. In cases where it’s proven that your clients’ data was stolen due to a certificate issue, you would be compensated under the insurance policy. 
  4. Improved search indexing: Many search engines give preference to secure websites in search results. Paid certificates can help boost SEO, as they signal greater reliability for your site.

When should you choose a paid SSL certificate?

  1. If your site handles sensitive information or payments: Paid certificates with EV are especially valuable for sites that process personal data or handle financial transactions. They help increase user trust.
  2. For multi-site projects: Paid certificates can protect multiple sites or subdomains, making them ideal for corporate or large commercial websites.
  3. If you need additional support: With paid certificates, you can get help from support services—important for businesses that don’t want to handle technical problems on their own.
  4. For improving SEO: Paid certificates can boost your rankings in search engines.
  5. For long-term use: Paid certificates have a longer validity period and don’t require frequent renewal, which is convenient for large sites and projects.

Conclusion

Free certificates from Let’s Encrypt or ZeroSSL are an excellent solution for most small websites and blogs. They provide basic security and are suitable for sites that don’t need extended validation or extra features.

If your site requires additional features - for example, protection of multiple domains or extended support - a paid certificate would be a better choice. In this case, you can explore the available paid options (to purchase a certificate from us, follow the link).

Basic work with journald

· 2 min read
Customer Care Engineer

read-journald-logs-and-learn-how-to-clear-it

Journald is a logging system used in modern Linux-based operating systems to record system events. It collects information about the operation of various services, applications, and system processes to help administrators monitor system health and diagnose errors.

Unlike standard text logs, journald stores data in a binary format. This allows logs to be stored more compactly and managed more efficiently, but at the same time, you cannot simply open these logs in a text editor. Special tools are required to view and analyze them.

In this article, we will look at how to view the records maintained by journald and how to clear them to save disk space.


How to view journal logs

To read logs, use the journalctl command:

  • All logs:
sudo journalctl
  • Logs since the last reboot:
sudo journalctl -b
  • Logs for a specific service:
sudo journalctl -u nginx
  • Logs for a specific day:
sudo journalctl --since "2024-11-01" --until "2024-11-02"
  • View the last n entries (for example, the last 100):
sudo journalctl -n 100
  • Filter by priority level (for example, for errors):
sudo journalctl -p err
  • View journal entries in reverse order, starting from the newest (useful when you need to see the latest log entries quickly):
sudo journalctl -r
  • View journal entries in real time (similar to tail -f):
sudo journalctl -f

You can combine these options. For example, to display all errors from the nginx service on November 10, 2024, showing only the last 10 entries:

sudo journalctl -u nginx --since "2024-11-10" --until "2024-11-10 23:59:59" -n 10

How to clear the Journal

If logs occupy too much space, you can use the following commands to clear them:

  • Clear old logs (e.g., older than 7 days):
sudo journalctl --vacuum-time=7d
  • Clear logs exceeding a specified size (e.g., 1 GB):
sudo journalctl --vacuum-size=1G
  • Completely clear all logs:
sudo journalctl --vacuum-files=0

How to reduce the Journal size

By default, journald can occupy a lot of disk space if logs are not limited. To set a maximum size for logs, open the journald.conf configuration file:

sudo nano /etc/systemd/journald.conf

In this file, you can configure the following parameters:

  • SystemMaxUse — the maximum size for all journals:
SystemMaxUse=1G
  • RuntimeMaxUse — the maximum size for temporary journals:
RuntimeMaxUse=500M
  • MaxRetentionSec — the maximum time to retain logs:
MaxRetentionSec=1month

Set values suitable for your system and needs, then save the file using Ctrl + O, and exit the editor using Ctrl + X. 

To apply the changes, restart the journald service:

sudo systemctl restart systemd-journald

You can also enable logging to RAM or even disable it entirely. Neither option is recommended in a production environment, as the journal contains important diagnostic information. Its accuracy and relevance are crucial for proper diagnostics of processes on your server.

If you still want to activate storing the journal in RAM, set the following value in /etc/systemd/journald.conf:

Storage=volatile

To completely disable logging, specify:

Storage=none

Don’t waste your server resources: block unwanted bots using Nginx

· 4 min read
Customer Care Engineer

block-unwanted-bots-using-nginx

Search engine bots (crawlers) are special programs that scan websites on the Internet. Search engines need them to find, index and display pages in search results. But not all bots are useful!

Sometimes your site may be visited by unwanted bots that:

  • Collect data without your permission.
  • Consume server resources, slowing it down.
  • Are used to look for vulnerabilities.

If you want to protect your site from such bots, it’s time to configure Nginx! In this article, we’ll show you how to easily and quickly block them using a special configuration file.


Why Nginx configuration instead of robots.txt?

The robots.txt file is a tool for managing search bots’ behavior. It tells them which parts of the site should not be crawled. It’s very easy to use this file: simply create one in the site’s root directory, for example:

User-agent: BadBot  

Disallow: /  

However, there is a problem: instructions in robots.txt are a recommendation rather than an enforced rule. Conscientious bots do follow this file’s instructions, but most bots simply ignore it.

By contrast, configuring Nginx allows you to physically block access for unwanted bots, guaranteeing a 100% effective result.


How Nginx blocks unwanted bots: using response 444

Unlike robots.txt, which only provides recommendations to bots, Nginx physically blocks their access. One way to achieve this is by using a special server response with the code 444. 

In Nginx, the response code 444 is an internal method of terminating the connection with the client without sending any response. This is an efficient approach to ignore unwanted requests and minimize server load.


Setting up the blocking

Step 1: How to identify unwanted bots?

Unwanted bots can be identified by their User-Agent, which is a parameter sent by all clients when visiting your site. For example, some User-Agents might look like this:

    AhrefsBot     SemrushBot     MJ12bot

You can find suspicious User-Agent values in the Nginx access log (if your site uses PHP-FPM):

sudo grep -i bot /var/log/nginx/access.log

Or in the Apache access log (if your site uses the Apache module or FastCGI as a PHP handler):

  • For Ubuntu/Debian:
sudo grep -i bot /var/log/apache2/access.log
  • For CentOS/AlmaLinux/RockyLinux:
sudo grep -i bot /var/log/httpd/access.log

If you’re using a control panel such as FASTPANEL, each site will have its own separate log file. You can analyze them individually or all at once using a command like:

  • If your site uses the Apache module or FastCGI as the PHP handler:
sudo cat /var/www/*/data/logs/*-backend.access.log |  grep -i bot | tail -500
  • If your site uses PHP-FPM:
sudo cat /var/www/*/data/logs/*-frontend.access.log |  grep -i bot | tail -500

This command will display the last 500 requests made to all your sites where the User-Agent parameter contains the word “bot.” An example of one line (one request to your site) might look like this:

IP - [03/Nov/2022:10:25:52 +0300] "GET link HTTP/1.0" 301 811 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; [email protected])"

or

IP - [24/Oct/2022:17:32:37 +0300] "GET link HTTP/1.0" 404 469 "-" "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)"

The bot’s User-Agent is located between the segments “compatible;” and “/version.number“ at the end of the request line in parentheses. So in the above examples, User-agents are: BLEXBot and DotBot.

Analyze the information you gather and note the User-Agent strings of the most active bots for the next step of configuring the block. 

Step 2: Create a File to Block Bots

  1. Connect to your server via SSH.
  2. Before making changes, ensure that your current Nginx configuration has no errors:
nginx -t

If everything is fine, you’ll see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

If there are any errors, review them and fix them in the file indicated by the error messages.

  1. Create a separate file listing the bots to block:
sudo nano /etc/nginx/conf.d/block_bots.conf

Add the following code to the file:

    map $http_user_agent $block_bot {

        default 0;

        ~*AhrefsBot 1;

        ~*SemrushBot 1;

        ~*MJ12bot 1;

    }



    server {

        if ($block_bot) {

            return 444;

        }
    }

Here we create a map that determines which bots should be blocked.

Following this pattern, list the User-Agent strings of the bots you want to block. You must list each bot on a new line and place a semicolon ; at the end of each line as a delimiter.

After you finish building your list, press "Ctrl + O" on your keyboard to save the file, then "Ctrl + X" to exit the nano editor.

Step 3: Apply the Changes

After making your changes, always test the Nginx configuration for correctness to ensure there are no syntax errors:

sudo nginx -t

If everything is fine, you’ll see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

If there are errors, review the output to identify and correct them in the file specified.

Then reload the Nginx configuration to apply the changes:

sudo systemctl reload nginx

In the future, if you need to add more bots to the block_bots.conf file, you should repeat this step each time. 


Conclusion

Now you know how to easily block unwanted search bots on your server using Nginx! Keep an eye on your logs and add new lines to the block_bots.conf configuration file as needed.

Make sure you only block malicious bots so that you don't prevent useful search engines like Google or Bing from indexing your site.

How to set up logrotate for automatic log archiving and saving server space

· 2 min read
Customer Care Engineer

Log management is a crucial part of any server administrator's job. Logs that are not rotated can quickly occupy all available disk space, slow down the server, and cause unpredictable errors. In this article, we’ll explain how to configure and use logrotate for automatic log cleanup and rotation on a server. 


What is logrotate and why is it important to use?

Logrotate is a tool designed for automatic log management. It helps to:

  • Clear old logs — automatically deletes or archives old log files.
  • Save disk space — compresses and removes unnecessary logs.

Log rotation prevents logs from accumulating and causing disk overflow, which could result in crashes and data loss. Logrotate automatically archives old logs and makes room for new data.


How does logrotate work?

When logrotate is active, it automatically performs the following steps:

  1. Log rotation — old logs are renamed and stored, while new files are created in their place.
  2. Compression — old logs can be compressed into .gz format to save space.
  3. Deletion — outdated logs can be deleted if they are no longer needed.

Example: A log file named access.log can be transformed into access.log.1, then compressed into access.log.1.gz, and eventually deleted after a specified retention period.


How to configure logrotate

1. Installing logrotate

On most Linux systems, logrotate is pre-installed. To check if logrotate is installed, run the command:

sudo logrotate --version

 If logrotate is not installed, it can be installed via a package manager. 

  • For Debian/Ubuntu:
sudo apt update && sudo apt install logrotate
  • For CentOS/RockyLinux/AlmaLinux:
sudo yum install logrotate

2. Configuring logrotate

Logrotate configuration is usually stored in /etc/logrotate.conf. This file contains general parameters for all logs on the server. To configure the rotation of individual logs, you can create separate configuration files for different services in the /etc/logrotate.d/ directory.

Example of a standard Nginx configuration:

/var/log/nginx/*.log {
daily          # Logs are rotated daily
missingok      # Do not display an error if the log is missing
rotate 7       # Keep 7 archived files
compress       # Compress old logs
delaycompress  # Delay compression until the next rotation
notifempty     # Do not rotate empty files
create 0640 www-data adm  # Create new logs with specific permissions
}

3. Key configuration parameters

  • daily/weekly/monthly — defines how often the log file will be rotated (daily, weekly, or monthly).
  • rotate [N] — specifies the number of archived logs to retain.
  • compress — enables log file compression (typically into .gz).
  • missingok — prevents errors if a log file is missing.
  • notifempty — skips rotation for empty files.
  • create — creates new logs with specified permissions.

4. Running logrotate

Logrotate usually runs automatically via cron. However, you can run it manually if you need to check the configuration or perform a rotation immediately:

sudo logrotate -f /etc/logrotate.conf

5. Verifying logrotate's operation

To ensure that logrotate is working correctly, you can check the latest entries in its service log:

sudo journalctl -u logrotate -n 10

Logs are taking up too much space on your server. How to fix it?

· 2 min read
Customer Care Engineer
info

Most log files are stored in the /var/log directory, but they are not limited to it. The principles described in this section apply to all *.log files in any directory on your server.

Logs are files that store information about server events: application and operating system activity, various errors, user requests to websites, and more. Over time, logs can take up a significant amount of disk space, especially under heavy load or if there are software errors.

One critical aspect of log files is that, in most cases, deleting them can cause issues for the program generating them — whether it’s a web server or even the operating system itself.

Additionally, logs often contain valuable diagnostic information that can help identify software issues on your server and prevent larger problems. Therefore, it’s important to handle them properly and carefully.


How to identify logs that can be cleaned

Use ncdu to locate large logs on the server. If a log file is unusually large, check its latest entries:

sudo tail /path/to/log

If there are no anomalies, check the beginning of the file to determine whether the log grew large simply due to age (pay attention to the date of the earliest entries):

sudo head /path/to/log

After this, you can proceed with cleaning the file.

info

If you’re unsure why the log file has grown so large, it’s better to save it and contact your hosting provider’s support team for clarification.


How to safely clean logs

The truncate command clears the contents of a file without deleting it:

sudo truncate -s 0 /var/log/nginx/error.log

Separately note the files that are logs, despite the lack of *.log extension:

  • /var/log/btmp
  • /var/log/syslog
  • /var/log/messeges
  • /var/log/secure
  • /var/log/maillog

These files can also be safely cleaned using the truncate command.

A special case is the log located in the /var/log/journal directory. You can find more details about working with it in separate article.   


How to prevent logs from growing too large

While analyzing logs, you may notice some of them have names like:

  • syslog.1
  • yoursite.access.log.1

These appear when log rotation is applied, for example, using the logrotate program. Old files can be deleted or compressed during rotation, saving disk space.

You can read more about configuring this mechanism in a separate article.

How to find and delete files that are "eating up" space on the server

· 2 min read
Customer Care Engineer

Running out of space on your server? This may cause the site and database to malfunction. To free up space, you need to identify the files taking up the most room and delete them. In this article, we’ll explain how to easily accomplish this using the ncdu utility and how to safely clean up logs.


Step 1: Installing and running ncdu

ncdu  is a handy tool for disk space analysis. It displays all folders and files sorted by size in an easy-to-use text interface.

To use this program, you’ll need to connect to your server via SSH.  

Installation

  • Debian/Ubuntu:
sudo apt update && sudo apt install ncdu
  • CentOS/AlmaLinux/Rocky Linux:
sudo yum install ncdu

Running disk analysis

  • To scan the root directory /, execute:
sudo ncdu -x /

The -x option in ncdu restricts the scan to a single file system, excluding mounted virtual directories (e.g., /proc, /dev, /sys) and any other volumes mounted via separate mount points (e.g., network or external drives).

  • To analyze a specific directory:
sudo ncdu /path/to/directory

For example, to scan only the logs directory, run:

sudo ncdu /var/log

Step 2: Analyzing and deleting unnecessary files

After running ncdu, you will see a list of files and folders sorted by size. Navigation is simple:

  • Up/Down arrow keys — move through the list.
  • Enter — navigate into a directory.
  • D — delete the selected file or folder.

ncdu-how-to-find-large-files

danger

Be careful when deleting system files. Delete only those files that you are sure of.

When files are deleted in Linux, they are permanently removed! Recovery is only possible through backups, and only if available.

It is safer to create a list of files and directories taking up significant space (highlight rows in ncdu and copy them to a notepad on your local PC), then review each individually and delete them using the command line.

To delete a file, run:

sudo rm -f /path/to/file

To delete a directory:

sudo rm -rf /path/to/directory

  Here's a list of the major directories that tend to take up a lot of space:

  1. /var/www/ - directory with your sites

Often, the largest directories are upload and cache in the root directory of the website, containing user-uploaded files and the site cache, respectively. For example:

/var/www/user/data/www/yoursite.com/upload/

Files in these directories are relatively safe to delete. However, only you, as the administrator of your website, know which files in the upload directory are important and which are no longer needed. It is recommended to leave the directory itself intact to avoid errors. 

  1. /var/lib/mysql/

This is the directory containing your website databases. 

danger

Please do not delete anything from this directory!

If it is taking up an unusually large amount of space, contact your hosting provider for a deeper analysis of the issue. 

  1. /var/log/

This directory stores logs generated by software running on your server. Logs have specific characteristics, and their cleanup is covered in a separate article.


Step 3: Finalizing and verifying

After deleting unnecessary files, check how much space has been freed using the command:

df -h

How to change the MariaDB password for root and regular users

· 3 min read
Customer Care Engineer

Forgot your MariaDB root password? Without it, you won’t be able to manage users, databases, or perform critical configurations. In this article, you’ll learn not only how to quickly reset the MariaDB root password but also how to reset the password for regular users. 

info

The root user is the main administrator of the database. They have full access to all data and settings. If you lose this password, you will not be able to change some settings or execute commands.

All operations will be performed via the command line over SSH. You can find detailed instructions on how to connect to your server using SSH in this article

Before proceeding, check the contents of the /root/.my.cnf file. Often, it contains the current root password for accessing MariaDB

To test the connection, use the command:

mysql -u root -p 

Then, enter the password from the .my.cnf file. 

If the password doesn’t work, follow the instructions below. 


Resetting the password

info

In most commands below, the mysql command will be used instead of mariadb to interact with the MariaDB server. This is because, on some operating systems, such as RHEL-based distributions (RockyLinux, AlmaLinux, etc.), the mariadb command is unavailable. Instead, the mysql command is used for compatibility with MySQL.

Using the mysql command provides universal compatibility regardless of the distribution or implementation of the server.

Step 1: Stop MariaDB

To reset the password, first stop the MariaDB server. Enter the following command:

systemctl stop mariadb

 Step 2: Restart the server in safe mode

  • For Debian and Ubuntu:

Make sure the directory MariaDB will run from exists and has the correct owner:

mkdir -p /var/run/mysqld/ && chown -R mysql: /var/run/mysqld/

 Start the MariaDB server without access control:

mysqld_safe --skip-grant-tables --socket=/var/run/mysqld/mysqld.sock &

If the MariaDB server starts successfully, you will see a message similar to:

2024-11-28T23:50:19.298141Z mysqld_safe Starting mariadb daemon with databases from /var/lib/mysql

To continue working in the command line, press “Ctrl + C”. 

  • For CentOS/RockyLinux/AlmaLinux:

Start the MariaDB server without access control:

mysqld_safe --skip-grant-tables --socket=/var/lib/mysql/mysql.sock &

To continue working in the command line, press “Ctrl + C”.

Step 3: Connect to MariaDB

  • For Debian and Ubuntu:
mysql --socket=/var/run/mysqld/mysqld.sock
  • For CentOS/RockyLinux/AlmaLinux:
mysql --socket=/var/lib/mysql/mysql.sock

 Step 4: Reset the password

Execute the following commands sequentially:

FLUSH PRIVILEGES;

 For a local user:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword';

For a network user (if it exists):

ALTER USER 'root'@'%' IDENTIFIED BY 'NewPassword';

Then:

FLUSH PRIVILEGES;

Replace NewPassword with your desired new password.

info

'user'@'localhost' — refers to a local user connecting via socket or localhost. 'user'@'%' refers to a network user with access from any IP address.

You can set the same or different passwords for these users. If the network user doesn’t exist, the @'%' command will result in an error.

Exit MariaDB using the exit command or by pressing “Ctrl + D”. 

Step 5: Restart MariaDB

Stop the MariaDB server:

  • For Debian and Ubuntu:
mysqladmin shutdown --socket=/var/run/mysqld/mysqld.sock -p

Then, enter the previously set root password.

  • For CentOS/RockyLinux/AlmaLinux:
mysqladmin shutdown --socket=/var/lib/mysql/mysql.sock -p

Then, enter the previously set root password.

Start MariaDB in normal mode:

systemctl start mariadb

 How to reset the password for regular users

If you forget the password for a user other than root, the approach is similar:

  1. Connect to the MariaDB server as root:
mysql -u root -p

 Enter your MariaDB root password.

  1. Execute the command to change the password:

For a local user:

ALTER USER 'username'@'localhost' IDENTIFIED BY 'NewUserPassword';

For a network user (if it exists):

ALTER USER 'username'@'%' IDENTIFIED BY 'NewUserPassword';

Then:

FLUSH PRIVILEGES;

Replace username with the actual username and NewUserPassword with your desired new password.

Exit MariaDB using the exit command or by pressing “Ctrl + D”.

If necessary, you can list all users with the following query:

SELECT User, Host FROM mysql.user;

How to connect to MariaDB locally without entering a password

To avoid entering the password manually each time you connect to MariaDB from the command line on your server, you can save it in the /root/.my.cnf file. Open the file in a text editor:

nano /root/.my.cnf

Add the following lines:

[client]

user = root
password = YourRootPassword

Replace YourRootPassword with your actual root password.

Save the file by pressing Ctrl + O, then exit the text editor with Ctrl + X. 

For security purposes, set stricter permissions on the .my.cnf file:

chmod 600 /root/.my.cnf

After this, you can connect by simply running the command:

mysql -u root