Command: ubos-admin restore
To see the supported options, invoke
ubos-admin restore --help.
This command must be run as root (
sudo ubos-admin restore).
% sudo ubos-admin restore <arguments>
supports a number of different use cases:
Restore all Sites (including all Apps and Accessories contained in the provided UBOS backup file to the same configuration as at the time of when the backup file had been created. This includes Hostnames, Context Paths, Customization Points, and even SSL/TLS keys and certificates (assuming the backup file contains all of those).
Restore only some Sites contained in the backup file.
Restore an AppConfiguration that ran some App
Aat the time the backup file had been created, to an AppConfiguration running some other App
Bon the current Device. This allows migration of data from one App to another; however, it assumes that App
Bunderstands what to do with data that comes in the form App would have expected it.
Backups can only be restored to the currently available versions of the required Apps and Accessories on the current Device. UBOS does not support downgrading Apps or Accessories to older versions unless they are the current version on the current Device’s Release Channel.
During restore, UBOS generally performs the following actions:
The actual restore performed depends on the type of AppConfigItem. For example, a MySQL database will be created and imported, while files and directories are simply copied into the right place, potentially adjusting permissions according to the UBOS Manifest.
upgradersof the Apps and Accessories are run, so the imported data can be migrated to the structure needed by the current versions of the Apps and Accessories. This supports the situation where the backup was created with an older version of an App or Accessory than is currently installed on the Device and some form of data migration needs to be performed before the new version can run.
The Site is resumed, and the placeholder web page is removed.
This command internally uses a plug-in architecture, which allows the support of alternate backup formats without changing the invocation by the user.
Restoring to different versions of the App or Accessory
When a backup is restored, it is possible (likely?) that the version of the App or Accessory currently available is different (newer) than the version of the App or Accessory that ran at the time the backup was created: after all, likely some time has passed between when a backup was created and when it needs to be restored.
UBOS itself does not (and in fact cannot) migrate data from old versions of
Apps or Accessories to new ones. This is the responsibility of the
App or Accessory developer. This is what the
in the UBOS Manifest is for: run code that will upgrade the data.
Renaming retention buckets
Particular care needs to be take when an App or Accessory changes the numbers or names of its retention buckets. UBOS matches the content of a bucket by name, and does NOT restore the content of buckets whose name is not specified in the UBOS Manifest any more. Conversely, when adding an additional bucket from one version to another, the App or Accessory must be tolerant of the situation that during upgrades or restores, that bucket will be empty as UBOS cannot restore any data into it.
A good strategy for a developer is to never rename retention buckets.
Developers are encouraged to support multi-step upgrades, in which their
scripts are able to migrate the data from older versions (and not just the most recent
previous version) of their App or Accessory to the most
recent one. This enables users to restore their data even from older backups.