mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-04 12:02:33 +02:00
Divarion_D
47200c1322
Make 'beta' the canonical update_channel value across the settings UI, GitHubReleases (prerelease filter + cache-file suffix + setChannel), the binary/fanout update commands, and the module channel mapping. 'unstable' is kept as a legacy alias so nothing breaks mid-upgrade: GitHubReleases::normalizeChannel() maps it to 'beta', and the binary commands still accept it. Migration 011 rewrites existing settings.update_channel 'unstable' -> 'beta', and the settings dropdown normalizes a stale 'unstable' to show Beta selected before the migration runs. Docs (en) updated.
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
# Updating a Server
|
|
|
|
Step-by-step guide to updating an XC_VM server. For the internals of the update process, see [Update Mechanism](../administration/update-system.md).
|
|
|
|
> 💾 Before updating, it is recommended to create a [backup](../administration/backup-strategy.md).
|
|
|
|
## Updating via the Panel
|
|
|
|
**Step 1.** Open the **Servers** section in the top menu of the panel.
|
|
|
|
|
|
|
|
**Step 2.** Select **Manage Servers** from the dropdown menu.
|
|
|
|
|
|
|
|
**Step 3.** Locate the target server in the servers table and click the menu button in the **Actions** column.
|
|
|
|
|
|
|
|
**Step 4.** Select **Server Tools** from the menu.
|
|
|
|
|
|
|
|
**Step 5.** In the **Server Tools** dialog, click **Update Server**.
|
|
|
|
|
|
|
|
Clicking the button inserts an `update` signal into the database. Within a minute, CRON picks it up and the update runs automatically: the panel is stopped, updated, and restarted. You can track progress via the server version in the **Manage Servers** table.
|
|
|
|
## Manual Update (CLI)
|
|
|
|
```bash
|
|
sudo -u xc_vm /home/xc_vm/console.php update update
|
|
```
|
|
|
|
Downloads and applies the latest update from GitHub. Usually triggered automatically through the web panel.
|
|
|
|
## Rolling Back a Server
|
|
|
|
If an update introduces a problem, you can roll a server back to an earlier release directly from the panel. Rollback works per-server, so both the **MAIN** panel and individual **Load Balancers** can be downgraded independently.
|
|
|
|
**Step 1.** Open the **Servers** section → **Manage Servers**.
|
|
|
|
**Step 2.** Locate the target server and open its **Actions** menu (the same menu used for updating).
|
|
|
|
**Step 3.** Click **Rollback Version**. A dialog opens listing earlier releases (newest first). Pre-release builds are tagged `(beta)`.
|
|
|
|
**Step 4.** Select the version to roll back to and confirm.
|
|
|
|
Clicking **Rollback** inserts a `rollback` signal (carrying the chosen version) into the database. Within a minute CRON picks it up and the rollback runs automatically, reusing the same stop → replace → restart flow as an update. Track progress via the server version in the **Manage Servers** table.
|
|
|
|
> 💾 On the **MAIN** server a database backup is taken automatically before the rollback, saved to `/home/xc_vm/backups/pre_rollback_<from>_to_<to>_<timestamp>.sql`. Load balancers have no database, so this step is skipped.
|
|
|
|
The versions offered depend on the server's update channel: on the `stable` channel only stable releases are listed; on `beta` you also see `(beta)` pre-releases.
|
|
|
|
> ⚠️ A rollback **does not undo database migrations** — they are forward-only. The schema is designed to stay backward-compatible, and the automatic backup is the recovery path if an older build cannot read newer data. Use rollback only as a recovery step.
|
|
|
|
### Manual Rollback (CLI)
|
|
|
|
```bash
|
|
sudo -u xc_vm /home/xc_vm/console.php update rollback 2.4.0
|
|
```
|
|
|
|
Downloads the specified release from GitHub and applies it, with the same integrity checks and — on MAIN — the automatic database backup.
|