Backup & Restore
Complete guide to backing up and restoring LaraDashboard data including database, files, and configuration.
Backup & Restore
Regular backups are essential for data protection. This guide covers creating, managing, and restoring backups in LaraDashboard.
Backup Overview
What Gets Backed Up
| Component | Included |
|---|---|
| Database | ✅ All tables and data |
| Media Files | ✅ Uploaded files |
| Configuration | ✅ Settings and .env |
| Themes | ✅ Custom themes |
| Modules | ❌ (reinstall from source) |
| Vendor | ❌ (reinstall via Composer) |
Backup Methods
- Admin Panel - Built-in backup tool
- Command Line - Artisan commands
- Automated - Scheduled backups
- Manual - Direct database/file backup
Admin Panel Backup
Creating a Backup
- Navigate to Settings → Backups
- Click Create Backup
- Select backup options:
- Include database
- Include media files
- Include configuration
- Click Start Backup
- Download when complete
Backup Options
| Option | Description | Size Impact |
|---|---|---|
| Database | MySQL dump | Small-Medium |
| Media | Storage files | Large |
| Config | Environment settings | Tiny |
Managing Backups
View existing backups:
┌─────────────────────────────────────────────────────────────────┐
│ Backups [Create Backup] │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Name Size Created Actions │
│ ───────────────────────────────────────────────────────────── │
│ backup-2024-01-15.zip 245 MB Jan 15, 10:30 [⬇️] [🗑️] │
│ backup-2024-01-14.zip 242 MB Jan 14, 10:30 [⬇️] [🗑️] │
│ backup-2024-01-13.zip 240 MB Jan 13, 10:30 [⬇️] [🗑️] │
│ │
└─────────────────────────────────────────────────────────────────┘
Command Line Backup
Database Backup
# Using mysqldump
mysqldump -u username -p laradashboard > backup.sql
# With compression
mysqldump -u username -p laradashboard | gzip > backup.sql.gz
# Include stored procedures and triggers
mysqldump -u username -p --routines --triggers laradashboard > backup.sql
File Backup
# Backup storage directory
tar -czvf storage-backup.tar.gz storage/
# Backup specific directories
tar -czvf media-backup.tar.gz storage/app/public/
# Backup configuration
cp .env .env.backup
Complete Backup Script
#!/bin/bash
# backup.sh
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups/laradashboard"
APP_DIR="/var/www/laradashboard"
# Create backup directory
mkdir -p $BACKUP_DIR/$DATE
# Backup database
mysqldump -u laradashboard -p'password' laradashboard | gzip > $BACKUP_DIR/$DATE/database.sql.gz
# Backup storage
tar -czvf $BACKUP_DIR/$DATE/storage.tar.gz -C $APP_DIR storage/
# Backup configuration
cp $APP_DIR/.env $BACKUP_DIR/$DATE/.env
# Create combined archive
tar -czvf $BACKUP_DIR/backup-$DATE.tar.gz -C $BACKUP_DIR $DATE
# Cleanup individual files
rm -rf $BACKUP_DIR/$DATE
# Keep only last 7 days
find $BACKUP_DIR -name "backup-*.tar.gz" -mtime +7 -delete
echo "Backup completed: backup-$DATE.tar.gz"
Make executable and run:
chmod +x backup.sh
./backup.sh
Automated Backups
Schedule via Cron
# Edit crontab
crontab -e
# Daily backup at 3 AM
0 3 * * * /var/www/laradashboard/backup.sh >> /var/log/backup.log 2>&1
# Weekly full backup on Sunday
0 3 * * 0 /var/www/laradashboard/backup.sh --full >> /var/log/backup.log 2>&1
Laravel Scheduler
// app/Console/Kernel.php
protected function schedule(Schedule $schedule): void
{
// Daily database backup
$schedule->exec('mysqldump -u user -p laradashboard | gzip > /backups/db-$(date +\%Y\%m\%d).sql.gz')
->daily()
->at('03:00');
// Weekly full backup
$schedule->command('backup:run')
->weekly()
->sundays()
->at('03:00');
}
Cloud Storage
Backup to S3
# Install AWS CLI
sudo apt install awscli -y
# Configure credentials
aws configure
# Upload backup
aws s3 cp backup.tar.gz s3://your-bucket/laradashboard/backup-$(date +%Y%m%d).tar.gz
# Sync directory
aws s3 sync /backups/laradashboard s3://your-bucket/laradashboard/
Environment Configuration
BACKUP_DISK=s3
AWS_ACCESS_KEY_ID=your-key
AWS_SECRET_ACCESS_KEY=your-secret
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=your-backup-bucket
Restore Process
Restore from Admin Panel
- Navigate to Settings → Backups
- Select backup file or upload
- Click Restore
- Confirm restoration
- Wait for completion
Warning: Restoration overwrites current data!
Restore Database
# Standard restore
mysql -u username -p laradashboard < backup.sql
# From compressed backup
gunzip < backup.sql.gz | mysql -u username -p laradashboard
# Drop and recreate database first
mysql -u root -p
DROP DATABASE laradashboard;
CREATE DATABASE laradashboard CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL ON laradashboard.* TO 'laradashboard'@'localhost';
EXIT;
mysql -u username -p laradashboard < backup.sql
Restore Files
# Extract storage backup
tar -xzvf storage-backup.tar.gz -C /var/www/laradashboard/
# Set permissions
chown -R www-data:www-data /var/www/laradashboard/storage
chmod -R 775 /var/www/laradashboard/storage
# Restore configuration
cp .env.backup .env
Complete Restore Script
#!/bin/bash
# restore.sh
BACKUP_FILE=$1
APP_DIR="/var/www/laradashboard"
TEMP_DIR="/tmp/restore_$$"
if [ -z "$BACKUP_FILE" ]; then
echo "Usage: ./restore.sh <backup-file.tar.gz>"
exit 1
fi
# Create temp directory
mkdir -p $TEMP_DIR
# Extract backup
tar -xzvf $BACKUP_FILE -C $TEMP_DIR
# Find the backup directory
BACKUP_DIR=$(ls -d $TEMP_DIR/*/)
# Enable maintenance mode
php $APP_DIR/artisan down
# Restore database
gunzip < $BACKUP_DIR/database.sql.gz | mysql -u laradashboard -p'password' laradashboard
# Restore storage
rm -rf $APP_DIR/storage
tar -xzvf $BACKUP_DIR/storage.tar.gz -C $APP_DIR
# Restore configuration
cp $BACKUP_DIR/.env $APP_DIR/.env
# Set permissions
chown -R www-data:www-data $APP_DIR/storage
chmod -R 775 $APP_DIR/storage
# Clear caches
php $APP_DIR/artisan cache:clear
php $APP_DIR/artisan config:clear
php $APP_DIR/artisan view:clear
# Run migrations
php $APP_DIR/artisan migrate --force
# Recreate storage link
php $APP_DIR/artisan storage:link
# Disable maintenance mode
php $APP_DIR/artisan up
# Cleanup
rm -rf $TEMP_DIR
echo "Restore completed successfully"
Best Practices
Backup Strategy
Follow the 3-2-1 rule:
- 3 copies of data
- 2 different storage types
- 1 offsite location
Recommended Schedule
| Backup Type | Frequency | Retention |
|---|---|---|
| Database | Daily | 7 days |
| Full | Weekly | 4 weeks |
| Monthly | Monthly | 12 months |
| Before upgrades | Manual | Until verified |
Testing Backups
Regularly test restoration:
- Create test environment
- Restore backup
- Verify data integrity
- Test application functions
- Document any issues
Security
- Encrypt backups at rest
- Use secure transfer (HTTPS/SFTP)
- Restrict backup access
- Monitor backup processes
- Document recovery procedures
Disaster Recovery
Recovery Plan Template
# Disaster Recovery Plan
## Contact Information
- Primary Admin: name@email.com
- Backup Admin: backup@email.com
- Hosting Provider: support@hosting.com
## Recovery Steps
1. Assess situation and damage
2. Notify stakeholders
3. Obtain latest backup
4. Provision new server (if needed)
5. Restore application
6. Verify functionality
7. Update DNS (if needed)
8. Monitor for issues
## Backup Locations
- Primary: s3://bucket/backups/
- Secondary: /backups/offsite/
- Local: /backups/local/
## Expected Recovery Time
- Database only: 15 minutes
- Full restoration: 1-2 hours
- With new server: 4-6 hours
Recovery Checklist
- Latest backup identified
- Server accessible or new server ready
- Database restored
- Files restored
- Configuration verified
- Permissions set
- SSL certificate valid
- DNS pointing correctly
- Application tested
- Users notified
Troubleshooting
Backup Fails
- Check disk space
- Verify database credentials
- Check file permissions
- Review error logs
Restore Fails
- Verify backup file integrity
- Check database user permissions
- Ensure disk space available
- Review MySQL error log
Data Inconsistency
- Check backup timestamp
- Verify complete restoration
- Run database repairs if needed
- Compare with source if available
Next Steps
- Deployment Guide - Server setup
- Upgrade Guide - Version upgrades
- Troubleshooting - Common issues