Website File Backup: Setup for Data Loss Prevention
Accidental deletion of the uploads folder, a server disk failure, or an attack — without a file copy, your site becomes an empty shell. Code from git restores in minutes, but user-uploaded images, PDFs, and configs are gone. We are a team with 10+ years of experience in backup configuration. We offer turnkey setup: rsync over SFTP or S3 sync, rotation, notifications, and test restoration. We'll assess your project for free in one day. File backup is not about saving — it's about restoring. Without regular verification of copies, you risk losing data at a critical moment. Adhering to the 3-2-1 backup rule (Wikipedia) ensures data redundancy. We guarantee that after our setup, you'll be able to restore files in minutes.
Which files should be backed up and how?
Must back up: user-uploaded files (uploads/), SSL certificates (if not Let's Encrypt), custom configurations outside the repository. No need to back up: code from git, node_modules, vendor, application cache, temporary files. Git already stores history — duplicating it in the backup is pointless. Exclude large temporary folders to save space and traffic. Incremental backup copies only changed files each time, speeding up the process and reducing server load.
We use two main scenarios. The choice depends on budget and recovery speed requirements.
How to set up incremental backup using rsync
View rsync backup script
#!/bin/bash # /usr/local/bin/files-backup.sh set -euo pipefail SOURCE="/var/www/myapp/storage/app/uploads" BACKUP_HOST="backup.example.com" BACKUP_USER="backup" BACKUP_PATH="/backups/myapp/files" TIMESTAMP=$(date +%Y-%m-%d) rsync -avz \ --link-dest="${BACKUP_PATH}/latest" \ --exclude="*.tmp" \ --exclude=".DS_Store" \ -e "ssh -i /root/.ssh/backup_key -o StrictHostKeyChecking=no" \ "${SOURCE}/" \ "${BACKUP_USER}@${BACKUP_HOST}:${BACKUP_PATH}/${TIMESTAMP}/" ssh -i /root/.ssh/backup_key "${BACKUP_USER}@${BACKUP_HOST}" \ "ln -sfn '${BACKUP_PATH}/${TIMESTAMP}' '${BACKUP_PATH}/latest'" echo "[$(date)] Files backup completed: ${TIMESTAMP}" AWS S3 sync
View S3 sync script
aws s3 sync /var/www/myapp/storage/app/uploads/ \ s3://myapp-backups/files/uploads/ \ --delete \ --exclude "*.tmp" \ --storage-class STANDARD_IA aws s3api put-bucket-lifecycle-configuration \ --bucket myapp-backups \ --lifecycle-configuration file://lifecycle.json { "Rules": [{ "ID": "delete-old-backups", "Filter": { "Prefix": "files/" }, "Status": "Enabled", "Expiration": { "Days": 90 } }] } Comparison of rsync and S3 sync
View comparison table
| Criteria | rsync + SSH | AWS S3 sync |
|---|---|---|
| First backup speed | ~5 min for 10 GB | ~10 min for 10 GB |
| Storage cost per month for 10 GB, 90 days | ~$1.2 (server rental) | ~$0.13 (S3 STANDARD_IA) |
| Setup complexity | Medium | Low |
| Restoration | Copy back via SSH | aws s3 cp recursively |
S3 sync is better for cloud projects; rsync is ideal for full control. For initial backup, rsync is 2 times faster than S3. For storage cost, S3 is nearly 10 times cheaper than renting a server. Our solutions can reduce storage costs by up to 50% compared to an additional server.
How to choose between rsync and S3 and automate rotation?
If your server is already in AWS, S3 is natural due to integration and low cost for STANDARD_IA. With a dedicated server, rsync to a second server or SFTP storage is simpler and cheaper. We help you decide during the audit phase. Estimate data volume and change frequency upfront to avoid overpaying for storage.
Rotation prevents old copies from filling up space. For S3, configure a Lifecycle policy: keep daily copies for 30 days, weekly for 90 days, monthly for 12 months. For rsync, use scripts with find and rm or logrotate. We always configure rotation so that multiple recovery points are available.
What's included in our turnkey backup setup
Included services:
- Backup script development (bash/ansible)
- Crontab configuration with priority after database backup
- Notifications to Telegram/Slack (success/error)
- Rotation setup: S3 Lifecycle or rsync --delete-excluded
- Test restoration on staging
- Documentation: schema, contacts, restoration instructions
- Training and support for your team
Work process and timeline
- Analysis: determine directories to back up, choose storage (S3, SFTP, second server).
- Design: write script, configure access rights and SSH keys.
- Implementation: deploy solution on production, set up monitoring.
- Testing: restore files in a test environment, verify integrity.
- Deployment: finalize crontab, hand over documentation, train the team.
Configuring one scenario takes 0.5 to 1 day. The exact price depends on data volume and complexity. Our configuration service starts at $500 for a single backup scenario, including script development, rotation, and test restoration. Contact us — we'll assess your project in one day.
Common mistakes and the importance of test restoration
Common mistakes:
- Ignoring test restoration — a backup that cannot be restored is useless.
- Storing backups on the same disk as the site (RAID does not protect against accidental rm).
- Lack of notifications — a failure can go unnoticed for weeks.
Guarantee: all configured backups pass a test restoration before being handed over to the client. Without a test restoration, you don't know if the backup works. We always restore files to a staging environment and check integrity via md5sum or file count comparison. Rsync recommends using the --dry-run option for verification.
Recommended backup rotation
| Type | Frequency | Retention |
|---|---|---|
| Daily | Every day | 30 days |
| Weekly | Every week | 90 days |
| Monthly | Every month | 12 months |