[SOLVED] Using tar to cold backup the root file system - strange error
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Using tar to cold backup the root file system - strange error
My normal method to do a cold backup of the root fs is with Clonezilla. The only downside is that Clonezilla will not write an image to a smaller drive - even if there is plenty of room for the files.
I am playing with a couple of Raspberry Pi3 computers. They use a microSD card as their "hard drive." Rather cool. Problem is... all 16GB microSD cards are not the same size. Even a few KB difference will prevent Clonzilla from moving the OS to a smaller card. So...
I have figured out the necessary switches to allow rsync to copy files to a smaller microSD card (once it is properly partitioned and formatted.) I decided to give tar a try - just for the heck of it. In this case I am attempting to write a tar file from a microSD card mounted in my CentOS 7 workstation.
Code:
[ken@taylor20 Desktop]$ sudo tar --acls -cpvzf /xtra/store_root/pi_root.tar.gz /run/media/ken/PI_ROOT
[sudo] password for ken:
tar: Removing leading `/' from member names
/run/media/ken/PI_ROOT/
/run/media/ken/PI_ROOT/tmp/
/run/media/ken/PI_ROOT/tmp/.ICE-unix/
/run/media/ken/PI_ROOT/tmp/config-err-U5UlJ9
/run/media/ken/PI_ROOT/tmp/.X11-unix/
/run/media/ken/PI_ROOT/tmp/.XIM-unix/
/run/media/ken/PI_ROOT/tmp/.Test-unix/
/run/media/ken/PI_ROOT/tmp/.font-unix/
...
/run/media/ken/PI_ROOT/dev/fd/3/tmp/.ICE-unix/
...
/run/media/ken/PI_ROOT/dev/fd/3/dev/fd/3/dev/fd/3/tmp/.ICE-unix/
...
Segmentation fault
The errors which I captured show
Quote:
tar: Removing leading `/' from member names
tar: /run/media/ken/PI_ROOT/tmp/.ICE-unix/1290: socket ignored
tar: Removing leading `/' from hard link targets
tar: /run/media/ken/PI_ROOT/dev/fd/1: file changed as we read it
tar: /run/media/ken/PI_ROOT/dev/fd/3/tmp/.ICE-unix/1290: socket ignored
tar: /run/media/ken/PI_ROOT/dev/fd/3/dev/fd/3/tmp/.ICE-unix/1290: socket ignored
tar: /run/media/ken/PI_ROOT/dev/fd/3/dev/fd/3/dev/fd/3/tmp/.ICE-unix/1290: socket ignored
tar: /run/media/ken/PI_ROOT/dev/fd/3/dev/fd/3/dev/fd/3/dev/fd/3/tmp/.ICE-unix/1290: socket ignored
It appears that I have some sort of recursive mischief going on. This started when I added the -h option to attempt to preserve links. However, it seems that I am trying to save the files linked to (according to the man pages.)
My question is... How do I save the LINKS so that they will be restored to my cloned "hard drive" and used when the Pi boots?
Have you thought of using fsarchiver? Unlike clonezilla, it only copies the occupied part of the disk. I have used it to move filesystems to partitions that were not the same size.
I am running Ubuntu Mate 16.04 and 18.04. I think I will try tar without the -h and see if links are in fact added to the tarball by default. I spent two days figuring out that I needed to add -A to my rsync command. It worked, the Pi booted but I could not mount a USB flash drive. Seems that /mount/ken had an ACL set. When that was not present I could not mount the flash drive
Thanks hazel,
I will check out fsarchiver. It is always good to have more tools in the toolbox
I did a tar without the "a" option and it seemed to work OK. At least no errors. When I did an un-tar I found that the permissions do not carry forward as they should. Here are my commands
Quote:
sudo tar --acls -cpvzf /xtra/store_root/pi_root.tar.gz /run/media/ken/PI_ROOT >> run.log 2> errors.txt
sudo tar --acls -xpvf /xtra/store_root/pi_root.tar.gz -C /
When I examine the resultant file system I find for example that /home has the permissions
Code:
drwx------. 3 root root 4096 Nov 21 18:40 home
which should be something like
Code:
drwxr-xr-x 3 root root 4096 Sep 9 14:50 home/
Obviously the users will not be able to access their home directories
Oh never mind - but this is rather interesting! I was writing this post as the process was running. I was viewing the / directory of the target file system. As the process completed I observed the little [x] symbols disappear from the various directories. I can now access my home directory and files. Perhaps restoring permissions is a final step to the un-tar process?
My normal method to do a cold backup of the root fs is with Clonezilla. The only downside is that Clonezilla will not write an image to a smaller drive - even if there is plenty of room for the files.
I am playing with a couple of Raspberry Pi3 computers. They use a microSD card as their "hard drive." Rather cool. Problem is... all 16GB microSD cards are not the same size. Even a few KB difference will prevent Clonzilla from moving the OS to a smaller card. So...
I have figured out the necessary switches to allow rsync to copy files to a smaller microSD card (once it is properly partitioned and formatted.)
May I ask what file system? Since you are already partitioning and formatting the microSD card, why not just use dump/restore or xfsdump/xfsrestore (depending on filesystem)?
That causes tar to make a copy of the original file, not the link. In a restore the file would be copied back.
As for keepting the owners and such - I use "tar --one-file-system --selinux --acls --xattrs -z" to create the backup.
Then use the --same-owner (which is the default for the super user).
The --selinux --acls and --xattrs are because they are used on Fedora/RH kit, so they need to be preserved. The --one-file-system is to prevent tar from walking into other mounted filesystems.
segfault is caused because of the loop. As you see there is a symbolic link which will make a recursion. It will cause a variable overflow inside tar and finally a crash. You need to avoid following those links.
Thank you jpollard - that did the trick! I tar(ed) the root partition from a microSD card, deleted all files from that partition and (un)tar(ed) the files back. The microSD card successfully booted the Pi and it seems to be working fine. As to the -h. I did not want to follow the links, just to save them to the tarball. I have a working recipe now.
Thanks pan64, I realize that the segmentation fault was caused by the looping until tar exploded or imploded or whatever. Again, I did not want to follow the links, just save them. My bad.
Thanks dc.901,
The partition is ext4. I will look into dump and restore. It is always good to have options.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Kernel panic. Missing links perhaps?
I tar(ed) the root partition from a microSD card, deleted all files from that partition and (un)tar(ed) the files back. The microSD card successfully booted the Pi and it seems to be working fine. As to the -h. I did not want to follow the links, just to save them to the tarball. I have a working recipe now.
