Data Protection by the 3-2-1 Rule: Automation and Restoration Guarantee

Once, a client lost 3 months of data due to a RAID array failure. The backup was stored on the same physical server — both copies were lost. Recovery was only possible from a six-month-old copy on a developer's laptop. According to statistics, 30% of companies do not check backups, and 50% store them on the same hosting as the main site. Data loss costs businesses an average of 2 million rubles. It's a direct path to irreparable losses that amount to tens and hundreds of thousands of rubles in downtime. We have been doing backups for 10 years and have serviced over 200 projects.

Unlike many companies, we don't just set up scripts — we design a backup architecture that withstands hardware failure, human error, and even targeted attacks. Our engineers are certified in AWS and PostgreSQL, which ensures correct configuration of S3 Lifecycle and pg_dump with atomicity and consistency checks.

The 3-2-1 rule is the gold standard for backup that eliminates such risks. Source: Wikipedia. We configure automatic backups that comply with this rule, using S3 storage and smart rotation. The result is a guaranteed ability to roll back to any point in the last 90 days. Data is safe even in case of hardware failure.

Why Backup Is Not an Option but a Necessity?

Backup on the same server is false security. If RAID fails, both copies are lost. We move backups to S3 and configure Lifecycle — now data is duplicated in another region. Storage cost for 10 GB on S3 is less than 5 rubles per month, while data loss can cost millions. It's an investment that pays off at the first accident. For example, monthly cost for storing 50 GB of backups is about 25 rubles. And data recovery after a failure can cost hundreds of thousands of rubles. The savings are obvious. Custom scripts are 10x more flexible than ready plugins, especially for complex rotation policies.

Which Data We Back Up First

The database is the main source of changes. For WordPress with 10k+ daily visitors, we set up DB backups every 6 hours. Upload files (uploads/, storage/) — once a day. Configuration files (.env, nginx.conf) — after every change. Code is in Git, but a backup copy of the repository on a separate server wouldn't hurt.

Setting Up Automatic Backup in 2–4 Hours

We use bash, pg_dump, rsync, and S3. Below is a typical scenario.

Automatic DB Backup to S3

#!/bin/bash
# /opt/scripts/backup-db.sh

set -euo pipefail

DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mysite_prod"
BACKUP_DIR="/tmp/backups"
S3_BUCKET="s3://my-backups/database"

mkdir -p "$BACKUP_DIR"

# PostgreSQL
pg_dump -U postgres -d "$DB_NAME" -F custom \
  | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Upload to S3
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" \
  "${S3_BUCKET}/${DB_NAME}_${DATE}.dump.gz" \
  --storage-class STANDARD_IA

# Clean local
rm "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Remove old (30 days)
aws s3 ls "${S3_BUCKET}/" \
  | awk '{print $4}' \
  | while read key; do
      date=$(echo "$key" | grep -oP '\d{8}')
      if [[ $(date -d "$date" +%s) -lt $(date -d "30 days ago" +%s) ]]; then
          aws s3 rm "${S3_BUCKET}/${key}"
      fi
  done

echo "Backup completed: ${DB_NAME}_${DATE}.dump.gz"

Crontab: every 6 hours

0 */6 * * * /opt/scripts/backup-db.sh >> /var/log/backup.log 2>&1

S3 Lifecycle Policies for Automatic Rotation

{
  "Rules": [{
    "ID": "BackupRetention",
    "Filter": { "Prefix": "database/" },
    "Status": "Enabled",
    "Transitions": [
      { "Days": 7,  "StorageClass": "STANDARD_IA" },
      { "Days": 30, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 90 }
  }]
}

File Backup via rsync + S3

# Syn uploads/ to S3
aws s3 sync /var/www/mysite/storage/app/public/ \
  s3://my-backups/files/ \
  --storage-class STANDARD_IA \
  --delete

# Without --delete (safer, but grows)
aws s3 sync /var/www/mysite/uploads/ s3://my-backups/uploads/

Backup Setup Stages

1. Data volume assessment: determine DB size, files, and growth rate.
2. Strategy selection: backup frequency, retention depth, S3 storage classes.
3. Script writing: pg_dump, rsync, aws cli.
4. Crontab configuration: for DB — every 6 hours, for files — once a day.
5. S3 Lifecycle configuration: automatic rotation and deletion of old copies.
6. Test recovery: simulate a failure and verify restore.

Backup Verification Procedure

A backup without recovery verification is an illusion of security. Run a test recovery monthly in an isolated environment:

# Monthly restore test
aws s3 cp s3://my-backups/database/latest.dump.gz /tmp/test-restore.dump.gz
createdb mysite_restore_test
gunzip < /tmp/test-restore.dump.gz | pg_restore -d mysite_restore_test
psql -d mysite_restore_test -c "SELECT COUNT(*) FROM users;"
dropdb mysite_restore_test

If recovery is successful — the backup works. On error, an alert is sent to Telegram. This approach guarantees that data will be available at a critical moment. We perform checksum verification and I/O throughput measurement to ensure WORM compliance.

Backup Service Composition

• Development of backup scripts (DB, files, configs)
• Crontab and S3 Lifecycle configuration
• Test recovery in an isolated environment
• Monitoring with daily healthcheck and alerts
• Documentation with full scheme and instructions
• Delivery of all scripts, access to S3 bucket, and a 1-month post-deployment support period
• Team training session on manual recovery procedures

Before project delivery, we verify that crontab is configured for DB and files, S3 Lifecycle policy is created, test recovery was performed, monitoring with alerts is set up, and documentation is handed over to the client.

Custom Script or Ready Plugin: What to Choose?

Custom script is justified for custom scenarios: rotation, multiple DBs, monitoring integration. For simple sites, ready plugins are faster, but we recommend a hybrid approach.

Recommended Retention Policy

Our engineers are certified in AWS and PostgreSQL. We guarantee restoration from backup. Order a consultation — we will select the optimal strategy for your project. Want to secure your project? Contact us — we will assess your infrastructure in one day and offer the best strategy.

Website Technical Support: Updates, Monitoring, SLA

A website on Laravel 8 with PHP 7.4. PHP 7.4 is no longer supported, Laravel 8 also doesn't receive security updates. The hosting provider warned about the mandatory PHP update to 8.1 — after the update, two plugins and one library broke, the site went down. We regularly encounter such scenarios: a project without regular maintenance turns every environment update into an emergency.

This case is not an exception, but a rule. Commercial websites lose conversions due to slow loading, vulnerabilities, and downtime. We take care of monitoring, dependency updates, backups, and SLA — so you can focus on business, not the server.

Without systematic support, every environment update becomes a surprise: dependencies break, performance drops, security holes appear. Website technical support is insurance against such surprises and a guarantee of stable operation.

What Actually Goes into Website Technical Support?

Support is not "answering a call when something breaks." It is systematic prevention of breakdowns.

Dependency updates. Composer packages, npm packages, CMS or framework. composer audit and npm audit show known vulnerabilities. Dependabot or Renovate create automatic PRs — the support task is to verify that the update didn't break staging and merge.

Updates types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates for 6+ months accumulates tech debt: bigger gap, more work.

WordPress is a separate story. The platform's popularity makes it a prime attack target. Outdated plugins are the #1 attack vector. Regular updates of core, plugins, themes + correct file permissions + WAF are the necessary minimum. Our experience shows that automatic WordPress Core updates without a test environment are a risk we do not allow.

How Does Monitoring Prevent Downtime?

Uptime monitoring. Basic HTTP check every minute. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert to Telegram or Slack on downtime — and notification upon recovery. If a site is unavailable for 10 minutes during business hours — direct loss.

Performance. TTFB, LCP, INP — we track via Google Search Console (real users, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Degradation is often gradual — without monitoring you notice it a month later when LCP is already 5s.

Application errors. Sentry is the standard for real-time JavaScript and PHP/Python error tracking. Each unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.

Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. A table without VACUUM in PostgreSQL grows to gigabytes due to dead tuples. Routine database maintenance is part of support.

Disk space and logs. Is logrotate configured? /var/log/nginx growing without limits and filling the disk — classic. Automatic rotation + alert at disk > 80%.

Why Are Backups Without Verification an Illusion?

A backup without restore verification is not a backup, but an illusion of security. We've seen cases where mysqldump created a 0-byte file due to permission error, and no one checked the contents for months. We guarantee all copies are restorable.

Backup scheme:

• Daily incremental backup of database + media files
• Weekly full backup
• Storage: at least 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
• Automatic integrity check (pg_restore --list, mysqldump verify)
• Test restore once a quarter in an isolated environment

Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.

SLA: What Does It Mean in Practice?

SLA (Service-Level Agreement) Wikipedia — specific commitments for response and resolution times:

SLA makes sense only with monitoring — otherwise you learn about problems from users, not systems. A broken button in a form can silently kill conversions for weeks.

Content Update Process

A developer should not be in the chain for editing text on a page. CMS with a convenient editor, role separation (editor edits content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.

Preview before publishing, staged rollout for important changes. If editors work directly on prod — that's a risk.

Typical Situations We Resolve

Website hack: attack vector analysis, cleanup, security hardening (WAF, fail2ban, file permission restrictions). Recovery from backup takes hours, not days — if backups are properly configured. Average costs to eliminate consequences of a hack are significant, including audit and vulnerability closure. Regular support is much cheaper and prevents such incidents.

Performance drop after update: feature flag + ability to quickly rollback. Canary deployment — update 5% of traffic, check metrics, then 100%.

What's Included in the Support Package (Deliverables)

Upon signing the contract, you receive:

• Documentation: infrastructure diagram, access, recovery procedures
• Monitoring: uptime, performance, errors, logs — set up from day one
• Backup: daily/weekly copies with verification
• Dependency updates: monthly audit and update with testing
• SLA response: per priorities from the table above
• Reports: weekly dashboards, monthly review, quarterly tech plan
• Content editing support: editor training, permission setup

Contact us to choose a suitable plan and get an initial audit of your project.

How We Work: Stages

1. Onboarding (3–5 days): audit of current state, setup of monitoring and backups, infrastructure documentation.
2. Regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
3. Response: per SLA, with recording of cause and resolution time.
4. Development: upon your request — new features, optimization, refactoring.

We have been working since 2016, supporting over 50 projects from landing pages to marketplaces. Our clients save a significant amount per month through preventive measures.

Timelines and Cost

Setting up monitoring and backups: 3–5 days. Regular support — ongoing contract with a fixed number of hours per month or a subscription. Cost is calculated individually after audit. Get a consultation — we will evaluate your project in 1–2 days.

Comparison: Monitoring with Automatic Alerting vs Manual Checking

Automatic monitoring with Better Uptime responds to failures 10 times faster than manual checking.