8

I want to copy everything in root / to my external hard disk before I upgrade my OS so I'll have everything just in case something goes wrong. Is the following the most appropriate command for it?

username@machine:/$ sudo cp -r . /media/username/TOSHIBA\ EXT/root_copy/
Eliah Kagan
  • 117,780
scribe
  • 680
  • 8
  • 14

5 Answers5

13

To add to what P.P has said, you don't really want to copy every directory. I use tar to backup everything that I need, and "exclude" the directories I don't need. The command basically goes tar (options) BACKUP-FILENAME TARGET. If you run the following command it should do the trick.

sudo tar -cvpzf /media/username/TOSHIBA\ EXT/root_copy/root-copy.tar.gz --exclude='/mnt' --exclude='/run' --exclude='/proc' --exclude='/sys' --exclude='/media' --exclude='/dev' --exclude='/lost+found' --exclude='/tmp' --exclude='/boot' --exclude=".*lost+found" / 2> /root/tar-errors.txt

I know it looks like a lot, but tar is going to create a backup at /media/username/TOSHIBA\ /EXT/root_copy/. The file name is root-copy.tar.gz. It will exclude each of the directories that I have mentioned with --exclude, and lastly it will dump any errors that occur in a file named /root/tar-errors.txt.

Another benefit to using tar this way, is that the backup file will be a "zipped tarball". It's essentially a compressed archive so you will save space on your external drive.

I am sure there are more simple ways of doing this but I have always used this method to backup my systems.

terdon
  • 100,812
Gordster
  • 1,719
  • 5
    I also exclude /home/*/.cache, that is also several gigabytes you don't need. – Simon Richter Jul 09 '20 at 11:49
  • @SimonRichter mind explaining a little why could those be excluded? – scribe Jul 09 '20 at 22:09
  • @Gordster, when I ran this, I am getting bash: /root/tar-errors.txt: Permission denied. I did run it with sudo but it did not prompt for the password. – scribe Jul 09 '20 at 22:23
  • That will be because the redirection is running as your regular user, not with sudo. You'll need to use ... 2> sudo tee /root/tar-errors.txt (and install tee if it's not there already) – Canadian Luke Jul 09 '20 at 22:43
  • I was actually able to run sudo -i and log in as a sudoer and then cd /. After that I ran the command and it is running just fine. – scribe Jul 09 '20 at 23:05
  • @CanadianLuke Don't you mean ... 2>&1 | sudo tee /root/tar-errors.txt (includes stdout too, which I assume to be desirable)? You can't pipe stderr to a command like that. – vikarjramun Jul 10 '20 at 02:32
  • @scribe that is the per-user directory for cache files like the browser cache. Applications must expect that files in this directory go missing because a cleanup tool removes them. – Simon Richter Jul 10 '20 at 08:58
  • @vikarjramun Possibly. I don't use tee myself – Canadian Luke Jul 10 '20 at 16:15
  • @vikarjramun you can in bash if you do 2> >(sudo tee /...), but the comment was missing some syntax – D. Ben Knoble Jul 10 '20 at 16:18
  • @SimonRichter I apologize for the late response. You want to exclude those directories because they (especially /dev and /proc) contain sockets and device files that are specific to the system while it is running. In my experience while running this specific command to backup files, I only found interest in the standard errors (2>) as the errors would show me what directories I didn't have access to (as a standard user) or if the directory contained sockets that should be excluded. Scribe I apologize for not specifying that you will not be able to write files to /root as standard user – Gordster Jul 11 '20 at 07:39
9

Consider imaging the disk instead of making just a copy of files. There's more than just files that can get messed up during an upgrade: EFI system partition, boot sectors etc.

I'd recommend Clonezilla. It's user-friendly and reliable. They have their dedicated boot disk. Some rescue disks provide it too (eg. GRML) and you can install it on Ubuntu Live CD.

Clonezilla images aren't browseable, but can be used to easily restore entire disk to previous condition.

Some people could suggest using dd to create a raw image. It's also a valid approach and resulting files would be browseable, but they would take as much space as your entire partition size. Meanwhile Clonezilla uses partclone under the hood, which only copies actually used disk space and ignores free space unlike dd. Clonezilla will also compress images by default.

gronostaj
  • 720
  • 1
    +1 for suggesting Clonezilla, but I wouldn't go so far as to say it is user-friendly. An experienced computer user can handle it, but I imagine a less experienced one would find it quite challenging. – Jon Bentley Jul 09 '20 at 09:14
  • @JonBentley You're right, it's a stretch to say it's user-friendly in general, but it definitely is compared to tar ;) – gronostaj Jul 09 '20 at 12:25
8

Yes, if you want to copy everything under /, then you can do:

sudo cp -r / media/username/TOSHIBA\ EXT/root_copy/

But, before proceeding... you need to be aware that you don't really want to copy everything under / :)

You typically only need to copy your data; not all the OS binaries, installed applications, configuration files, etc. Which is what the about command would do.

If OS upgrade goes bad, it's not going to be straightforward to "copy over" everything. If you had your data, you can simply reinstall the OS and copy back the data from the external disk/medium.

Also, if you have set up other partitions than the one you have the OS installed and keep the data there, then you may not need to copy externally at all. You can keep your data in a separate partition. If the OS reinstall goes bad, you can just wipe that partition and reinstall the OS without touching the other partition where you kept the data.

P.P
  • 1,101
  • I don't exactly know where all my data might be, so I am machine gunning everything in root to an external hdd just in case. Maybe you'll be interested in answering this. – scribe Jul 08 '20 at 23:14
  • 3
    Don't copy /proc or /dev. You'll regret trying to restore those. If you don't know where your data is...then find out. This answer is very similar to the answer to your previous question. – user535733 Jul 08 '20 at 23:18
  • I am not looking to restore anything with this, I know where most of my data is and I have backed it up. Now I am just copying because why not, if shit hits the fan at least I would have somewhere to look back. I have used my system for about 5 years now. It is not possible to find out exactly what all I did and where. – scribe Jul 08 '20 at 23:25
  • 1
    @scribe But please don't copy back everything onto / even if something goes wrong. Because an OS upgrade would inevitably change a number of files/configurations. So if you "restore" everything from the external medium/USB for whatever reason, you might end up breaking it even more. – P.P Jul 08 '20 at 23:29
  • I understand that copying everything back into root won't work. That is not my intention with this. :) – scribe Jul 08 '20 at 23:33
  • 2
    To be fair to OP, I think there is a lot of missing the point here. I personally clone my hard drive before re-installing the OS. Doing so means I can simply restore the clone and I will be exactly where I started from with no need to reinstall applications and configuration files etc. which this answer rules out. If you've only copied the data, you will need to reinstall the originall OS, reinstall all the applications, re-configure everything, and copy back all the data. That's much more labour and time intensive. I agree that things like /proc are not useful here, but OP understands that. – Jon Bentley Jul 09 '20 at 09:05
  • On another note, even if we go with the "only copy the data" approach, it is incorrect to exclude configuration files from that. Configuration files are data. You can get back binaries by reinstalling the package, but you cannot get back your configuration that way. Configuration files absolutely should be included in any sane backup. – Jon Bentley Jul 09 '20 at 09:05
  • @JonBentley I am not against copying/backing up more files. That's why I said "you typically only...". If you need configuration files (or other settings) that can be your "data" too. But it's not going to be practical to keep track of various config files and/or figure out exactly which files need to be restored to old config if OS upgrade goes bad. I broadly advocate "know what you're doing". But there's no "correct" answer I suppose - it depends on the level of comfort and time one has. – P.P Jul 09 '20 at 09:20
  • @p.p "It's not going to be practical [to] figure out exactly which files need to be restored to old config if OS upgrade goes bad" - but that's exactly my point. If you simply backup everything, then you can very easily figure out which files to restore - all of them! It's only when you manually select which files to backup and restore that you have this problem. IMO a full clone as suggested in this answer is a far superior solution when doing an OS upgrade, than a selective data backup. It makes the restore process simple and quick. – Jon Bentley Jul 09 '20 at 09:22
  • @JonBentley What I mean by that is if application X is broken after upgrade, you can't easily figure out the settings needed to be restored only for fixing X as that has the potential for breaking other applications. – P.P Jul 09 '20 at 09:25
1

rsync is better IMO that tar or cp

if you have your sshkeys setup, and are going to another system: nohup rsync-r /* user@destination:/ARCHIVE_DESTINATION

else rsync -r /* user@destination:/ARCHIVE_DESTINATION

If local rsync -r /* /mnt/ARCHIVE_DESTINATION

0

I find it much easier to mount the root device on another path and then use cp (or even better rsync). This way I do not need to worry about excluding /dev/disk, /run, /proc etc.

For example:

    eval $(findmnt --pairs --target /)
    sudo mount -t ${FSTYPE} --options ${OPTIONS} --source ${SOURCE} --target /mnt/
    sudo cp -r /mnt/ /media/username/TOSHIBA\ EXT/root_copy/

The first line creates the following environment variables in my case:

    TARGET="/" SOURCE="/dev/sda8" FSTYPE="ext4" OPTIONS="rw,noatime,errors=remount-ro"

These are used to mount the root device again in /mnt. Alternatively, you can use sudo mount --bind / /mnt (I am not sure if there is a difference between the two solutions).

As others have noted, there are things in / that you may not need to backup so it would make sense to exclude them anyway. My solution is useful when you want to copy everything in the partition so you could in principle even boot from the external device (assuming efi, boot, etc are also copied / found somewhere upon boot).

Luca Citi
  • 309