Tuesday 4 September 2018

Introduction to Crostini - Part 5: Backup and Restore

For the purposes of backup and restore there are conceptually five mutable artefacts: your Google account, the operating system (OS), the VM (termina), your container (penguin) and your local data. Being a device whose design in centred around the web the emphasis is to store data in the cloud (i.e. your Google Drive) with which your Google account is intrinsically linked through synchronization. Whilst some data is automatically backed up and restored through being online, granularity and control over what gets synced is also possible:


You can save and sync things like your history, bookmarks, and passwords to your Google account. That way you'll always have them on any Chromebook/Chromebox and in Google Chrome on other devices where you're signed in. Further information can be found in https://support.google.com/chromebook/answer/2914794


Also by default your account syncs the Android apps as explained under "Back up and sync your apps" (see https://support.google.com/chromebook/answer/7021273) unless your sync settings of "Sync everything" or Apps syncing is turned off. However as highlighted in "Back up or restore data on your Android device" (see https://support.google.com/nexus/answer/2819582) not all Android apps can back up or restore all settings and data and you may need to find out more about an individual Android app specifics by contacting its developer.

As Chrome OS backups your Google account to the cloud (in an un-metered area of your Google Drive) a restore is effected every time you log into a device. If it is a new device your Google account information is synced such that it is the same as on other devices or if it is the same device, prior to initiating any recovery as next described.

Chrome OS provides three options for its recovery:



Your Chrome profile basic settings will be changed to the default. This means any customisation you have made to your device with be removed including your homepage, themes etc. together with disabling any extensions you have installed. You can continue using your device with your previously configured Google account and this is a useful recovery option if apps or extensions you installed changed your settings without your knowledge.



A factory reset erases all the information on your device's hard drive including any user accounts and all the local files and makes your device start like new again. This option is called the 'Powerwash'.



When your device's operating system isn’t working properly you can recover it. Recovery is removing everything and reinstalling the OS from scratch. It involves downloading a copy of the Chrome OS suitable for your device using the Chromebook Recovery Utility (see https://chrome.google.com/webstore/detail/chromebook-recovery-utili/jndclpdbaamdhonoechobihbbiimdgai) which is stored on external media and then uses recovery mode on your device to reinstall the OS resulting in your device being like new.

Local data (see below) will need to be recovered from its backup location of either your Google Drive or from external media.

Linux (Crostini) Backup and Restore

Currently VMs/containers/data are not synced or backed up. You are responsible for any data going into the containers (see https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md#are-my-vms_containers_data-synced_backed-up).

VM

If you want to back up an individual container you can use the standard LXC commands which is the preferred method for saving the state of Crostini. The 'vmc export' command can be used to export an entire VM manually. It will dump the 'qcow2' disk image to the Downloads folder by default. However there isn't yet a way to import a VM so a backup is only useful for diagnostics (see https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md#how-can-i-backup-a-vm).


Container

At this stage in the development of Project Crostini there are two ways to backup and restore a container using LXC commands: snapshots and images.

Backup using snapshots


You can create a backup or snapshot of a container from within the VM using the command:
lxc snapshot penguin igloo

Restore using snapshots

To restore the container from a previously taken snapshot simply enter:
lxc restore penguin igloo

Alternatively you can replace the container with an earlier snapshot of it. First stop and rename the container:

    lxc stop --force penguin
    lxc rename penguin​ ​​oldpenguin


then create the replacement container:
lxc copy​ ​​oldpenguin/igloo penguin
and optionally delete the original container:
lxc delete​ ​​old​penguin
Another way of backup and restore is by using images. If you want an external copy of the snapshot backup then you can publish the snapshot as an image:
lxc publish penguin/igloo --alias eskimo
Backup using images


To backup a container using images first it is best to stop the container to create a static backup:
lxc stop --force penguin
then publish container as an image:
lxc publish penguin --alias eskimo

To make an external backup first export image as a tarball file:
lxc image export eskimo $LXD_CONF/eskimo
and optionally to save space:
lxc image delete eskimo
and then restart the container:
lxc start penguin

Now import the tarball file back into the container ready for copying as a Linux File (see below):

    ​chmod o+w $LXD_CONF​
    lxc config device add penguin lxd​_​conf disk source=$LXD_CONF path=/mnt/lxd_conf
    lxc exec penguin -- mv /mnt/lxd_conf/eskimo.tar.gz /home/linuxiumcomau/
    c​hmod o-w ​$LXD_CONF​
    l​xc config device remove penguin lxd_conf
    lxc exec penguin -- rmdir /mnt/lxd_conf​


or if the tarball file is less that the size allocated to /tmp​ ​​then it is also possible to use the following command instead:
lxc file push $LXD_CONF/eskimo.tar.gz penguin/home/linuxiumcomau/
​together with optionally ​saving space:
rm $LXD_CONF/backup.tar.gz

You can then copy the tarball to external media using the 'Files' app.

Restore using images


To restore an externally prepared tarball backup first load the tarball into the VM. Again if it is small enough simply copy the file into the container using the Files app and then:
lxc file pull penguin/home/linuxiumcomau/eskimo.tar.gz $LXD_CONF
otherwise:

​    chmod o+w $LXD_CONF​
    lxc config device add penguin lxd​_​conf disk source=$LXD_CONF path=/mnt/lxd_conf
    lxc penguin exec -- mv /home/linuxiumcomau/eskimo.tar.gz /mnt/lxd_conf/
​    chmod o​-​w $LXD_CONF


Next import the tarball file as an image:
lxc image import $LXD_CONF/eskimo.tar.gz --alias eskimo

Finally recreate the container based on the backup image:

    lxc stop --force penguin
    lxc rename penguin​ ​​oldpenguin
    lxc launch eskimo penguin

and optionally delete the image and the old container:

    lxc image delete eskimo
    lxc delete​ ​​oldpenguin

Local Data


Aligned with storing data in the cloud the 'Downloads' folder is intended only as a temporary resource for (as the name suggests) downloaded data. You can upload files and folders to Google Drive (see https://support.google.com/drive/answer/2424368) and files can also be saved and recovered to/from external media  (see https://support.google.com/chromebook/answer/1700055#save).

Android app data can also be stored in the cloud. Specifically you can save a file to Google Drive from the 'Play Files' folder using the 'Files' app or save to external media. You cab also access Android app data from 'Storage' and 'Explore' from 'Manage Android preferences'.




The 'Linux Files' folder shows your home directory in your 'penguin' container (i.e. the contents of '/home/linuxiumcomau'). Again you can backup or save a file to Google Drive from the 'Linux Files' folder using the 'Files' app or backup/save to external media. As a reminder this local data is not synced or backed up automatically and you are responsible for any data going into the container so regular container snapshots are recommended as a minimum.

Please donate if you find this guide useful using the following link http://goo.gl/nXWSGf.

6 comments:

Spirited said...

Sorry, just for good measure, but Stick STCK1A8LFC keeps going into GNU Grub rather than the Bios, is there a way to boot into the USB or get the BIOS back?

Linuxium said...

Pressing 'F2' (typically multiple times) after power-on gets you into the BIOS on the STCK1A8LFC.

Sam Colson said...

Is there a way to make a cloud backup of all data (google offers backing up only certain types of information)? It seems like some 3rd-party companies offer such thing, but is there a way to backup all device data to cloud using only Google tools?

Linuxium said...

Backup and restore is coming in Release 74 which has just hit the development channel if you are interested.

Jace said...

I was following this guide to restore an image after a powerwash and I ran into an odd error at "lxc launch eskimo penguin":

Error: Failed to run: btrfs subvolume create /mnt/stateful/lxd/storage-pools/default/images/4e1f4fa57aa56fae024823b73c5d37100d82ecbfabf64c3dd42f084be901c43e_tmp: ERROR: target path already exists: /mnt/stateful/lxd/storage-pools/default/images/4e1f4fa57aa56fae024823b73c5d37100d82ecbfabf64c3dd42f084be901c43e_tmp

I looked up this image via "lxc image list" and it turns out to be the image I'm launching.

$ lxc image list
+--------+--------------+--------+---------------------------------------------+--------+-----------+-----------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
+--------+--------------+--------+---------------------------------------------+--------+-----------+-----------------------------+
| eskimo | 4e1f4fa57aa5 | no | Ubuntu 18.04 LTS server (20181206) | x86_64 | 5527.85MB | Jun 8, 2019 at 7:23pm (UTC) |
+--------+--------------+--------+---------------------------------------------+--------+-----------+-----------------------------+

Stumped at how to proceed from here.

Linuxium said...

What does 'lxc list' show as it looks like your penguin container might already exit?

Post a Comment