<div class="gmail_quote">On Tue, Sep 27, 2011 at 10:31 AM, Amrit Pal Pathak <<a href="mailto:amritpalpathak1@gmail.com">amritpalpathak1@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> How to take a backup of ubuntu? How to create a restore point on HD (a partition other than ubuntu 's installation) so that i can restore it when i installed new ubuntu.I don't want to install a lot of package /software again and again with each installation. </blockquote></div>There are lots of answers. I tend to use the basic UNIX tools that have been around forever, and treat this problem as no different from any other backup situation. The advantage is that the tools are robust, and will not change any time soon, and my backups are usable on just about any *N*X system. Design points 1) I have live CD's and DVD's that will boot a system without touching any of the other drives; this is crucial for restoring a broken system, either infected or non-bootable. 2) I have high-capacity "internal" drives -- 1 and 2 TB -- which I use externally in USB/SATA docks, so that I can take some of the drives off-site. That means I leave it with a friend. The off-site drive is rotated once in a while. I use internal drives because it saves a little money; you could use external drives and save some worries about their safety. 3) I mount the drive when I want to use it, and leave it offline otherwise (ideally --- in practice I sometimes leave it for a long while by accident.) 4) I copy either directly or to another system via SSH, using scripts I have written. I copy a whole directory or drive to a single file, using a tool appropriate to the situation: - dd(1) and gzip(1) for FAT partitions - ntfsclone(1) for NTFS partitions - tar -cf for normal unix directories, usually with the options --exclude-caches-under --one-file-system --exclude=.gvfs --gzip 5) In addition, some meta information is also saved (output of df, complete fdisk listings to reconstruct partions if necessary) For example, the scripts have things like fdisk /dev/sda <<EOF >/$drive/$loc/$loc.fdisk-sda-$date.txt p x p r c u p x p q EOF 6) Each file has a name with several parts, some derived from the environment, some from shell parameters - the machine name (we have 1 desktop and 3 laptops at home) - a name for the data (root, home, etc) - a date stamp - an extension indicating the format This all took a while to get going, but I'm now quite comfortable with it. It keeps logs on the systems being backed up, so i can tell where the most recent data is, as well as on the backup drives so I can see what's there. All of this is bash scripting with commands known to just about any *N*X system administrator in the last 40 years: bash, dd, gzip, tar, date, wc, test, df, fdisk, mount, umount, grep plus the somewhat newer ntfsclone My backup is then started by root: ~/scripts/bkun.sh 2tb to take a backup of all Ubuntu stuff to the drive mounted on /2tb. This mount point is bound to a specific drive UUID, so it's always the same one. The script balks if there's no disk mounted there. -- Kevin O'Gorman, PhD