Restore a TeamPass instance
Restore a backup and its Recovery Package on a fresh deployment. Compatible database upgrades are applied before activation.
Requires a fresh deployment, an empty dedicated database, the original Recovery Package and a complete backup. Database credentials are for the destination.
- 1. Restore database
- 2. Publish instance
- 3. Secure permissions
- 4. Finalize restoration
- 5. Cleanup, access and cron
On this server, run the following command as the PHP service account, then enter the one-hour code here.
PHP process account: noorisaeed1375.
Run this command on the server. Use sudo -u; sudo php runs as root and creates files PHP cannot read.
sudo -u 'noorisaeed1375' -- '/usr/bin/php8.4' '/home/noorisaeed1375/web/vault.saeedna.ir/public_html/app/scripts/disaster-recovery.php' --enableCommon Linux service accounts
Debian/Ubuntu: www-data; RHEL/Rocky/AlmaLinux: usually apache;
SUSE/openSUSE: usually wwwrun. A custom PHP-FPM pool can use another account; prefer the detected account above.
Step 1 — Preliminary checks passed. Run the complete command below on the server to restore, upgrade and verify the database. Wait for it to finish, then click Refresh progress.
Run the complete command below in a terminal on this server as
noorisaeed1375.
Keep the sudo -u prefix shown in the command; sudo php runs as root.
Encryption verification
The restored TP system private key cannot be used. The original master key matches the database, but item decryption could not be verified with the system key. Users' existing sharekeys are preserved and may still provide access. After restoring access, review the TP key repair in Tools and each owner's personal-item repair.
After the terminal reports that the database is verified, click Refresh progress to display the activation command. TeamPass stays in maintenance until the final operational checks are acknowledged.
The instance is published, but private staging cleanup has not been confirmed. Correct the terminal diagnostic and run the activation command again to finish cleanup before continuing. Do not discard this completed publication.
A stopped recovery can retain the database password in job.json,
the original key and decrypted staging files in its private job directory.
Keep them restricted to the PHP service account while investigating.
If you abandon this job, remove its staging with the command below.
This does not reset the destination database or remove files already published.
Files you placed in storage/recovery/incoming/ and private CLI request files
are not removed automatically. Preserve the encrypted backup and Recovery Package securely outside
the deployment, then remove their staged copies and any request containing credentials.
3. Secure file permissions
Publication automatically audits permissions using the File integrity rules.
No audit result is available yet. Run this fallback command, then click Refresh progress.
Review and copy this single block into your server terminal as an administrator. It applies the proposed rights and automatically runs the audit again as the PHP service account. Code, configuration and the original master key are protected; runtime data stays writable by PHP.
Wait for the block to finish, then click Refresh progress. Exit code 2 means permission findings remain.
Automatic remediation is unavailable for this platform or layout. Review the OS permissions/ACLs manually: PHP needs read access to code, configuration and keys, and write access only to runtime directories. See the permission documentation.
4. Finalize restoration
After reviewing permissions, run this command, wait for it to finish, then click Refresh progress.
Keep cron stopped until the installer is removed and access checks are complete in the next step.
Backup schedules and LAPR stay disabled until you review and enable them deliberately.
5. Cleanup, access checks and cron
Successful publication removes the job's sensitive staging and keeps a non-sensitive receipt.
Files you placed in storage/recovery/incoming/ and private CLI request files are retained.
Preserve the encrypted backup and Recovery Package securely outside the deployment,
then remove their staged copies and any request containing credentials.
5.1 Remove the installer
Run this command as an administrator to remove public/install and allow application sign-in.
Keep this page open for the instructions below; do not refresh it after removal.
5.2 Check the restored instance
Open TeamPass in another tab. Verify administrator and standard-user sign-in, HTTPS, the URL, decryption, personal folders, manager/read-only permissions, documents, MFA and external authentication. Reconcile external integrations and offline clients.
Open TeamPass login5.3 Restore scheduled processing (cron)
After the access checks, restore the host scheduler. The recovery hold is released, but restoring a database does not recreate a host cron entry. Review enabled tasks first; backup schedules and LAPR require separate review before enabling them.
Open the crontab for the PHP service account. Preserve other jobs and keep exactly one active TeamPass scheduler entry.
sudo crontab -u 'noorisaeed1375' -e
Insert or uncomment this line in the crontab editor, then save. This is a cron entry, not a shell command:
* * * * * '/usr/bin/php8.4' '/home/noorisaeed1375/web/vault.saeedna.ir/public_html/app/sources/scheduler.php' #Teampass scheduler
Restore the cron daemon or equivalent scheduler with your server's service manager/runbook.
After a minute, check the last cron execution and task results in TeamPass administration. See the scheduled tasks documentation.