Backups and Restoration - ABDELHAK BOUDJELIDA - PhD in Accounting and Finance | Researcher

Guide Contents

Why do we need backups in the first place?
A quick manual backup (to try the command first)
Automatic daily backup via Cron
Backing up the files folder (images and attachments)
Storing a copy off the server
How to restore a backup when needed
Quick checklist

Why do we need backups in the first place?

The database (MySQL) stores everything: employee names, attendance records, related salaries, requests, tasks. If it gets deleted by mistake (a wrong command, a corrupted disk, a ransomware attack) without a backup, that means losing the company's entire history with its employees forever. Backups aren't a luxury — they're mandatory insurance for any system holding real employee data.

A quick manual backup

Before automating anything, try the command manually once so you understand exactly what happens.

Export the entire database into a single file

mysqldump -u workup_user -p workup > ~/workup_backup_$(date +%F).sql

mysqldump reads every table in the workup database and converts it into text SQL commands inside a single file (the same idea as the db.sql file we imported during installation, but this time it holds your real data). $(date +%F) automatically appends today's date to the file name (like workup_backup_2026-07-17.sql) so you don't mix up different backups.

Make sure the file was actually created and its size makes sense (not zero):

ls -lh ~/workup_backup_*.sql

Automatic daily backup via Cron

Don't rely on your memory to run the command manually every day — have the server do it itself at a fixed time (for example, 3 AM, when no one is using the system).

Create a simple backup script

sudo mkdir -p /var/backups/workup
sudo nano /usr/local/bin/workup-backup.sh

Paste this exact content:

#!/bin/bash
# Today's date, used for naming the files
DATE=$(date +%F)

# Database backup
mysqldump -u workup_user -p'put_password_here' workup > /var/backups/workup/db_$DATE.sql

# Backup of the files folder (images and attachments) as a single compressed archive
tar -czf /var/backups/workup/files_$DATE.tar.gz -C /var/www/html/WorkUp files

# Delete any backup older than 14 days so the disk doesn't fill up
find /var/backups/workup -type f -mtime +14 -delete

This script does three things in order: (1) backs up the database, (2) compresses the entire files folder into one small file, (3) automatically deletes backups older than two weeks so disk space doesn't fill up over time.

Make the script executable:

sudo chmod +x /usr/local/bin/workup-backup.sh

Replace put_password_here with the real password for workup_user, and make sure this file is readable only by the administrator: sudo chmod 700 /usr/local/bin/workup-backup.sh — because it contains the database password as plain text.

Schedule it daily via crontab

sudo crontab -e

Add this line at the end of the file (choose nano if it asks you for an editor):

0 3 * * * /usr/local/bin/workup-backup.sh

This literally means: "run this script every day at 3:00 AM". The five numbers are, in order: minute, hour, day of month, month, day of week — and the asterisk * means "any value, no condition".

Backing up the files folder (images and attachments)

The database alone isn't enough! Employee photos and task attachments are stored as actual files inside the files/ folder on disk, not inside the database. That's why the script above also backs it up (tar -czf) alongside the database backup — together, the two form a genuine "complete backup".

Storing a copy off the server

The most dangerous common mistake: leaving all backups on the same hard disk as the original server. If the server itself fails (fire, theft, disk failure), the backups are lost along with it!

Periodically copy backups to a completely separate location

The simplest way: copy them from your personal computer (not from the server) with a single command, weekly:

scp root@server_IP_address:/var/backups/workup/*.sql ~/workup-backups-local/
scp root@server_IP_address:/var/backups/workup/*.tar.gz ~/workup-backups-local/

Better alternatives for the long term: upload them automatically to a cloud storage service (Google Drive, Dropbox, or Amazon S3) using a tool like rclone. The core idea is always the same: don't trust just one location.

How to restore a backup when needed

This is the most important section — practice it before you actually need it in an emergency.

Restoring the database

mysql -u workup_user -p workup < /var/backups/workup/db_2026-07-17.sql

This command "overwrites" any data currently in the workup database. Make sure you actually want to restore (not just test it) before running this on a server with live data.

Restoring the files folder

# Extract to a temporary location first to verify its contents
tar -xzf /var/backups/workup/files_2026-07-17.tar.gz -C /tmp/restore-check

# After verifying, copy it to the actual location (replaces the current folder)
sudo rm -rf /var/www/html/WorkUp/files
sudo tar -xzf /var/backups/workup/files_2026-07-17.tar.gz -C /var/www/html/WorkUp
sudo chown -R www-data:www-data /var/www/html/WorkUp/files
sudo chmod -R 775 /var/www/html/WorkUp/files

Don't forget to reset permissions after restoring (the same permissions as the installation step) — files restored from a backup may carry different permissions than what the server needs.

Quick checklist

You've tried the mysqldump command manually at least once and seen the resulting file.

The automatic backup script is scheduled via crontab and runs daily.

Old backups (older than 14 days) are deleted automatically instead of filling up the disk.

There's a copy of the backups stored somewhere other than the server itself (your computer, or cloud storage).

You've tested the full restoration process at least once (on a test server, not the real one) so you know it actually works.

Backup WorkUp