Add advice on backup of chroots to README?

[sgharms]

Seems handy.

[dnschneid]

Even better, I'd like to add the feature (along with restore) to edit-chroot. Anyone interested in implementing it?

[tedm]

What would it involve beyond the current move function in edit-chroot? compression? differential or incremental?

home directory files, or the whole chroot filesystem?

[sgharms]

The least possible thing that would work would be a wholesale copy (much like the present move) but without the rm part. That would be good enough for me. Given the warning that it could take a long time, incremental backups would probably be pretty sweet.

Since I am a very dim person :confused:, I was surprised and confused that a naïve cp -r .../.secure/precise ..../removable/SD CARD 1/precise-backup yielded a ton of scary-looking errors. If you could make that locial operation happen, without scary errors, I would be :smiley:

[tedm]

trying to tar my unmounted chroot, I get an error on this library file every time:

/usr/local/chroots/precise/lib/libply-splash-core.so.2 tar: Exiting with failure status due to previous errors chronos@localhost /usr/local $

[dnschneid]

@tedm, did you run tar as root?

[dnschneid]

As for the actual feature, it'd basically add these parameters:

-b  Backs up the chroot to a tarball.
    Compression format is chosen based on the tarball extension.
-r  Restores a chroot from a tarball. If a name is specified, restores to that
    name instead of the one in the tarball. Will *not* overwrite a chroot when
    restoring unless -r is specified twice.
-f  Tarball to backup to/restore from. If unspecified, assumes
    $NAME-yyyymmdd-hhmm.tar.gz for backups, or the alphanumerical last $NAME*
    tarball for restore.  You cannot specify multiple chroots with -f.

Additionally, if you're in / when running the command, it should assume you meant to be in ~/Downloads. tar-wise, it would be an unmount followed by sudo tar -[zjJ] -cf "$FILENAME" -C "$CHROOTDIR" "$NAME" for each chroot specified to back up. For restore, it'd be sudo tar -xf "$FILENAME" -C "$CHROOTDIR" if a name is not specified or sudo tar -xf "$FILENAME" -C "$CHROOTDIR/$NAME" --strip-components=1 if a name is explicitly specified. If the destination already exists, the tool should refuse to run unless -r is specified twice, in which case it should do a scary warning and wait 5 seconds before deleting the chroot and then doing the extraction. Whether to use z, j, J, or none of the above when tarring should be detected from the file extension (tar will auto-detect when extracting, so you don't need to do anything for that). $FILENAME needs to be properly generated as well.

[tedm]

The first couple of times I didn't, but the last couple of attempts I did run as root. In fact, when using compression ( tar -cvzf ) crosh / shell doesn't allow gunzip to work, unless you are root.

When attempting to tar the whole /usr/local/chroots dir, I got up to about a 1.3GB tar file, but it stopped before precise was completed.

I then attempted to just tarball precise and never got past the above noted error. Could it be that I am using ~/Downloads/backup as my target directory for the tarball, which, while inside the chroot, is an accessable area?

I think you've pretty much already written the tarball backup method. I looked at edit-chroot and the code for -m with a couple of edits, should do what you propose above. Should compressed tarball be an option as well?

I'll try again tomorrow, will probably make a new core chroot to minimize time, will also try to tar to sd card dest ( mmcblkp1 )

Please let me know if ~/Downloads/xyz/abc is a valid DEST source (move) for tarballs with edit-chroot -m (chroot is unmounted, of course). I'm using the stock latest edit-chroot for -m, and above attempt at using tar was just crosh / shell tar command, e.g.: $ tar -czvf ~/Downloads/backup/chrootprecise.tar.gz /usr/local/chroots/precise/

[dnschneid]

Oops, one more very important parameter for tarring up the chroot: --one-file-system. Although if the chroot is unmounted, ~/Downloads shouldn't be linked...

~/Downloads/xyz/abc should work for edit-chroot -m, although if the chroot is encrypted, you won't be able to enter it (since ~/Downloads itself is encrypted, and ecryptfs explicitly disallows nested encrypted mounts).

[tedm]

OK, I must have attempted my tar attempts (cvs, and cvzf) above with sudo, as my root (crosh / shell / sudo su #) doesn't have a ~/Downloads dir

I just made a directory from root in /home/chronos/user/Downloads/backupchroot

cd /home/chronos/user/Downloads/backupchroot

then #tar -czvf mytarfile.tar /usr/local/chroots/precise/

and got a 555MB tarball that seems valid with #tar -tvf (but I didn't extract and test).

Will try tomorrow with root tar create and extract, and edit-chroot -m with --one-file-system parameter

Am curious why sudo tar gave the errors, had plenty of space in dest.

[tedm]

My ~/Downloads is linked from within my precise chroot, but those sym links shouldn't matter if I'm running tar with the chroot unmounted, right? The links help me to keep data safe and easily delete, and recreate chroots, while keeping data safe on the Chromos file side.

[tedm]

another feature for backup could be a platform independent chroot backup, be able to move chroot tarballs between ARM and x86?

[dnschneid]

Another edge case: encrypted chroots are unlikely to be compressed at all by gzip, so the default filename for encrypted chroots should be .tar (without compression) to save time. It's probably worth confirming that the space gains are not significant.

"platform independent chroot backup" doesn't really make any sense; by definition the chroots are platform-dependent.

[tedm]

OK, that explains why -cvzf doesn't create a .gz. I'll just use -cvf tomorrow. Should #tar -cvf filename.tar in /home/chronos/user/Downloads/backupdir work specifying source as say /usr/local/chroots/ for all chroots in a single tarball, or /usr/local/chroots/precise/ for the precise directory?

Not sure what the disalllowing of nested encrypted mounts means. My chroots are not encrypted, but is the above syntax 'nesting' ?

[dnschneid]

Erm, no, that wasn't relevant to your .gz issue. You have to add '.gz' yourself. Otherwise you're just naming the file incorrectly. The -C parameter is important for your tarball to be reasonable. Check the man pages.

Don't worry about nested encryption. You'll know it when you hit it.

[tedm]

OK, thanks. What about a feature to encrypt (with password) the backed up chroot tarball and put it on Drive instead of Downloads? (or both)?

[DennisLfromGA]

@tedm - I like to use the syntax 'tar -cvaf filename.tbz2', that way tar will interpret the suffix and apply the needed compression.

[tedm]

Thanks Dennis, I"ll probably start using that as well, though today will probably just use -cvf for the best speed. It's great being able to hot key and read man pages with crouton!

[tedm]

I extracted my tarred chroot to another location, and put my local /bin tools there as well. Should I be able to run it from the backup location?

localhost local # pwd /home/chronos/user/Downloads/backupchroot/usr/local localhost local # ls bin chroots localhost local # ./startxfce4 bash: ./startxfce4: No such file or directory localhost local # ../bin/startxfce4 bash: ../bin/startxfce4: No such file or directory localhost local # cd bin localhost bin # ls delete-chroot edit-chroot enter-chroot mount-chroot starte17 startkde startlxde startxfce4 unmount-chroot localhost bin # cd ../chroots localhost chroots # ls precise localhost chroots # ../bin/startxfce4 -n /home/chronos/user/Downloads/backupchroot/usr/local/chroots/precise bash: ../bin/startxfce4: Permission denied <-- ??? localhost chroots # pwd /home/chronos/user/Downloads/backupchroot/usr/local/chroots localhost chroots #

I am root, and owner, scripts are 755 perms:

localhost bin # ls -l total 144 -rwxr-xr-x 1 root root 8146 Jun 4 09:52 delete-chroot -rwxr-xr-x 1 root root 8146 Jun 4 09:52 edit-chroot -rwxr-xr-x 1 root root 12511 Jun 4 09:52 enter-chroot -rwxr-xr-x 1 root root 10679 Jun 4 09:52 mount-chroot -rwxr-xr-x 1 root root 520 Jun 4 09:52 starte17 -rwxr-xr-x 1 root root 508 Jun 4 09:52 startkde -rwxr-xr-x 1 root root 511 Jun 4 09:52 startlxde -rwxr-xr-x 1 root root 497 Jun 4 09:52 startxfce4 -rwxr-xr-x 1 root root 8410 Jun 4 09:52 unmount-chroot localhost bin # pwd /home/chronos/user/Downloads/backupchroot/usr/local/bin localhost bin # whoami root localhost bin #

localhost bin # ls delete-chroot edit-chroot enter-chroot mount-chroot starte17 startkde startlxde startxfce4 unmount-chroot localhost bin # ./enter-chroot ../chroots/precise bash: ./enter-chroot: Permission denied localhost bin # ./enter-chroot -n precise bash: ./enter-chroot: Permission denied <-- ??? localhost bin #

[tedm]

using sudo, I can enter-chroot, but am not sure if it is original precise, or backup precise.

chronos@localhost ~/Downloads/backupchroot/usr/local/bin $ pwd /home/chronos/user/Downloads/backupchroot/usr/local/bin chronos@localhost ~/Downloads/backupchroot/usr/local/bin $ ls delete-chroot edit-chroot enter-chroot mount-chroot starte17 startkde startlxde startxfce4 unmount-chroot chronos@localhost ~/Downloads/backupchroot/usr/local/bin $ sudo enter-chroot -n precise Unknown username "dnsmasq" in message bus configuration file Unknown username "whoopsie" in message bus configuration file ted@localhost:~$ pwd /home/ted ted@localhost:~$ exit logout Unmounting /usr/local/chroots/precise... Sending SIGTERM to processes under /usr/local/chroots/precise... chronos@localhost ~/Downloads/backupchroot/usr/local/bin $ sudo enter-chroot ~/Downloads/backupchroot/usr/local/chroots/precise Unknown username "dnsmasq" in message bus configuration file Unknown username "whoopsie" in message bus configuration file -su: /home/chronos/user/Downloads/backupchroot/usr/local/chroots/precise: No such file or directory Unmounting /usr/local/chroots/precise... Sending SIGTERM to processes under /usr/local/chroots/precise... chronos@localhost ~/Downloads/backupchroot/usr/local/bin $

Instead of trying to run the extracted and moved tarball, I can try edit-chroot -m but would it be safe for me to remove the 'mv' in the -m portion of script to 'cp' and comment out the 'rm' so I can leave the original chroot there, while copying it to another location? Or would this not work?

[DennisLfromGA]

@tedm - I think you may have to specify '-c /home/chronos/user/Downloads/backupchroot/usr/local/chroots' to let startxfce4 know where to look.

Try this out and see if it works -

cd /home/chronos/user/Downloads/backupchroot/usr/local/bin
sudo sh startxfce4 -c /home/chronos/user/Downloads/backupchroot/usr/local/chroots -n precise

Hopefully that'll satisfy all the requirements and it'll open up.

[tedm]

Dennis, Thanks! That works perfectly. I have now verified that my extracted chroot tarball works in a different location. To further verify, I changed the desktop, then went back to the original /usr/local/chroots precise and opened and closed it with different wallpapers.

But when unmounting, the showing of the path, keeps me clear of what chroot I was just in. Who says you can only have one release per DE target ;)

But I wonder if there are any dangers of running chroots moved all over, would env path settings be a concern?

Unmounting /home/chronos/user/Downloads/backupchroot/usr/local/chroots/precise... Sending SIGTERM to processes under /home/chronos/user/Downloads/backupchroot/usr/local/chroots/precise... chronos@localhost ~/Downloads/backupchroot/usr/local/bin $

[DennisLfromGA]

Great, glad it worked out :-)

[tedm]

I successfully copied my chroot with edit-chroot -m to another directory. I felt safer commenting out the 3 lines below, leaving my original in place, since I have the space.

I can take a stab at the -b and -r tarball functions for edit-chroot, but it will be scary. I understand about 2/3 of what's going on here.

        echo "Copying to $target..." 1>&2
        cp -a --one-file-system "$CHROOT" "$target"

echo "Deleting old $CHROOT..." 1>&2

rm -rf --one-file-system "$CHROOT"

    else
        if ! mkdir -p "`dirname "$target"`"; then
            error 1 "Unable to create directory for $target"
        fi
        echo "Moving $CHROOT to $target" 1>&2

   #  mv "$CHROOT" "$target"
    fi

On Tue, Jun 4, 2013 at 10:44 AM, DennisLfromGA notifications@github.comwrote:

Great, glad it worked out :-)

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/190#issuecomment-18926267 .

[dnschneid]

It's probably better to fully understand what is happening before trying to modify it.

[tedm]

OK, good point.

[GirlBossRush]

I've backed up my chroot installation a few times and had no trouble extracting the archive. My only trouble is installing Crouton and sitting through an Ubuntu installation that I will toss. Maybe I'm just missing something obvious. I'd love if I could download Crouton, point to an archive and have everything install in one go. It might be better to separate the OS install process from setting up Crouton:

1. wget -O crouton http://goo.gl/fd3zc
2. sudo sh crouton install. Installed to /usr/bin/foo, file is no longer necessary.
3. crouton create-chroot ...

[dnschneid]

You can download the bootstrap stuff with -d -f bootstrap.tar.bz2 and then use it when you create chroots via -f bootstrap.tar.bz2. That should save you a chunk of time.

[dnschneid]

Now with more spinners! See if edit-chroot -b and edit-chroot -r do what you need them to do. They're pretty powerful.

[sgharms]

seems good. Thanks :+1: