Administration

Connect data providers

Profuz LAPIS allows to connect local, network, FTP, Google Drive, Dropbox, S3 and many others storages

  1. Open ~/apache-tomcat/production-cofig.json file in your favorite text editor
  2. Add or edit the following entry in "providers" array:
     
  {
      "storageId": 11,
      "className": "com.profuzdigital.data_server.database.providers.vfs.VfsDataProvider",
      "name": [ { "language": "en", "country": "US", "searchValue": "Storage Name" } ],
      "enabled": true,
      "authenticationDataProperties": {
        "public": ["domain", "username"],
        "sensitive": ["password"]
      },
      "indexPath": "data/vfs-blob-index",
      "uri": "file:///DATA/DATA/DATA/",
      "fileMonitorDelay": 3600000,
      "rootAuthentication": {
        "domain": null,
        "username": "guest",
        "password": ""
      },
      "defaultAuthentication": {
        "domain": null,
        "username": "guest",
        "password": ""
      }
  }

 
Fields explanation:

Save and restart tomcat to apply the changes:

sudo systemctl restart tomcat.service

SMTP Configuration

To configure SMTP server that LAPIS will use to send emals do the following:

"smtp": {
    "protocol": "TLS",
    "host": "mail.example.com",
    "port": 587,
    "username": "youraccount@example.com",
    "password": "you-passwors",
    "sender": "no-reply@example.com"
  },

Restart tomcat to apply the changes:

sudo systemctl restart tomcat.service

Server Address

To configure the server address that LAPIS will use when generating links in the emails it sends do the following:

"serverAddress": "http://localhost",

Change "http://localhost" with your LAPIS server address, for example "https://lapis.example.com"

Restart tomcat to apply the changes:

sudo systemctl restart tomcat.service

Backups

During the installation, a couple of cron-jobs are set up to backup the Mongo database and the PostgreSQL one. They are run at 3 in the morning and are put in `$HOME/backups`. These cron jobs can be modified as needed.

Backup and Restore Strategy

1. System

In case of barebone installations we recommend the following multi-layered backup and recovery approach to ensure data protection and business continuity. Such infrastructure utilizes hardware-level redundancy combined with comprehensive software backup solutions.

Hardware Redundancy

In case of virtualized environment in addition to automatic snap-shots provided by most virtualization systems you can use also the provided below solution which can be used also to move to a different environment without hassle.

2. System Backup Strategy

Relax-and-Recover (ReaR) Implementation

Manual Backup Commands

# Check ReaR configuration
rear checklayout

# Perform manual backup
rear mkbackup

# Create rescue image only
rear mkrescue

# Verbose backup with debug information
rear -v mkbackup

Recovery Scenarios

3. Database Backup Strategy

Daily Backup Operations

4. File-Level Backup Strategy

Flexible Folder Backup

5. Complete Restore Process for Hardware Failure

Scenario A: Partial Hardware Failure (Hot-swap Recovery)

  1. Disk Replacement: Hot-swap failed drives while system is running

  2. RAID Rebuild: Automatic RAID reconstruction without service interruption

  3. Time Estimate: 2-6 hours (depending on RAID array size and disk speed)

Scenario B: Complete System Failure (Approx. 3-8 hours)

Note: Time estimates exclude spare parts delivery, which depends on specific service agreements.

Phase 1: Hardware Replacement (Approx. 1-2 hours)

  1. Replace failed hardware components

  2. Rebuild RAID arrays as needed

  3. Verify hardware functionality

Phase 2: System Recovery (Approx. 1-2 hours)

Transfer recovery ISO bootup image and boot the system from it (make USB stick or DVD from if needed). In the boot screen choose either automatic or manual recovery.

Automatic Recovery (when backup storage is directly accessible):

# Boot from ReaR recovery media
# ReaR automatically detects backup location and initiates restore
# No manual intervention required

# Manual trigger if needed:
rear recover

Manual Recovery (when backup storage requires mounting):

# Boot from ReaR recovery media

# Manually mount backup storage (example for NFS):
mkdir -p /mnt/backup
mount -t nfs 192.168.1.100:/backups /mnt/backup

# Configure ReaR to use mounted backup:
cat > /etc/rear/local.conf << EOF
BACKUP_URL=file:///mnt/backup
OUTPUT_URL=file:///mnt/backup
EOF

# Execute recovery:
rear recover

Phase 3: Database Restoration (Approx. 30 mins - 1 hour)

# Navigate to backup directory
cd ~/backups/

# List available backups (organized by date)
ls -la

# Restore database from latest backup
# Specific commands depend on database type (PostgreSQL, MySQL, etc.)
# Example for PostgreSQL:
pg_restore -d database_name latest_backup_file.dump

Phase 4: File Restoration (Approx. 30 mins - 3 hours)

bash
# Restore individual folders from remote backups
# Example using rsync:
rsync -avz user@remote-server:/backup/path/ /restore/location/

# Time varies based on data volume and network bandwidth

6. Estimated Total Recovery Time

7. Key Configuration Files

ReaR Configuration (/etc/rear/local.conf)

# Example configuration
BACKUP=NETFS
BACKUP_URL=nfs://192.168.1.100/backups
OUTPUT=ISO
BACKUP_PROG_COMPRESS_OPTIONS=--gzip
BACKUP_PROG_COMPRESS_SUFFIX=.gz

Database Backup Location

8. Maintenance and Monitoring

We recommend:

9. Configuration Flexibility

All backup frequencies, retention policies, and storage locations are configurable to meet specific business requirements and compliance needs.

This comprehensive strategy ensures minimal data loss and rapid recovery in the event of hardware failure or system corruption, with hot-swap capability allowing most disk failures to be resolved without service interruption.