Viewing 7 posts - 1 through 7 (of 7 total)
  • Linux again
  • molgrips
    Free Member

    Spent most of this week trying to get Ubuntu installed on an encrypted partition. What a nightmare. Found a great tutorial online and followed it, only to have it not work in a fascinating variety of ways, most of which involving me shouting at a blank screen or cryptic console prompt.

    Anyway, finally sorted it and I want to make sure I don’t have to do it again. Any reason I can’t simply create a tar of / and use that as a system backup? Presumably doing it in recovery mode or from a live usb would be better?

    madjak
    Free Member

    I’d boot from a USB disk and use the dd command to copy the partitions or whole disks to a file/s. You’ll need encrypted disk support to mount and read them.

    That way you can just write the whole
    partition back.

    I’d tar them as well so you can read config files if needed without faffing with crypted disks.

    molgrips
    Free Member

    I thought the tar solution would be easy – to recover, boot off live usb, set up partitions either encrypted or not, then un-tar. Would this actually work?

    Not sure about block level copying of encrpted partitions.. sounds like a recipe for failure. Plus, if the reason for restoring is forgetting my password, I’d be screwed if I only had an encrypted backup 🙂

    (of course an unencrypted backup isn’t secure, but I have a hardware encrypted USB HD to solve that problem)

    madjak
    Free Member

    Yes the taring would work to restore the file and directory structure but it would not restore the boot sectors or configure the encrypted partitions. You would need to reconfigure your boot loader and setup disk encryption.

    dd is as reliable as the hardware its running on (I find), if the machine experiences a memory parity error then corruption can occur (rare). I have used dd and netcat to restore linux systems over the network. dd will copy the boot sector and partition tables for the block device (disk) you are running it on. So if you have more then one physical disk you will need to run the command on each disk.

    tar will produce a copy of the files/directorys, some directories should be excluded, /mount /mnt /proc /sys. Permissions should be preserved when archiving and restoring (-p). Use gzip or bzip for compression (-z or -j). Run tar from single user mode.

    Run dd with ‘conv=sync,noerror bs=64k’ sync is the way dd will read the data, noerror tells it to keep going if an error occurs and pad the data out to the correct length, bs sets the block size – by keeping the size small makes the copy slower but means if an error occurs then the data that is missed is smaller, ie 64k.

    I think I’d be tempted to make regular tar backups and dd for restoring. You can restore the system with a boot usb and dd, boot the restored system and extract the tar updating the files that have changed.

    One last point, rather than just using tar if you have access to a file share you can use rsync to do differential copies, put the command in roots crontab to run when you like. rsync has enough options to do whatever is needed. Either mount the file share or send the files using ssh etc.

    If you want dated snapshots then tar the copy in the file store; tar cpvfz /filestor/backup /filestore/archive/backup-‘date –iso’

    Eveyones happy 😀

    Apologies if you know this already and to non geeks for geeking up STW……

    edit ‘date –iso’ should be in grave accents (ASCII code 96) not apostrophies but STW wont allow that.

    tightywighty
    Free Member

    Why did you encrypt the OS, not just /home?

    andytherocketeer
    Full Member

    Often specified by corporate IT security procedures.

    Full disc encryption protects around some forms of attack where the attacker has access to the machine (eg one left on a desk, one that’s been stolen, etc.)

    richc
    Free Member

    If you dd the disk you also copy the master LUKs key, which isn’t a great thing if you are using it to deploy multiple systems as if you crack a single passphrase on any machine with the encrypted header you can get into everything. So you are reliant on somebody not using a stupid passphrase and I’ve never found a way to combine cracklib with the cryptsetup tools to add a level of sanity checking to passwords.

    Personally I would also dump the original LUKs key using “cryptsetup luksHeaderBackup” so if you do forget your key at somepoint you can roll back to this and get in.

    As far as installing a full crypto disk, if you used the alternative install CD it’s an option so you don’t have to dick around with LiveCD’s etc.

    Or I could have give you a preseed file which would have made life easier….

    As for backing up your data, just use rsync and a NAS. I wouldn’t bother with the OS, as its easier to just reinstall as its pretty trivial to do once you get your preseed created.

    We deploy fully configured Linux boxes from bare metal to customer < 30 minutes, on any size disk or hardware which is much faster than pissing around with dd.

Viewing 7 posts - 1 through 7 (of 7 total)

The topic ‘Linux again’ is closed to new replies.