SJ Yang Posted May 28, 2018 Posted May 28, 2018 Hi, My system has install and setting a lot, wan to read back all of from sd(8GB) card. Actually system capacity around 2GB, using windisk32 to backup image still 8GB So there any way to do image backup and capacity around 2GB. thanks
guidol Posted May 28, 2018 Posted May 28, 2018 5 hours ago, SJ Yang said: So there any way to do image backup and capacity around 2GB. Some time ago I did read about a Tool that inly do backup the used part - but I dont know the name On the other Hand you could use on another computer gparted so shrink the partition - but this doesnt help with win32diskimager or ecther The best would be a tool which do only back up the used part and after restore we do resize the partition to the new card size (not every 8GB card has the same size in bytes )
Technicavolous Posted May 28, 2018 Posted May 28, 2018 (edited) I use (g)parted to reduce the partition size before making the image. The guys who really know piping say you can pipe the output through a zip program to reduce it. Since I refuse to use x86 in my lab etcher and w32di aren't candidates any longer, want to do everything from my SBCs. If I"m going to use an x86 machine to make an image, I'm most likely to use Clonezilla, as it has the facility to reduce the image on creation. Clonezilla Image Instructions Since 2014 only makes image size of data I constantly hose installations trying different things so I've a boatload of images and ran into the same nightmare, 32gb image that has maybe 2 gig on it. Zipping is nice to save space, but the read and write time really sucks. On my XU4 I don't really care about trying to back up the boot partitions, so I don't try to image the whole disk any more. I now have the HC1 set up with OMV and back up my images there. Usually I just image the partition. Lately I've been reading about backing up without playing with an image using stuff like rsync. If I want to share a boot image with someone else then I worry about the disk image. Otherwise lately this is wayyyyy too much overhead for local backups. Now, if I could get Clonezilla running on ARM I would be a happy boy! An XU4 image that booted into Clonezilla would make this lab really productive as far as sharing images goes. Edited May 28, 2018 by Technicavolous Added info
arox Posted May 28, 2018 Posted May 28, 2018 Compress your backup ! You only have problem when you want to restore on a card with lower capacity. If this is the problem, you need [to learn] linux tools to handle linux data ! (tar, dd, losetup, fdisk, parted, mount ...)
tkaiser Posted May 28, 2018 Posted May 28, 2018 3 minutes ago, arox said: Compress your backup ! And do on the running system this prior to compressing: dd if=/dev/zero of=/lala bs=1M || rm /lala Usually reduces the size of the compressed image by magnitudes since zeroes compress better than random garbage (it's a block device that gets compressed so this does not happen at the filesystem layer --> everything that has been deleted is still there on the block device) As a side note: there are two search functions here, the search bar using the crappy/useless internal forum search and 'Google site search'. This topic has been discussed in detail many many times.
Technicavolous Posted May 28, 2018 Posted May 28, 2018 1 hour ago, arox said: you need [to learn] linux tools which is why most of us are here. So to make this more educational than admonishment perhaps a pointer or two, a link, or even a little instruction might help some others. Thanks for the tip on losetup. 1 hour ago, tkaiser said: And do on the running system this prior to compressing: dd if=/dev/zero of=/lala bs=1M || rm /lala Thanks for this, makes sense and it did make a difference for me. 1 hour ago, arox said: You only have problem when you want to restore on a card with lower capacity. In a classroom / workshop situation we have systems that participants may want to save or share with others. Having a disk full of large images is wasteful in many different resources, the small files are faster and easier to administrate. I know it gets aggravating repeating yourselves ...
arox Posted May 28, 2018 Posted May 28, 2018 "Thanks for the tip on losetup" With "losetup -o offset" (and --sizelimitzelimit if needed) you can do a resize2fs on an image disk file and truncate it (and update part table on file with fdisk). Not that easy to calculate the size for truncate -- I got 102400 too short, and I havent find why untill now. "Having a disk full of large images is wasteful in many different resources, the small files are faster and easier to administrate." "tar zcvf - . | ssh svghost dd of=/svg/svg.tgz bs=1M" is your friend "mount -o bind / /mnt" is also your friend, BUT beware of saving a running system for database constistency !
kris777 Posted June 10, 2018 Posted June 10, 2018 On a Linux system, you can backup this way ... and then reduce the image and burn to a different SD card .... I'm sorry but howto in Polish : clone SD
WarHawk_AVG Posted June 27, 2018 Posted June 27, 2018 Pishrink simple script...just take the .img file...tell it to shrink the .img and voila...compressed down sudo pishrink.sh [-s] imagefile.img [newimagefile.img] 1
kris777 Posted June 28, 2018 Posted June 28, 2018 with me the program has reduced the image from 30GB to 2.1GB ... great Theoretically, I can now burn the image onto a 3GB / ... 8GB e.t.c mini SDHC ! but the program Pishrink creates a minimal image .img ... that is, as much as there is data on it without a record what if we will install many programs in the future, etc. does not include free space for writing ...exceeding eg 2GB can not we determine the size of the created image ourselves ?
WarHawk_AVG Posted June 29, 2018 Posted June 29, 2018 I believe there is a script that will expand it back to full size of the card...the developers know what it is...run that once burned to a new card then reboot On 10/29/2017 at 8:06 AM, tkaiser said: No, since it's necessary to... Depending on the board you use and what you want to achieve different adjustments are needed before you execute the following two lines and power off the board prior to cloning: systemctl enable firstrun systemctl enable resize2fs I think that is what you do before you shutdown -h now and make the *.img (but I also believe that is for a fresh build of a brand spanking new build...not one you are cloning) at next boot...it resize the card to fill it up This in the documentation shows you can limit it if you want https://docs.armbian.com/Developer-Guide_User-Configurations/#partitioning-of-the-sd-card They would know more for sure though however, maybe they will weigh in Ah....enabling them...then shutting down, then imaging prevents the new installs from being perfect clones of the sdcard, if you were going to build an image that could be deployed to multiple but identical hardware type SBC's (actually the script looks like it checks and can patch for multiple types of cards...so it could work on multiple different SBC's) it clears configs, re-generates keys, turns on zram (if available) or a small swap file if not, turns swappiness to 0 (to lower the rate of writing to card)...yadda yadda You could manually run them I suppose If doing a "backup" then don't do the firstrun, but you will have to do the resize2fs one
kris777 Posted June 29, 2018 Posted June 29, 2018 In the Armbian system, I made such commands and the size of the image file saved on the miniSD was matched to the original size of the card :-) sudo systemctl enable resize2fs sudo update-rc.d resize2fs defaults sudo reboot or poweroff /etc/init.d/resize2fs start 1
WarHawk_AVG Posted June 30, 2018 Posted June 30, 2018 tkaiser also brought it to my attention that the pishrink.sh script builds an autoexpand image...that might now work with armbian becuase it is setup differently than rasbian There are two methods to correct this in the script itself edit should_skip_autoexpand=false to read =true or add a -s to the command string when imaging however the above commands you ran needs to follow on the new machine
Igor Posted June 30, 2018 Posted June 30, 2018 6 hours ago, WarHawk_AVG said: that might now work with armbian becuase it is setup differently than rasbian It should. Armbian can be "manufactured" and it's with a separate, FAT or ext4, boot partition on OMV. Rootfs can be ext4 or btrfs.https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-resize-filesystem
Recommended Posts