Input Allow Backup Scope Selection: Subdomain Document Root vs. Parent Directory

[J.Wick]

Problem​

When hosting modern PHP applications (such as Mautic, Laravel, Symfony, or Composer-based projects) as Plesk subdomains, the current backup system creates a critical gap in disaster recovery capabilities.

Current Behavior:

• Plesk subdomain backups only include the document root directory (e.g., /var/www/vhosts/example.com/subdomains/app/httpdocs or docroot)
• Modern applications follow best practices by placing critical files outsidethe web-accessible directory for security:
  • 
    /bin/ - CLI executables and console commands
  • /config/ - Application configuration
  • /vendor/ - Composer dependencies (often 50-200MB)
  • 
    /var/ - Application cache, logs, and runtime data
  • Root-level files: composer.json, composer.lock, .env, package management files

The Impact: When restoring from a Plesk backup, administrators receive only the web-accessible files. The application is non-functional because:

1. Composer dependencies are missing (/vendor/)
2. Configuration files are absent (/config/, .env)
3. CLI tools are unavailable (/bin/console)
4. Package manifests are lost (composer.json, package.json)

This forces manual reconstruction of the application environment, defeating the purpose of automated backups and significantly extending recovery time from hours to potentially days.

​

Proposed Solution​

Add a backup scope selector for subdomain subscriptions with two options:
Option 1: Document Root Only (Current Default)

• Backs up only /httpdocs or /docroot
• Suitable for simple HTML/PHP sites
• Maintains current behavior for backward compatibility

Option 2: Full Application Directory (New)

• Backs up the entire subdomain parent directory
• Includes all sibling directories to the document root
• Excludes only Plesk-managed directories (logs/, statistics/, etc.)
• Allows optional exclusion patterns (e.g., node_modules/, var/cache/)

​

Implementation Suggestions​

UI Location:

• Add checkbox in Backup Manager: "☐ Include full application directory (not just document root)"
• Add option in scheduled backup configuration
• Include in CLI: plesk bin pleskbackup --domains-name example.com --full-directory

Default Behavior:

• Keep current behavior as default (document root only) for backward compatibility
• Show informational tooltip explaining the difference

Exclusion Patterns: Allow administrators to define exclusion patterns similar to existing functionality:

bash


plesk bin pleskbackup --domains-name app.example.com --full-directory \
-exclude-pattern "node_modules/*,var/cache/*,var/tmp/*"

​

Benefits​

For Hosting Providers:

1. Competitive Advantage - Support modern application frameworks out-of-the-box
2. Reduced Support Tickets - Fewer "my backup doesn't work" complaints
3. Customer Retention - Developers won't migrate to Docker/VPS solutions for proper backups
4. Market Alignment - Competitors (cPanel, DirectAdmin) face the same issue; be first to solve it

For End Users:

1. True Disaster Recovery - One-click restore that actually works
2. Time Savings - No manual reconstruction of application dependencies
3. Confidence - Backups that match modern development practices
4. Flexibility - Choose the right backup scope for each application type

For Plesk:

1. Modern Framework Support - Aligns with Laravel, Symfony, Mautic, Magento, and other Composer-based applications
2. Best Practices Compliance - Supports the security practice of keeping sensitive files outside document root
3. Minimal Development Effort - Extends existing backup logic rather than creating new systems
4. No Breaking Changes - Opt-in feature maintains full backward compatibility

​

Use Cases​

1. Laravel/Symfony Applications - Require /vendor/, /config/,
   
   /bin/, .env
2. Mautic Marketing Automation - Needs /vendor/, /bin/console, composer.json
3. Magento E-commerce - Requires complete directory structure
4. Custom Business Applications - Any Composer-managed project
5. Node.js Applications - Need package.json, node_modules/, configuration files

​

Current Workarounds (and Why They're Inadequate)​

Users currently resort to:

1. Manual cron scripts copying files into docroot/ before backup - fragile, doubles storage
2. Separate backup solutions - defeats Plesk's value proposition
3. Avoiding Plesk for modern apps - lost revenue opportunity
4. Restructuring applications - breaks framework conventions, creates security risks

​

Conclusion​

This enhancement bridges the gap between Plesk's traditional hosting model and modern application architecture. It's a natural evolution that acknowledges how PHP applications are built today while maintaining full backward compatibility.
Expected Outcome: Plesk becomes the preferred hosting control panel for modern PHP frameworks, reducing churn and attracting developers who currently view Plesk as unsuitable for Composer-based applications.

---

Priority: Medium-High
Complexity: Low (extends existing backup logic)
Breaking Changes: None (opt-in feature)
Target Users: Developers, agencies, SaaS providers using modern PHP frameworks