{"id":4731,"date":"2026-02-07T20:46:03","date_gmt":"2026-02-07T17:46:03","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/log-archiving-strategy-on-cpanel-and-vps-gzip-s3-object-storage-and-retention\/"},"modified":"2026-02-07T20:46:03","modified_gmt":"2026-02-07T17:46:03","slug":"log-archiving-strategy-on-cpanel-and-vps-gzip-s3-object-storage-and-retention","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/log-archiving-strategy-on-cpanel-and-vps-gzip-s3-object-storage-and-retention\/","title":{"rendered":"Log Archiving Strategy on cPanel and VPS: gzip, S3\/Object Storage and Retention"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Disk usage graphs on hosting servers rarely grow in a straight line. Traffic increases, marketing launches, more WordPress or Laravel sites get added, and in the background one thing grows steadily every single day: logs. On both cPanel hosting environments and unmanaged <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> servers, web, email, database and system logs can quietly consume gigabytes of space, slow down backups and even trigger \u201cno space left on device\u201d errors if you do not keep them under control. A clear log archiving strategy \u2013 built around gzip compression, S3\u2011compatible object storage offload and realistic retention policies \u2013 turns that risk into an asset. You keep the logs you actually need for debugging, security and compliance, while freeing your primary disks for what really matters: serving your applications. In this article we will walk through how we at dchost.com think about log archiving on cPanel and VPS, which tools we rely on in real projects, and how you can implement a strategy that is cheap, predictable and compliant.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Log_Archiving_Matters_on_cPanel_and_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Log Archiving Matters on cPanel and VPS<\/a><ul><li><a href=\"#Key_reasons_to_archive_logs_properly\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Key reasons to archive logs properly<\/a><\/li><\/ul><\/li><li><a href=\"#Understanding_Log_Types_and_Where_They_Live\"><span class=\"toc_number toc_depth_1\">2<\/span> Understanding Log Types and Where They Live<\/a><ul><li><a href=\"#Common_log_types_on_cPanel_servers\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Common log types on cPanel servers<\/a><\/li><li><a href=\"#Common_log_types_on_plain_VPS_servers\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Common log types on plain VPS servers<\/a><\/li><\/ul><\/li><li><a href=\"#gzip_Compression_and_logrotate_The_Foundation_of_Log_Archiving\"><span class=\"toc_number toc_depth_1\">3<\/span> gzip Compression and logrotate: The Foundation of Log Archiving<\/a><ul><li><a href=\"#How_log_rotation_works\"><span class=\"toc_number toc_depth_2\">3.1<\/span> How log rotation works<\/a><\/li><li><a href=\"#Configuring_gzip_and_rotation_on_cPanel_servers\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Configuring gzip and rotation on cPanel servers<\/a><\/li><li><a href=\"#Configuring_gzip_and_rotation_on_unmanaged_VPS_servers\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Configuring gzip and rotation on unmanaged VPS servers<\/a><\/li><\/ul><\/li><li><a href=\"#Offloading_Logs_to_S3Compatible_Object_Storage\"><span class=\"toc_number toc_depth_1\">4<\/span> Offloading Logs to S3\u2011Compatible Object Storage<\/a><ul><li><a href=\"#Designing_your_bucket_structure\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Designing your bucket structure<\/a><\/li><li><a href=\"#Tools_to_sync_logs_to_object_storage\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Tools to sync logs to object storage<\/a><\/li><li><a href=\"#Example_rclonebased_log_archive_sync\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Example: rclone\u2011based log archive sync<\/a><\/li><li><a href=\"#Security_considerations_for_log_archives\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Security considerations for log archives<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Realistic_Log_Retention_Policies\"><span class=\"toc_number toc_depth_1\">5<\/span> Designing Realistic Log Retention Policies<\/a><ul><li><a href=\"#Step_1_Classify_your_logs\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Step 1: Classify your logs<\/a><\/li><li><a href=\"#Step_2_Map_categories_to_retention_periods\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Step 2: Map categories to retention periods<\/a><\/li><li><a href=\"#Step_3_Reflect_policies_in_logrotate_and_object_storage\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Step 3: Reflect policies in logrotate and object storage<\/a><\/li><li><a href=\"#Step_4_Think_about_privacy_and_minimisation\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Step 4: Think about privacy and minimisation<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_All_Together_Reference_Architectures_for_cPanel_and_VPS\"><span class=\"toc_number toc_depth_1\">6<\/span> Putting It All Together: Reference Architectures for cPanel and VPS<\/a><ul><li><a href=\"#Scenario_1_WHMcPanel_server_hosting_many_sites\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Scenario 1: WHM\/cPanel server hosting many sites<\/a><\/li><li><a href=\"#Scenario_2_Custom_VPS_with_NginxApache_databases_and_apps\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Scenario 2: Custom VPS with Nginx\/Apache, databases and apps<\/a><\/li><\/ul><\/li><li><a href=\"#A_Maintainable_Log_Archiving_Strategy_for_the_Long_Term\"><span class=\"toc_number toc_depth_1\">7<\/span> A Maintainable Log Archiving Strategy for the Long Term<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Log_Archiving_Matters_on_cPanel_and_VPS\">Why Log Archiving Matters on cPanel and VPS<\/span><\/h2>\n<p>Server logs are not just noise; they are a detailed history of how your sites, APIs and email infrastructure behave. The problem is that this history grows forever unless you make intentional decisions.<\/p>\n<h3><span id=\"Key_reasons_to_archive_logs_properly\">Key reasons to archive logs properly<\/span><\/h3>\n<ul>\n<li><strong>Disk capacity and stability:<\/strong> Uncontrolled logs fill disks, cause failed backups and can even crash services when they cannot write temporary files. On a VPS with limited NVMe or SSD space, this can happen faster than you think.<\/li>\n<li><strong>Performance of tools and backups:<\/strong> Backup jobs, malware scanners and search tools slow down when they must process months of uncompressed logs sitting in <code>\/home<\/code> or <code>\/var\/log<\/code>.<\/li>\n<li><strong>Security and incident response:<\/strong> When something goes wrong, you want to be sure that the right logs still exist \u2013 not just yesterday\u2019s, but maybe 30, 90 or 365 days back, depending on your risk profile.<\/li>\n<li><strong>Legal and regulatory requirements:<\/strong> Regulations like KVKK and GDPR often require that you keep certain logs for a minimum period and delete or anonymize them after a maximum period. We covered this perspective in detail in <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-ve-e-posta-altyapisinda-log-saklama-sureleri\/\">our guide on log retention on hosting and email infrastructure<\/a>.<\/li>\n<li><strong>Cost optimisation:<\/strong> Fast NVMe disks are excellent for active databases and applications, but expensive as an archive. Compressing and offloading logs to object storage gives you the same data at a fraction of the cost.<\/li>\n<\/ul>\n<p>For customers using cPanel on shared or reseller hosting, some rotation exists out of the box, but it is rarely aligned with your specific needs. On VPS and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, you are fully responsible for log rotation and archiving. In both cases, a bit of planning around gzip, object storage and retention will save you many headaches later.<\/p>\n<h2><span id=\"Understanding_Log_Types_and_Where_They_Live\">Understanding Log Types and Where They Live<\/span><\/h2>\n<p>Before designing an archiving strategy, you need to know <strong>what<\/strong> you are archiving and <strong>where<\/strong> it is written.<\/p>\n<h3><span id=\"Common_log_types_on_cPanel_servers\">Common log types on cPanel servers<\/span><\/h3>\n<p>On a typical cPanel\/WHM server managed by dchost.com or by your own team, you will encounter:<\/p>\n<ul>\n<li><strong>Web server logs (Apache \/ LiteSpeed):<\/strong>\n<ul>\n<li>Global logs such as <code>\/usr\/local\/apache\/logs\/access_log<\/code> and <code>error_log<\/code><\/li>\n<li>Per\u2011domain logs under <code>\/usr\/local\/apache\/domlogs\/<\/code><\/li>\n<\/ul>\n<\/li>\n<li><strong>cPanel and WHM logs:<\/strong>\n<ul>\n<li><code>\/usr\/local\/cpanel\/logs\/access_log<\/code> (panel access)<\/li>\n<li><code>\/usr\/local\/cpanel\/logs\/error_log<\/code><\/li>\n<li><code>\/usr\/local\/cpanel\/logs\/login_log<\/code> (authentication)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Mail server logs (Exim, Dovecot):<\/strong>\n<ul>\n<li><code>\/var\/log\/exim_mainlog<\/code>, <code>\/var\/log\/exim_rejectlog<\/code>, <code>\/var\/log\/exim_paniclog<\/code><\/li>\n<li><code>\/var\/log\/maillog<\/code> for POP\/IMAP connections<\/li>\n<\/ul>\n<\/li>\n<li><strong>FTP, SSH and system logs:<\/strong>\n<ul>\n<li><code>\/var\/log\/messages<\/code>, <code>\/var\/log\/secure<\/code> (or <code>\/var\/log\/auth.log<\/code> on some distros)<\/li>\n<li><code>\/var\/log\/pureftpd.log<\/code> or similar, depending on the FTP daemon<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Many of these logs are already rotated by cPanel\u2019s built\u2011in mechanisms and by <code>logrotate<\/code>, but default periods may not match your security or compliance needs. We will come back to that.<\/p>\n<h3><span id=\"Common_log_types_on_plain_VPS_servers\">Common log types on plain VPS servers<\/span><\/h3>\n<p>On a custom VPS without a control panel, you typically manage services yourself:<\/p>\n<ul>\n<li><strong>Web server logs:<\/strong> <code>\/var\/log\/nginx\/access.log<\/code>, <code>\/var\/log\/nginx\/error.log<\/code>, or <code>\/var\/log\/httpd\/<\/code> \/ <code>\/var\/log\/apache2\/<\/code>.<\/li>\n<li><strong>Application logs:<\/strong> Laravel log files under <code>storage\/logs\/<\/code>, Node.js app logs handled by pm2 or systemd\u2019s <code>journalctl<\/code>, custom scripts writing to <code>\/var\/log\/yourapp\/<\/code> etc.<\/li>\n<li><strong>Database logs:<\/strong> MySQL\/MariaDB slow query log, error log, general log; PostgreSQL <code>postgresql.log<\/code> files.<\/li>\n<li><strong>System and authentication logs:<\/strong> <code>\/var\/log\/syslog<\/code>, <code>\/var\/log\/messages<\/code>, <code>\/var\/log\/auth.log<\/code> or <code>\/var\/log\/secure<\/code>.<\/li>\n<\/ul>\n<p>On these servers, nothing stops your logs from growing indefinitely except what <code>logrotate<\/code> (or systemd\u2011journald) is configured to do. If you have ever hit a nasty \u201cno space left on device\u201d message, you might want to review our dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-disk-kullanimi-ve-logrotate-ayarlariyla-no-space-left-on-device-hatasini-onlemek\/\">VPS disk usage and logrotate tuning<\/a>.<\/p>\n<h2><span id=\"gzip_Compression_and_logrotate_The_Foundation_of_Log_Archiving\">gzip Compression and logrotate: The Foundation of Log Archiving<\/span><\/h2>\n<p>The simplest and most effective optimisation for logs is to compress them. Plain text compresses extremely well; it is common to see <strong>70\u201390% size reduction<\/strong> using gzip. That means a 10 GB log history can shrink to 1\u20133 GB immediately.<\/p>\n<h3><span id=\"How_log_rotation_works\">How log rotation works<\/span><\/h3>\n<p>Both cPanel and most Linux distributions rely on a utility called <code>logrotate<\/code> to manage log files. The basic idea:<\/p>\n<ol>\n<li>The active log file (for example <code>access.log<\/code>) is periodically \u201crotated\u201d.<\/li>\n<li>The current file is renamed to something like <code>access.log.1<\/code>, and a new empty <code>access.log<\/code> is created for the service to keep writing into.<\/li>\n<li>Older files (<code>.2<\/code>, <code>.3<\/code> \u2026) are removed when they exceed your configured retention count or age.<\/li>\n<li>If compression is enabled, rotated files are compressed with gzip and end up as <code>access.log.1.gz<\/code>, <code>access.log.2.gz<\/code> etc.<\/li>\n<\/ol>\n<p>Rotation can be based on <strong>time<\/strong> (daily\/weekly\/monthly) or <strong>size<\/strong> (for example, when a log exceeds 100 MB). Most hosting setups use daily or weekly rotation plus gzip.<\/p>\n<h3><span id=\"Configuring_gzip_and_rotation_on_cPanel_servers\">Configuring gzip and rotation on cPanel servers<\/span><\/h3>\n<p>On a cPanel\/WHM server, many rotations are preconfigured, but you can adjust them at two levels:<\/p>\n<ul>\n<li><strong>WHM interface:<\/strong> Under <em>Service Configuration \u2192 Apache Configuration \u2192 Log Rotation<\/em> you can adjust whether to archive logs and how long to keep them for web logs specifically.<\/li>\n<li><strong>logrotate configuration files:<\/strong> Located under <code>\/etc\/logrotate.conf<\/code> and <code>\/etc\/logrotate.d\/<\/code>. These are standard Linux configuration files; cPanel also installs its own snippets there for Exim, MySQL, cPanel logs, etc.<\/li>\n<\/ul>\n<p>A typical logrotate rule for an Apache log might look like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">\/usr\/local\/apache\/logs\/access_log {\n    daily\n    rotate 14\n    compress\n    delaycompress\n    missingok\n    notifempty\n    sharedscripts\n    postrotate\n        \/usr\/local\/apache\/bin\/apachectl graceful &gt; \/dev\/null 2&gt;&amp;1 || true\n    endscript\n}\n<\/code><\/pre>\n<p>Important directives:<\/p>\n<ul>\n<li><code>daily<\/code>: Rotate the log every day.<\/li>\n<li><code>rotate 14<\/code>: Keep 14 compressed archives before deleting the oldest.<\/li>\n<li><code>compress<\/code> \/ <code>delaycompress<\/code>: Compress rotated logs with gzip (starting from the second newest file).<\/li>\n<li><code>missingok<\/code> \/ <code>notifempty<\/code>: Do not complain if the file is missing or empty.<\/li>\n<\/ul>\n<p>For most cPanel environments, tightening these rules (for example, from 90 days to 14 or 30 days for large, low\u2011value logs) immediately frees disk space without losing useful data. Security and audit logs can be retained longer but perhaps moved off the main server, which we will cover in the S3 section.<\/p>\n<h3><span id=\"Configuring_gzip_and_rotation_on_unmanaged_VPS_servers\">Configuring gzip and rotation on unmanaged VPS servers<\/span><\/h3>\n<p>On a plain VPS, you have full control. Typical steps:<\/p>\n<ol>\n<li>Inspect existing rules: <code>cat \/etc\/logrotate.conf<\/code> and <code>ls \/etc\/logrotate.d\/<\/code>.<\/li>\n<li>Add or adjust rules for key services such as Nginx, Apache, MySQL, PostgreSQL, and your application logs.<\/li>\n<\/ol>\n<p>Example for Nginx logs:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">\/var\/log\/nginx\/*.log {\n    daily\n    rotate 7\n    size 100M\n    compress\n    missingok\n    notifempty\n    sharedscripts\n    postrotate\n        [ -f \/run\/nginx.pid ] &amp;&amp; kill -USR1 $(cat \/run\/nginx.pid)\n    endscript\n}\n<\/code><\/pre>\n<p>Example for a Laravel application log under <code>\/var\/www\/example.com\/storage\/logs\/laravel.log<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">\/var\/www\/example.com\/storage\/logs\/laravel.log {\n    daily\n    rotate 30\n    compress\n    missingok\n    notifempty\n    copytruncate\n}\n<\/code><\/pre>\n<p>The <code>copytruncate<\/code> directive tells logrotate to copy the existing file, then truncate it in place so that PHP can keep writing to the same file handle. It is not perfect for ultra\u2011high traffic systems, but for most small to medium sites it works well.<\/p>\n<p>Once gzip and logrotate are correctly set, you have a rolling window of compressed history. The next step is to decide <strong>which of those compressed logs stay on the server<\/strong>, and which should be offloaded to cheaper, more scalable storage.<\/p>\n<h2><span id=\"Offloading_Logs_to_S3Compatible_Object_Storage\">Offloading Logs to S3\u2011Compatible Object Storage<\/span><\/h2>\n<p>Even compressed, long log histories eat storage and clutter backups if they remain on your main server forever. A better pattern is:<\/p>\n<ul>\n<li>Keep a <strong>short, recent window<\/strong> of logs locally (for example, 7\u201330 days).<\/li>\n<li><strong>Archive older logs<\/strong> to an external, S3\u2011compatible object storage bucket.<\/li>\n<li>Apply separate, cheaper retention rules on that bucket (months or years).<\/li>\n<\/ul>\n<p>Object storage is ideal here: it is inexpensive, highly durable and designed for exactly this kind of \u201cwrite once, read rarely\u201d data. At dchost.com we often pair VPS or dedicated servers with S3\u2011compatible object storage for backups and log archives, so that customers can scale retention without constantly resizing disks.<\/p>\n<h3><span id=\"Designing_your_bucket_structure\">Designing your bucket structure<\/span><\/h3>\n<p>For logs, a clear naming structure makes later searches much easier. A common pattern is:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">logs\/&lt;environment&gt;\/&lt;hostname&gt;\/&lt;service&gt;\/YYYY\/MM\/DD\/filename.log.gz\n<\/code><\/pre>\n<p>For example:<\/p>\n<ul>\n<li><code>logs\/production\/cpanel01\/web\/2026\/02\/07\/access_log-20260207.gz<\/code><\/li>\n<li><code>logs\/staging\/vps-api01\/nginx\/2026\/02\/07\/access.log-20260207.gz<\/code><\/li>\n<\/ul>\n<p>This structure lets you filter by environment, server and service when you later ingest logs into a central system or respond to an incident.<\/p>\n<h3><span id=\"Tools_to_sync_logs_to_object_storage\">Tools to sync logs to object storage<\/span><\/h3>\n<p>On Linux servers we usually rely on command\u2011line tools that speak the S3 API:<\/p>\n<ul>\n<li><strong>rclone:<\/strong> Very flexible, supports many storage providers, sync and copy modes, encryption and bandwidth limits.<\/li>\n<li><strong>s3cmd<\/strong> or other vendor tools: Simple and widely used; good for basic scripts.<\/li>\n<li><strong>restic \/ borg:<\/strong> Backup tools that can also handle log archives as part of a wider backup strategy; we covered this pattern in <a href=\"https:\/\/www.dchost.com\/blog\/en\/object-storagea-otomatik-yedek-alma-rclone-restic-ve-cron-ile-cpanel-vps-yedekleri\/\">our article on automating off\u2011site backups to object storage with rclone, restic and cron<\/a>.<\/li>\n<\/ul>\n<h3><span id=\"Example_rclonebased_log_archive_sync\">Example: rclone\u2011based log archive sync<\/span><\/h3>\n<p>1. Configure an S3\u2011compatible remote with rclone:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">rclone config\n# Create a new remote, choose S3, enter endpoint, access key and secret key\n<\/code><\/pre>\n<p>Assume the remote is called <code>logarchive<\/code> and the bucket <code>my-logs<\/code>.<\/p>\n<p>2. Create a local directory where rotated, compressed logs live, for example <code>\/var\/log\/archive\/<\/code>. Configure your logrotate rules to move older <code>.gz<\/code> files there using the <code>olddir<\/code> directive:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">\/var\/log\/nginx\/*.log {\n    daily\n    rotate 7\n    compress\n    olddir \/var\/log\/archive\/nginx\n    missingok\n    notifempty\n}\n<\/code><\/pre>\n<p>3. Add a cron job to sync archives to object storage, for example once per night:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">0 2 * * * \/usr\/bin\/rclone sync \n  \/var\/log\/archive\/nginx \n  logarchive:my-logs\/production\/vps-api01\/nginx \n  --transfers=4 --checkers=4 --log-file=\/var\/log\/rclone-logarchive.log --log-level=INFO\n<\/code><\/pre>\n<p>4. After confirming files are safely uploaded and versioning is enabled on the bucket, you can add another logrotate or cron\u2011driven cleanup on the <code>\/var\/log\/archive\/<\/code> directory itself, keeping only 7\u201330 days locally while the bucket holds months or years.<\/p>\n<h3><span id=\"Security_considerations_for_log_archives\">Security considerations for log archives<\/span><\/h3>\n<ul>\n<li><strong>Encryption:<\/strong> Enable server\u2011side encryption on your object storage bucket where possible. For sensitive logs, consider client\u2011side encryption (for example rclone\u2019s <code>crypt<\/code> backend on top of S3).<\/li>\n<li><strong>Access control:<\/strong> Use dedicated access keys with minimal permissions (only the specific bucket and folder, write\u2011only if feasible from the server side).<\/li>\n<li><strong>Public access:<\/strong> Log buckets should never be public. Make sure block\u2011public\u2011access style settings are enabled.<\/li>\n<\/ul>\n<p>We also strongly recommend reviewing what personal data appears in logs. If you operate in KVKK\/GDPR\u2011regulated environments, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/kvkk-ve-gdpr-icin-log-anonimlestirme-ip-maskeleme-ve-pseudonymization\/\">log anonymisation and IP masking for KVKK\/GDPR\u2011compliant logs<\/a> is a good companion to this archiving guide.<\/p>\n<h2><span id=\"Designing_Realistic_Log_Retention_Policies\">Designing Realistic Log Retention Policies<\/span><\/h2>\n<p>Compression and S3 offload answer the <em>how<\/em> of log archiving. Retention policies answer the <em>how long<\/em>. Without clear policies, teams either keep everything forever (wasting storage and increasing privacy risk) or delete too aggressively (hurting incident response and compliance).<\/p>\n<h3><span id=\"Step_1_Classify_your_logs\">Step 1: Classify your logs<\/span><\/h3>\n<p>A practical way to start is to classify logs into three broad categories:<\/p>\n<ul>\n<li><strong>Operational logs:<\/strong> Web access logs, application logs at <code>INFO<\/code> level, general system logs. These help you troubleshoot performance issues or errors.<\/li>\n<li><strong>Security and audit logs:<\/strong> Authentication logs, firewall logs, panel access logs, admin actions. These are crucial for investigating suspicious activity.<\/li>\n<li><strong>Debug logs:<\/strong> Verbose development logs, SQL debug output, framework debug modes. These are usually only needed in dev\/staging or for short periods in production.<\/li>\n<\/ul>\n<h3><span id=\"Step_2_Map_categories_to_retention_periods\">Step 2: Map categories to retention periods<\/span><\/h3>\n<p>The exact numbers depend on your industry and any contractual or legal obligations, but a typical baseline for many small and medium businesses might look like this:<\/p>\n<table>\n<thead>\n<tr>\n<th>Log type<\/th>\n<th>Local retention (on server)<\/th>\n<th>Archive retention (object storage)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Web access logs<\/td>\n<td>7\u201330 days<\/td>\n<td>3\u201312 months<\/td>\n<\/tr>\n<tr>\n<td>Application error logs<\/td>\n<td>14\u201360 days<\/td>\n<td>6\u201312 months<\/td>\n<\/tr>\n<tr>\n<td>Database logs (slow query, error)<\/td>\n<td>7\u201330 days<\/td>\n<td>3\u20136 months<\/td>\n<\/tr>\n<tr>\n<td>Security\/audit logs (SSH, panel logins)<\/td>\n<td>30\u201390 days<\/td>\n<td>12\u201324 months (depending on policy)<\/td>\n<\/tr>\n<tr>\n<td>Debug logs<\/td>\n<td>0\u20137 days (only during an incident)<\/td>\n<td>Usually no archive<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>When you design these periods, align them with whatever you have defined for backups and database snapshots. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yedek-saklama-suresi-nasil-belirlenir-kvkk-gdpr-ve-maliyet-dengesi\/\">how long you should keep backups under KVKK\/GDPR vs storage costs<\/a> follows the same logic, and it is helpful to treat logs as just another dataset within your overall retention policy.<\/p>\n<h3><span id=\"Step_3_Reflect_policies_in_logrotate_and_object_storage\">Step 3: Reflect policies in logrotate and object storage<\/span><\/h3>\n<p>Once you have your desired numbers:<\/p>\n<ul>\n<li>Set <code>rotate N<\/code> and <code>daily\/weekly<\/code> in logrotate to achieve your local retention window (for example, <code>daily<\/code> + <code>rotate 14<\/code> \u2248 14 days).<\/li>\n<li>Configure an S3 lifecycle policy on the log bucket to transition old objects to cheaper &#8220;cold&#8221; tiers or delete them after your archive window. For example, delete access logs after 365 days, security logs after 730 days.<\/li>\n<\/ul>\n<p>The combination of logrotate + S3 lifecycle policies gives you automated enforcement: old logs disappear on schedule without manual cleanup.<\/p>\n<h3><span id=\"Step_4_Think_about_privacy_and_minimisation\">Step 4: Think about privacy and minimisation<\/span><\/h3>\n<p>Under KVKK\/GDPR, you must not keep personal data longer than necessary for your stated purposes. Logs often contain IP addresses, user IDs, email addresses and sometimes request bodies. A few practical tips:<\/p>\n<ul>\n<li>Shorten retention for logs with high personal data exposure (for example, application request logs that include full URLs with query parameters).<\/li>\n<li>Prefer anonymised or pseudonymised fields where possible, especially for long\u2011term archives. Again, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/kvkk-ve-gdpr-icin-log-anonimlestirme-ip-maskeleme-ve-pseudonymization\/\">log anonymisation guide<\/a> dives deeper into concrete techniques.<\/li>\n<li>Document your retention decisions in a policy document that your technical and legal teams both understand.<\/li>\n<\/ul>\n<h2><span id=\"Putting_It_All_Together_Reference_Architectures_for_cPanel_and_VPS\">Putting It All Together: Reference Architectures for cPanel and VPS<\/span><\/h2>\n<p>Let us combine the pieces into two concrete setups you can implement today: one for WHM\/cPanel servers and one for custom VPS environments.<\/p>\n<h3><span id=\"Scenario_1_WHMcPanel_server_hosting_many_sites\">Scenario 1: WHM\/cPanel server hosting many sites<\/span><\/h3>\n<p>This is common for agencies and resellers using dchost.com\u2019s cPanel hosting or their own dedicated\/cPanel servers.<\/p>\n<ol>\n<li><strong>Review existing rotation:<\/strong>\n<ul>\n<li>Check WHM\u2019s log configuration for Apache, cPanel and Exim.<\/li>\n<li>Inspect <code>\/etc\/logrotate.d\/<\/code> for service\u2011specific rules.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Enable and tighten gzip:<\/strong>\n<ul>\n<li>Ensure <code>compress<\/code> is set for all high\u2011volume logs (web, mail, panel).<\/li>\n<li>Reduce <code>rotate<\/code> counts where safe. For example, from 90 to 30 days for general access logs if you also archive to object storage.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Define an archive directory and object storage sync:<\/strong>\n<ul>\n<li>Configure logrotate to move older <code>.gz<\/code> files into something like <code>\/var\/log\/archive\/{apache,exim,cpanel}<\/code>.<\/li>\n<li>Use rclone or s3cmd with a nightly cron job to push those archives into a bucket such as <code>logs\/production\/cpanel01\/&lt;service&gt;\/<\/code>.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Apply lifecycle policies on the bucket:<\/strong>\n<ul>\n<li>For example: keep Apache logs for 12 months, Exim logs for 24 months, cPanel access logs for 18 months.<\/li>\n<li>Optionally transition older objects to a colder, cheaper storage class after 90 days.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Document and test:<\/strong>\n<ul>\n<li>Write down which logs live where, and for how long.<\/li>\n<li>Run a test by restoring a specific log file from the object storage archive and verifying you can read it.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>This approach keeps the cPanel server lean \u2013 only a few weeks of logs on the main SSD \u2013 while still giving you a long, searchable history off the box. It also plays nicely with centralised log stacks if you decide to add them later.<\/p>\n<h3><span id=\"Scenario_2_Custom_VPS_with_NginxApache_databases_and_apps\">Scenario 2: Custom VPS with Nginx\/Apache, databases and apps<\/span><\/h3>\n<p>For VPS customers running their own stacks (for example, Nginx + PHP\u2011FPM + MariaDB + Redis + Node.js), you have even more flexibility.<\/p>\n<ol>\n<li><strong>Standardise log locations:<\/strong>\n<ul>\n<li>Ensure each app writes to a dedicated directory such as <code>\/var\/log\/myapp\/<\/code>, not random paths under <code>\/home<\/code>.<\/li>\n<li>Configure pm2 or systemd units to log to files or to journald consistently.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Create logrotate rules per service:<\/strong>\n<ul>\n<li>Web server: daily rotation, 7\u201314 files, gzip, <code>olddir \/var\/log\/archive\/nginx<\/code>.<\/li>\n<li>Database: smaller retention locally (7\u201330 days) because these logs can be heavy.<\/li>\n<li>App logs: tune per project; for chatty Laravel logs you might want <code>size 50M<\/code> plus daily rotation.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Sync archives to object storage:<\/strong>\n<ul>\n<li>Use rclone scripts similar to the cPanel scenario, but with separate prefixes for each VPS (for example <code>logs\/production\/vps-app01\/<\/code>).<\/li>\n<li>Encrypt logs in transit (HTTPS to the object storage endpoint) and at rest.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Optional: centralise logs for search and alerts:<\/strong>\n<ul>\n<li>Instead of only cold archives, you can stream current logs into a central stack such as ELK\/Opensearch or Grafana Loki, and keep S3 as long\u2011term storage.<\/li>\n<li>We explained this pattern in more depth in <a href=\"https:\/\/www.dchost.com\/blog\/en\/birden-fazla-sunucuda-log-yonetimi-elk-ve-loki-stack-ile-merkezi-hosting-loglama\/\">our guide to centralising logs for multiple servers with ELK and Loki<\/a>.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Monitor disk usage and adjust:<\/strong>\n<ul>\n<li>Watch actual growth over a few weeks. If <code>\/var\/log<\/code> still grows fast, tighten local retention or reduce log verbosity.<\/li>\n<li>Review object storage bills and tune lifecycle policies; moving old logs to colder storage or reducing retention can have a big impact.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>With this model, your VPS stays clean and predictable, while your log history lives in a durable, inexpensive archive. If you ever scale out to multiple VPSs, adopting a centralised stack as described above becomes a natural next step instead of a painful migration.<\/p>\n<h2><span id=\"A_Maintainable_Log_Archiving_Strategy_for_the_Long_Term\">A Maintainable Log Archiving Strategy for the Long Term<\/span><\/h2>\n<p>Log archiving on cPanel and VPS does not need to be complicated or expensive. A solid strategy rests on a few practical decisions:<\/p>\n<ul>\n<li>Use <strong>gzip and logrotate<\/strong> everywhere to keep local disks lean.<\/li>\n<li><strong>Separate hot vs cold logs:<\/strong> recent logs stay on fast SSD, older logs move to S3\u2011compatible object storage.<\/li>\n<li>Define <strong>clear retention windows<\/strong> per log category, aligned with your security, troubleshooting and regulatory needs.<\/li>\n<li>Automate enforcement with <strong>logrotate rules and object storage lifecycle policies<\/strong>, so no one has to remember manual cleanup tasks.<\/li>\n<li>Review privacy aspects and apply <strong>anonymisation or masking<\/strong> where long\u2011term retention is required.<\/li>\n<\/ul>\n<p>From our perspective at dchost.com, the teams that sleep best are the ones who know exactly how far back they can look in their logs, how quickly they can fetch an archive and when old data will be deleted. If you are already hosting with us on cPanel, VPS, dedicated servers or colocation, our support team can help you review current log growth, propose reasonable retention targets and connect your servers to S3\u2011compatible object storage for archiving. Starting small \u2013 for example with web access logs only \u2013 is perfectly fine. The important part is to move from \u201clogs grow forever until the disk is full\u201d to a conscious, documented and automated log archiving strategy.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Disk usage graphs on hosting servers rarely grow in a straight line. Traffic increases, marketing launches, more WordPress or Laravel sites get added, and in the background one thing grows steadily every single day: logs. On both cPanel hosting environments and unmanaged VPS servers, web, email, database and system logs can quietly consume gigabytes of [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4732,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4731","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4731","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4731"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4731\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4732"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4731"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4731"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4731"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}