A backup is not a backup until you have restored from it. This is the single most important principle in data protection, and it is the reason the Panelica backup system goes beyond simply writing files to disk. It includes integrity verification, encryption, incremental chains, instant snapshots, scheduled automation with remote storage sync, and a full audit trail of every operation.
This guide covers every feature in detail — what it does, how to use it, and why it exists.
In This Article
- Full Backup — Selecting What to Protect
- Incremental Backup — Chains, Parents, and Why They Matter
- Smart Delete — Three Strategies for Chain Safety
- Chain Health — Monitoring and Maintenance
- Snapshots — Instant Recovery Points
- Scheduled Backups — Set Once, Run Forever
- Remote Storage — S3, Google Cloud, and Beyond
- Encryption — Panel Key vs. Password
- Restore — Full, Selective, and Verified
- Activity Log — The Complete Audit Trail
- Snapshot Settings — Retention, Pinning, and Auto-Cleanup
- Real-World Scenarios
1. Full Backup — Selecting What to Protect
Navigate to Backup & Restore → Create Backup in the sidebar. The first thing you see is a domain selector — a dual-list panel where your domains appear on the left (available) and your selected domains appear on the right (included in the backup).
Click a domain to move it to the selected list, or use Select All to include everything. Each domain shows its current disk usage, so you know exactly how much data you are backing up before you start.
What Gets Backed Up
A full backup captures everything needed to restore a domain to its exact state:
- Files — the entire document root, including WordPress installations, static sites, and uploaded media
- Databases — all MySQL and PostgreSQL databases associated with the selected domains
- Email — mailboxes, forwarders, and email account configuration
- DNS — zone files and DNS record configuration
- SSL — certificates, private keys, and ACME account data
Backup Name — Chain Isolation
Every backup requires a name (3 to 100 characters). This is not just a label. The name defines a backup chain — a sequence of related backups that belong together. When you create an incremental backup later, the system looks for the most recent full backup with the same name to use as a parent.
Disk Space Check
Before creating the backup, the panel shows available disk space with a progress bar. If free space drops below 5 GB, a warning appears. You will not accidentally fill your disk with a backup.
2. Incremental Backup — Chains, Parents, and Why They Matter
A full backup captures everything. An incremental backup captures only what changed since the last backup in the same chain. The result is dramatically smaller files and faster backup times — often 90% or more reduction in both size and duration.
How the Chain Works
Select Incremental as the backup type. The system automatically searches for the most recent full backup with the same name to use as the parent. If found, it shows the parent's filename, creation date, and size.
Jan 1 — 15 GB
Jan 2 — 200 MB
Jan 3 — 350 MB
Jan 4 — 150 MB
To restore to January 4, the system applies all four backups in sequence: the full backup first, then incrementals 1, 2, and 3. Each incremental stores a parent_backup_id pointing to its predecessor, forming an unbreakable chain.
When No Parent Exists
If you select incremental but no full backup with the same name exists, the system shows a warning and suggests creating a full backup first. You cannot create an incremental backup without a parent.
3. Smart Delete — Three Strategies for Chain Safety
Incremental chains create dependencies. Deleting the wrong backup can orphan every incremental that depends on it, making them unrestorable. The Smart Delete system understands these dependencies and gives you three clear options instead of a destructive yes/no dialog.
When you click the delete button on any backup, the system first analyzes the chain. It checks the backup type (full or incremental), its position in the chain, and how many other backups depend on it. This information appears in a visual summary before you make any decision.
If the Backup Has No Dependents
An incremental backup at the end of a chain, or a full backup with no incrementals, can be deleted directly. The system shows a green "Safe to Delete" badge — no further choices needed. The file is removed and the chain remains intact.
If the Backup Has Dependents
When the backup you want to delete has other backups chained to it, the modal displays a warning with the exact number of dependent backups and their filenames. Below that, three strategy cards appear:
Consolidate
RecommendedMerges the entire chain into a single new full backup before deleting the original. The data is preserved — nothing is lost. The new consolidated backup contains everything: the full backup and all incrementals combined.
If you have remote storage configured and select the remote deletion option, the consolidated backup is automatically queued for sync to the same remote destinations. Your off-site copies stay in sync.
Use when: You want to clean up chain clutter without losing any restore points.
Cascade
CautionDeletes the selected backup and every backup that depends on it. If you delete a full backup with cascade, all its incrementals go with it. If you delete an incremental in the middle of a chain, everything after it is also deleted.
The modal lists every backup that will be removed, so there are no surprises. Remote copies can be included in the cascade when you check the corresponding checkboxes.
Use when: The entire chain is outdated and you want to free maximum disk space immediately.
Force
DangerousDeletes only the selected backup, ignoring all dependency relationships. Dependent incrementals remain on disk but become orphans — they exist but cannot be restored because their parent is gone.
This is a surgical tool for unusual situations: a corrupted backup that cannot be consolidated, or a known-bad full backup where you intend to clean up the orphans separately.
Use when: You understand the chain is already broken and want manual control over the cleanup.
Remote Copies in the Delete Dialog
If the backup has been synced to remote storage, the Smart Delete modal shows a "Remote Copies" section below the strategy selector. Each remote destination appears with a checkbox. Checking it means the remote copy will also be deleted when you confirm. Leaving it unchecked preserves the remote copy even after the local file is removed.
When using Consolidate with remote delete enabled, the system performs a two-step process: first it creates the consolidated backup and deletes the chain locally, then it queues the new consolidated file for remote sync while deleting the old remote copies. The result is a clean single file both locally and remotely.
4. Chain Health — Monitoring and Maintenance
Over time, chains can develop problems. A forced delete might create orphans. A disk error might corrupt a link in the chain. The Chain Health monitor keeps track of every chain on your server and reports its status.
Health Dashboard
The backup list page includes a Chain Health card that shows four numbers at a glance:
- Healthy Chains — Chains where the full backup exists and every incremental can trace its lineage back to it. No action needed.
- Broken Chains — Chains where one or more links are missing. These incrementals cannot be restored. You can either delete them or attempt to re-create the missing backups.
- Orphan Backups — Incremental backups whose parent no longer exists. They consume disk space but serve no purpose.
- Orphan Size — The total disk space consumed by orphan backups, shown in MB or GB.
Orphan Cleanup
A single button cleans all orphan backups at once. The confirmation dialog shows exactly how many orphans exist and how much space they consume. After cleanup, the chain health numbers update automatically.
Chain-Aware Retention
Standard retention policies (“delete backups older than 10 days”) are dangerous when applied blindly to incremental chains. Deleting the full backup because it is 11 days old makes every incremental in the chain useless.
The retention system understands this. When applying retention rules, it evaluates entire chains as units. If any backup in a chain is within the retention window, the entire chain is preserved. Only when the newest incremental in a chain falls outside the retention window is the full chain removed — cleanly, as one unit, with no orphans left behind.
Hierarchical View
The backup list supports two view modes: Flat (a simple list sorted by date) and Hierarchical (backups grouped into their chains). In hierarchical mode, each chain shows the full backup as the chain header with a collapse/expand toggle. Expanding reveals all incrementals in order, with their sizes and timestamps. You can also select a specific restore point within a chain without navigating away.
5. Snapshots — Instant Recovery Points
Navigate to Backup & Restore → Snapshots in the sidebar. Snapshots are different from backups. A backup is a file you can store, move, encrypt, and restore anywhere. A snapshot is a point-in-time image of your filesystem that lives on the same server — designed for instant rollback, not off-site storage.
Two Modes, Automatic Detection
The very first thing the snapshot page does when it loads is call a filesystem detection endpoint. The system inspects your disk partitions and determines whether any mount point uses the Btrfs filesystem. This is not a setting you configure — it happens automatically, every time.
The result appears as a prominent banner at the top of the page:
Instant Mode (Btrfs Detected)
When Btrfs is found, the banner turns green with a lightning bolt icon and the word “Instant.” It also displays the Btrfs mount point path (e.g., / or /home).
Snapshots in this mode use copy-on-write (CoW) subvolume snapshots. Creation time: under one second, regardless of how much data exists. A 200 GB site gets the same instant snapshot as a 50 MB site. Initial disk cost: zero bytes. The snapshot consumes space only as the original files change after creation — and even then, only the changed blocks.
This is the same technology used by enterprise storage arrays and cloud providers. The difference is that here it runs directly on your server’s filesystem with no additional software or licensing.
Standard Mode (Rsync Fallback)
When the disk uses ext4, XFS, or any non-Btrfs filesystem, the banner turns blue with a folder icon and the word “Active.”
Snapshots in this mode use rsync to create a full file-by-file copy. Duration depends on data size — a 5 GB site takes about 30–90 seconds, a 50 GB site takes several minutes. Disk usage equals the full snapshot size, though hardlinks are used where possible to reduce overhead.
Rsync mode is fully functional. The only difference from Btrfs is speed and storage efficiency. All snapshot features (domain, server, auto, pin, restore) work identically in both modes.
Domain Snapshots vs. Server Snapshots
Domain Snapshot: Select a specific domain and create a snapshot of its files and database. Use this before updating a WordPress installation, changing DNS settings, or modifying a site's configuration.
Server Snapshot: Captures the entire server state — all domains, all configurations, all databases. Available to ROOT and ADMIN users only. Use this before major operations like PHP version upgrades or server-wide configuration changes.
Automatic Snapshots
The system can create snapshots automatically before certain operations. When enabled, an "Auto" badge appears on the snapshot with the reason — "Before DNS update," "Before SSL renewal," "Before PHP version change." These automatic snapshots mean that if something goes wrong during a routine operation, you can roll back instantly without having remembered to create a snapshot manually.
6. Scheduled Backups — Set Once, Run Forever
Navigate to Backup & Restore → Scheduled Backups. This page lets you create backup jobs that run automatically on a schedule.
Creating a Schedule
Click Create Schedule. The form includes:
- Name — identifies this schedule (also defines the backup chain for incrementals)
- Type — Full or Incremental
- Schedule — choose from presets (every hour, daily at 2:00 AM, daily at 3:00 AM, weekly on Sunday, monthly on the 1st) or enter a custom cron expression for any schedule you need
- Domains — select specific domains or all domains
- Items to include — checkboxes for Files, Databases, Emails, DNS, and SSL certificates
- Retention — number of days to keep backups before automatic deletion (1 to 365)
- Compression level — 1 (fastest) to 9 (smallest files), default 6 (balanced)
- Encryption — enable panel-key encryption for all backups created by this schedule
Remote Storage Sync
If you have configured remote storage destinations, a Sync to Remote toggle appears. Enable it and select one or more destinations. After each backup completes locally, the system automatically uploads it to every selected destination. If the upload fails, it retries with exponential backoff (1 second, 2 seconds, 4 seconds, up to 5 retries).
Type: Full | Schedule: Daily at 2:00 AM | Domains: All | Include: Files + Databases + SSL | Retention: 30 days | Encryption: Panel Key | Compression: 6 | Remote: AWS S3 + Google Cloud Storage
Every night at 2:00 AM, the system creates a full backup of all domains, encrypts it, compresses it, stores it locally, then uploads it to both S3 and GCS. Backups older than 30 days are automatically deleted from local storage.
Managing Schedules
The schedule list shows each job with its next run time displayed as a countdown. Bulk actions let you:
- Trigger All — run every active schedule immediately
- Pause All — suspend all schedules without deleting them
- Resume All — reactivate paused schedules
Individual schedules can be paused, edited, verified, or triggered on demand. The run count and last run status are visible at a glance.
7. Remote Storage — S3, Google Cloud, and Beyond
Navigate to the Destinations tab on the Backup page. This is where you configure off-site storage for your backups.
Supported Providers
| Provider | Protocol | Credentials | Use Case |
|---|---|---|---|
| AWS S3 | S3 API | Access Key + Secret Key + Bucket | Enterprise cloud storage, most popular choice |
| S3-Compatible | S3 API | Custom endpoint + Access Key + Secret Key | MinIO, Wasabi, DigitalOcean Spaces, Backblaze B2 |
| Google Cloud Storage | GCS API | Service Account JSON + Bucket | GCP infrastructure, multi-region redundancy |
| SFTP | SSH/SFTP | Server + Port + Username + Password/Key | Self-hosted storage, dedicated backup servers |
| Azure Blob Storage | Azure API | Connection String + Container | Microsoft cloud infrastructure |
Connection Testing
Before saving a destination, click Test Connection. The system verifies credentials, checks bucket/container access, writes a test file, reads it back, and deletes it. If any step fails, you see exactly what went wrong before committing the configuration.
Multi-Destination Sync
A single scheduled backup can sync to multiple destinations simultaneously. This gives you geographic redundancy — your data exists in at least three places (local server, cloud provider 1, cloud provider 2) at all times.
Each destination card shows its connection status, storage usage, and last sync time. If a destination becomes unreachable, it is flagged immediately — you do not discover the problem weeks later when you need to restore.
8. Encryption — Panel Key vs. Password
Backup encryption is available in the Create Backup form and in schedule settings. Three options exist:
No Encryption
The backup is stored as a plain compressed archive. Use this only for local storage on a server you fully control. Fastest option.
Panel Key Encryption
The backup is encrypted with AES-256-GCM using a key derived from the panel's master encryption key. This key is unique to your Panelica installation — backups can only be decrypted on the same panel that created them.
Best for: cloud storage where you want encryption without managing passwords. Upload to S3 knowing that even if someone gains access to the bucket, the files are unreadable.
Password Encryption
The backup is encrypted with AES-256-GCM using a key derived from a password you provide. The derivation uses PBKDF2-SHA256 with 100,000 iterations, making brute-force attacks impractical.
Password requirements: minimum 12 characters, must include uppercase, lowercase, numbers, and special characters.
Best for: portable backups that may need to be restored on a different server. You can carry the encrypted backup to any Panelica installation and restore it with the password.
Chain Consistency
If a full backup in a chain is encrypted, all incremental backups in the same chain must use the same encryption method. The system enforces this automatically — if the parent is encrypted, the incremental inherits the encryption setting and shows a notice: "Encryption inherited from chain. Mixed encryption causes restore failures."
9. Restore — Full, Selective, and Verified
Navigate to Backup & Restore → Restore. The page shows three tabs: Available Backups, Restore Points, and Restore History.
Choosing a Backup
Available Backups lists every backup with its type (Full/Incremental), size, source, creation date, and status. Encrypted backups show an "Encrypted" badge. Compressed backups show a "Compressed" badge. Click the eye icon to view details, the restore icon to start restoration, or the download icon to save the file locally.
Restore Options
When you initiate a restore, a dialog presents several choices:
- Destination — restore to the original location, or specify a custom path
- Preserve File Permissions — restore original ownership and permission settings
- Overwrite Existing Files — replace current files with backup versions
- Create Backup of Current Data — automatically backs up what is there now before overwriting (safety net)
- Selective Restore — choose specific files and directories from a tree view instead of restoring everything
Selective Restore
When enabled, a file tree appears showing the contents of the backup. Expand directories, check or uncheck individual files, and restore only what you need. This is invaluable when you need to recover a single configuration file or a specific database without touching anything else.
wp-config.php from a production site. Instead of restoring the entire backup (which would overwrite all recent content), you open the backup in selective mode, navigate to the WordPress installation directory, check only wp-config.php, and restore just that one file. The site is back online in seconds, and no other data is affected.
Restore History
Every restore operation is logged with its status (complete, failed, partial), progress percentage, duration, source backup, and type. Failed restores include error details. You can view the full log of any past restore operation to understand exactly what happened.
10. Activity Log — The Complete Audit Trail
Navigate to Backup & Restore → Activity Log. Every backup-related operation is recorded here with full context:
| Field | What It Tracks |
|---|---|
| Operation | Create, Restore, Delete, Upload (remote sync), Download |
| Status | Success, Failed, Partial, In Progress |
| Backup File | Filename and path of the backup involved |
| Storage | Local, S3, GCS, SFTP — where the operation targeted |
| Size | Backup size in human-readable format |
| Duration | How long the operation took |
| User | Who performed the action (username and role) |
| IP Address | Source IP of the request |
| Timestamp | Exact start and completion time |
| Domains | Which domains were included |
| Message | Success confirmation or error details |
Filtering and Export
Filter by operation type, status, username, or date range. Export the entire log as CSV for compliance reporting or external analysis. Cleanup controls let ROOT users remove old entries (keeping the most recent 300) or delete the entire log.
11. Snapshot Settings — Retention, Pinning, and Auto-Cleanup
ROOT users can access snapshot settings by clicking the gear icon on the Snapshots page. Four controls are available:
- Auto-snapshot before changes — when enabled, the system creates a snapshot automatically before any domain modification (DNS update, SSL renewal, PHP version change)
- Compression — enable gzip compression for Rsync-mode snapshots (reduces storage by 60-70%)
- Retention — auto-delete snapshots older than a specified number of days (default: 30)
- Maximum limits — cap the number of snapshots per domain, total server snapshots, and maximum storage used
Pinning
Click the pin icon on any snapshot to mark it as pinned. Pinned snapshots are exempt from automatic cleanup — they will not be deleted by retention policies or the cleanup routine. Use this for snapshots you want to keep indefinitely, like the state of a site before a major redesign or a known-good configuration before a migration.
12. Real-World Scenarios
Here is how these features work together in practice:
Scenario 1: Daily Protection for a Business Website
Create a schedule named "Daily Production" — Full backup, daily at 2:00 AM, all domains, include Files + Databases + SSL, retention 30 days, Panel Key encryption, sync to AWS S3.
Result: Every night, a full encrypted backup is created locally and uploaded to S3. After 30 days, old local copies are deleted automatically. S3 copies follow their own retention policy. If the server dies completely, you restore from S3 onto a new server.
Scenario 2: Efficient Storage with Incremental Chains
Weekly: Full backup named "Weekly Chain" on Sunday at 3:00 AM.
Daily: Incremental backup named "Weekly Chain" Monday through Saturday at 3:00 AM.
Storage math: If a full backup is 15 GB and daily changes are ~200 MB:
Without incrementals: 7 × 15 GB = 105 GB per week
With incrementals: 15 GB + (6 × 0.2 GB) = 16.2 GB per week
That is an 85% reduction in storage usage while maintaining daily recovery points.
Scenario 3: Pre-Update Safety Net
1. Enable auto-snapshots in Snapshot Settings.
2. Update WordPress, plugins, or PHP version through the panel.
3. The system creates a snapshot automatically before each change.
4. If something breaks, go to Snapshots, find the auto-snapshot (labeled with the reason), and click Restore.
5. On Btrfs, the rollback completes in milliseconds. On ext4, it takes a few minutes.
No manual backup creation needed. No remembering to "back up before updating." The system handles it.
Scenario 4: Recovering a Single Deleted File
1. Go to Restore → Available Backups.
2. Find the most recent backup that contains the file.
3. Click Restore, enable Selective Restore.
4. Navigate the file tree to the deleted file, check it.
5. Choose "Preserve File Permissions" and start the restore.
6. The single file is extracted from the backup and placed in its original location. Nothing else is touched.
Scenario 5: Compliance and Audit
Encrypted backups (password-based for portability) synced to two remote destinations in different regions. Activity log exported monthly as CSV.
Result: You can demonstrate to auditors that data is backed up daily, encrypted at rest, stored in geographically separate locations, and that every access to backup data is logged with timestamps, usernames, and IP addresses.
Data loss is not a question of "if" but "when." A disk fails. A developer runs a destructive command. A plugin update breaks a database. Ransomware encrypts the filesystem. In every one of these scenarios, the only thing that matters is whether you have a verified, recent, and restorable backup.
The system described in this guide — full and incremental backups with chain isolation, instant Btrfs snapshots with auto-creation, scheduled automation with remote sync, AES-256 encryption with portable password option, selective file-level restore, and a complete audit trail — is designed to make that answer "yes" in every scenario.
The best backup strategy is the one you set up once and never have to think about again — until the day you need it, when it works exactly as expected.