Restore Procedures

Restoring from a backup is straightforward, but it must be executed carefully to avoid data mismatch or corruption.

Restore Database

MySQL:

mysql -u root -p yourorganization < /backup/yourorganization_backup.sql

PostgreSQL:

psql -U postgres yourorganization< /backup/yourorganization_backup.sql

Restore Files

tar -xzvf /backup/os_files_latest.tar.gz -C /var/www/yourorganization/app/webroot/uploads/

Restart your Orangescrum services or Docker containers afterward:

docker restart orangescrum-app

Pro Tip: Always restore backups in a staging environment first to verify data consistency before applying to production.

Backing Up Database & Files

Installing Orangescrum is only the first step — maintaining it effectively is what ensures consistent uptime, performance, and data integrity.

Regular backups, version upgrades, log management, and scalability planning form the foundation of long-term success for self-hosted deployments.

This section covers essential post-deployment practices to keep your Orangescrum instance secure, optimized, and future-ready.

Astrong backup strategy protects your organization from accidental data loss, hardware failure, or human error.
Orangescrum stores its data in two key locations:

  • The database (MySQL or PostgreSQL)
  • The application file system (uploads, attachments, logs, configuration files)

Step 1: Database Backup

For MySQL / MariaDB:

mysqldump -u root -p yourorganization> /backup/yourorganization_$(date +%F).sql

For PostgreSQL:

pg_dump -U postgres yourorganization > /backup/yourorganization_$(date +%F).sql

Step 2: File Backup

Backup your application and uploaded assets:

tar -czvf /backup/os_files_$(date +%F).tar.gz /var/www/yourorganization/app/webroot/uploads

Step 3: Automate with Cron

Create a daily automated backup job:

crontab -e

Add:

0 2 * * * /usr/bin/mysqldump -u root -p’yourpassword’ yourorganization> /backup/yourorganization_$(date +\%F).sql

Recommended Frequency:

  • Database Backups: Daily
  • File Backups: Weekly
  • Retention: Keep 7 daily + 4 weekly copies

Maintenance

Maintenance, Upgrades & Backup

Installing Orangescrum is only the first step — maintaining it effectively is what ensures consistent uptime, performance, and data integrity.

Regular backups, version upgrades, log management, and scalability planning form the foundation of long-term success for self-hosted deployments.

This section covers essential post-deployment practices to keep your Orangescrum instance secure, optimized, and future-ready.

High Availability & Cluster Setup

For mission-critical deployments, you can design Orangescrum for high availability and load balancing.

Recommended Architecture

  • Load Balancer (HAProxy / Nginx): Routes traffic across app nodes
  • App Nodes (x2 or x3): Running Orangescrum containers or services
  • Database Cluster: MySQL replication or PostgreSQL streaming replication
  • Shared Storage: NFS or GlusterFS for file attachments
  • Monitoring: Prometheus + Grafana for performance tracking

Scaling Options

  • Vertical Scaling: Increase CPU/RAM on a single server
  • Horizontal Scaling: Add more app containers or nodes
  • Stateless Containers: Mount /uploads and /logs to shared persistent storage

Tip: Always maintain synchronized backups and a dedicated staging environment before performing upgrades.

Summary

Whether you choose Docker, Compose, Kubernetes, or Manual installation, Orangescrum gives you the flexibility to deploy on your terms.

  • Docker: Fast and self-contained
  • Compose: Modular and scalable
  • Kubernetes: Enterprise-grade automation
  • Manual: Maximum control and customization

Once the installation is complete, the next step is to configure your workspace — setting up admin credentials, email, storage, and SSL, which we’ll cover in Section 4: Post-Install Configuration.

Kubernetes/Helm Chart Deployment

For enterprise environments using Kubernetes (K8s), Orangescrum can be deployed as a microservice cluster. This provides auto-scaling, high availability, and rolling updates.

Step 1: Prepare Cluster

  • Minimum: 3 worker nodes (8 CPU, 16 GB RAM each)
  • Install kubectl, Helm, and configure access to your cluster.

Step 2: Create Namespace

kubectl create namespace yourname

Step 3: Configure Values File

Your values.yaml defines container images, storage, and environment variables:

app:  image: yourorganization:latest  replicas: 2  env:

    – name: DB_HOST

      value: hostname-db

    – name: DB_NAME

      value: Yourdomainname

    – name: DB_USER

      value: yourusername

    – name: DB_PASS

      value: yourpassword

db:

  image: mysql:8

  persistence:

    size: 20Gi

ingress:

  enabled: true

  hosts:

    – host: orangescrum.yourdomain.com

      paths:

        – /

Step 4: Deploy via Helm

helm install yourorganization ./helm-chart -n yourorganization
Step 5: Verify Pods
kubectl get pods -n yourorganization
Use Case: Recommended for DevOps teams running Orangescrum across multiple clusters or integrating with CI/CD pipelines.

Docker Compose

Docker Compose (Multi-Container Setup)

For production environments, you can split services into multiple containers — typically App, Database, and Reverse Proxy (Nginx/Apache).

Typical Directory Structure

/yourOraganization/├── docker-compose.yml├── app/

├── db/

└── nginx/

/yourOraganization/

├── docker-compose.yml

├── app/

├── db/

└── nginx/

Sample docker-compose.yml

version: ‘3.8’

services:

  app:

    image: yourorganization:latest

    ports:

      – “8080:80”

    depends_on:

      – db

    environment:

      – DB_HOST=db

      – DB_USER=root

      – DB_PASS=password

    volumes:

      – ./app/uploads:/var/www/html/app/webroot/uploads

  db:

    image: mysql:8.0

    restart: always

    environment:

      MYSQL_ROOT_PASSWORD: password

      MYSQL_DATABASE: database

    volumes:

      – ./db/data:/var/lib/mysql

  nginx:

    image: nginx:latest

    ports:

      – “80:80”

      – “443:443”

    volumes:

      – ./nginx/conf:/etc/nginx/conf.d

Launch Stack

docker-compose up -d

Verify Services

docker ps

Best For: Mid to large teams needing modular scaling, independent updates, and separate storage volumes.