User Backups
HiTechAdmin > Backups > Users controls how hosting users' own account backups (websites, databases, etc.) run. It's only available to Administrators and Users, not Resellers. It has three tabs: Settings, Configuration, and Runs.
On the retired container stack each account's backups ran in its own docker-volume-backup service (by offen, licensed under the Mozilla Public License 2.0). The native stack does not run that service.
There are two mutually exclusive modes, controlled entirely by the schedule of the hitechcloudcli docker-backup System Cron Job:
- User Configured (default) — each user manages their own backup from their own account, when the Backups module is enabled for them. Nothing runs centrally; the cron entry is set to a disabled placeholder schedule.
- Admin Configured — the Administrator runs backups for every user centrally, on one schedule, via
hitechcloudcli docker-backup.
See the Configuring HiTechCloud Backups article for the fuller comparison between the two approaches.
Settings
A single dropdown decides the mode:
- Disabled — user configured (the default).
- Daily / Weekly / Monthly — admin configured, all running at 03:00 server time. Fine-tune the exact time afterward from Scheduled Actions.
Saving updates the hitechcloudcli docker-backup cron entry's schedule accordingly.
Accounts excluded from the central backup takes one account name per line. Every central run, on the schedule or started with Run Backup Now, skips these accounts and writes a line for each to the Runs log (<account>: skipped: excluded from the central backup). The accounts are still backed up one at a time, never in parallel. Backups an account schedules for itself on its own Files > Backups page are not affected, and neither is a backup you start for chosen accounts from the Users list. A name that is not an account on the server is ignored, and the Settings tab marks it so a mistyped name is easy to spot. The list is kept in /etc/hitechcloud/hitechadmin/config/backups.ini (excluded_accounts under [USER_BACKUP]) and updates leave it as it is.
Configuration
The backup settings every new account starts with, one labelled field per setting. It does not change an existing account's own backup settings, only what future accounts start with.
| Group | Fields |
|---|---|
| Schedule | Frequency (off, daily, weekly, monthly), time, weekday and day of the month |
| What is included | Files, databases, mail, DNS, cron jobs and SSL certificates |
| Engine | tar or restic; a full archive every N backups; verify weekly or always; append-only (restic) |
| Retention | Keep daily, weekly and monthly copies. Leave a field empty to use the account's plan default |
| Destination | Local, S3-compatible, WebDAV, SSH/SFTP, FTP/FTPS, Azure, Dropbox, Acronis, an rclone remote, Google Drive and OneDrive (through rclone), and Backblaze B2, each with its own fields |
Restic cannot write to WebDAV, FTP, Azure, Dropbox or Acronis, and the form refuses that combination.
Passwords, keys and tokens are never shown again once saved: each shows Set or Not set. Leave the field empty to keep the stored value, or tick Clear to remove it. Test connection tries the destination with the values as filled in, before you save.
You do not need to edit any file for this. For reference, the form writes /etc/hitechcloud/backups/backup.env (the template for new accounts) and the root-only server-destination.env, and keeps any setting in them it does not show.
Restoring databases
A restore (hitechcloudcli user-restore, a backup set, a backup job, a website import) loads each database with the account's own database login, never root: the login in the account's ~/my.cnf must be the account's own (a plain file, not a link). A my.cnf that names root (what the retired container stack wrote) or another login is refused, and the database is reported as not imported with the command that fixes it: hitechcloudcli account dbpassword <account>.
The dump is read before the client sees it, by the same rules as copying a database between accounts: only what a dump of one database writes is let through (no USE, CREATE DATABASE, GRANT, CREATE USER, SET GLOBAL, LOAD DATA, client \ commands, names in another database, or a DEFINER of another login). A dump that breaks them is refused and its load stopped before the refused statement runs. The client runs as the account's system user with --binary-mode.
Since 4.1.4 every update replaces an account's ~/my.cnf that names root or another login with one that names none (hitechcloudcli account own-db-login --all) and makes the account's own login where it has none. An own login that exists keeps its password, because an application may use it: the update lists such accounts as a warning, to be reset with hitechcloudcli account dbpassword <account>.
Runs
Raw log of every hitechcloudcli docker-backup run (/var/log/hitechcloud/admin/docker-backup.log).
Run Backup Now triggers hitechcloudcli docker-backup immediately for every user. It's only available in Admin Configured mode — in Disabled mode there's no central schedule for it to act on, since each user's own settings apply instead.