(guía en español aquí: http://www.espaciolinux.com/foros/po...2.html#p244542 )

Well, this is a rather noobish thing to do, because it's not actually a question but a little guide I came up with and want to share in the spirit of open-source software. Recently I developed a way to make my own system restore under linux using partitions, and well, I guess I might as well share it because it's been so useful to me.

After some constructive criticism on behalf of LQ this is the result:

Ok, this guide is a little sketchy and it is actually more of a guideline. It is intended to be adapted by anyone who uses it and it might require some trial and error if you are a beginner, but once you get the hang of it it can prove very handy. I strongly recommend you read the whole guide and all the suggested material before you try anything. Also, reading the entire thread might help you understand how the whole idea evolved.

This is a procedure to make your computer restore it's self in case a virus attacks. You have to know how to install operating systems, mainly windows and linux, some stuff about the linux shell and how to partition hard drives.

Well, this is it without much detail:

1. Partition your hard drive in 4 parts: Their sizes will depend on the total disk space available in your hard drive. You can use this formulae to get the correct size of your partitions:

sda3size = ((totalhdcapacity-swapspace)/3)+sizeofyourdistroindisk
sda4size = swapspace
sda1size = (totalhdcapacity-sda3size-swapspace)/2
sda2size = sda1size

where

totalhdcapacity = the total space available in your hard drive
swapspace = the space you want to leave for the swap partition of the os you are going to install in /dev/sda3 (see step 5)
sizeofyourdistroindisk = the size your minimal linux distro will occupy in /dev/sda3, for example, around 50mb (preferably more) for dsl or around 30 mb (again, i recommend you use a bigger number) for slitaz.
sda1size = size of /dev/sda1 partition
sda2size = size of /dev/sda2 partition
sda3size = size of /dev/sda3 partition
sda4size = size of /dev/sda4 partition

It would be good to point out that, instead of using a whole partition for swap (sda4) you could have only 3 partitions, and use logical partitions to establish swap space in sda3. Ofcourse you would have to calculate the formulae for that on your own. In other words: this method is but a recommendation, partition as you see fit. One important thing you should remember though is to keep

sda3size > sda1size + sizeofyourdistroindisk

It is important to remember that if you are using an IDE HD instead of a SATA HD, the file names of your partitions will be /dev/hdXN instead of /dev/sdXN.

2. Format sda1 as NTFS, sda2 as NTFS, sda3 as ext2 or 3, or whatever you want to install linux in and sda4 as linux swap. Again, use fdisk and then mkfs, mkdosfs or any other tool to do this. If this doesn't work you can do this from windows after you install it, or if you install linux, from linux. If you are installing linux in /dev/sda1 instead of windows you might want to make the necessary logical partitions first and format as you see fit. This step, too, is open to your modifications.

3. Install your favorite windows (or linux, in which case you will want to use logical partitions for swap so that you keep everything in one big primary partition. This will be important later on) on sda1. A windows installation disk will probably call this particion C: during installation, so just install in C: if this is the case. You may also install a mac os or any other OS you like as long as it's in /dev/sda1 and as long as it is bootable by grub.

4. Install all the programs you want in your OS. Don't connect to the internet yet, as you might unknowingly infect this partition and make it impossible to restore a healthy partition in the future.

5. Once you have installed something in C: (sda1) install either Damn Small Linux (DSL), SliTaz or any other minimal linux distro that has dd and/or gzip/zcat, in sda3 and use sda4 as swap for this installation. Consult the DSL/SliTaz/etc website to find out how to do this. Choose grub preferably as your boot loader.

6. When you are done, enter DSL/SliTaz/etc from grub and enter this command:

This compresses all the bits in sda1 (where you installed your system) and stores that in sda1.img.gz. This file is what you will use to restore your system when it crashes. By the way, this might take from a few minutes to a few hours, depending on yout HD size and computer speed.

You may also use

in case you don't want to compress. It's your choice. The point is to have the binary sequence of /dev/sda1 available for later recovery.

7. To restore your system, back all your precious files up in sda2 (drive D: or E: or whatever) and simply enter DSL/SliTaz/etc from grub again, but this time, use the command

This will restore the system you installed on sda1 ( C: ) and leave it the exact same way you left it in step 3. This, too, might take a long while.

In case you used dd instead in step 6, you will have to use

to achieve system recovery.

There are some very useful guidelines for using dd here, I recommend you use them when adapting this guide to your own needs. And as a side note, dd is probably much faster than gzip/zcat, since it doesn't deal with compression.

8. One crucial thing to remember is to always keep a backup of your MBR and a copy of DSL or any other distro so you will be able to reinsert/reinstall grub in case it stops working. Error 13 can be a real headache. There are many guides online on how to reinstall grub or on how to simply use dd to recover your original MBR.

The next thing to do would be perhaps to write a script that would do the system restore automatically when DSL boots and also to change the grub menu so that it will show the booting option of sda1 (whatever you may call it) in the first place of the list and "System restore" in the second place, and program it with a waiting time lapse of 2 seconds or so. Again, this is beyond the scope of this guide and I recommend you adapt this part on your own, there are many tutorials on how to configure grub out there.

Read the rest of the posts for more details on what is happening here, especially posts #4, #8 and #10. Thanks to all who posted, especially silvyus_06.

And well, to keep this official, I guess my question would be: can you think of ways to make this guide better? do you think it is worthwhile? It is important for me to receive your criticism so that I may improve this guide.

Thanks for the attention and I hope this helped!

EDIT: I attached an image which illustrates the procedure above in a simple manner.

EDIT: BTW, what is written below is the original post, before all the editing. It might help you understand some of the posts and criticisms in this thread.

This is a procedure to make your computer restore it's self in case a virus attacks. You have to know how to install operating systems, mainly windows and linux, some stuff about the linux shell and how to partition hard drives.

Well, this is it without much detail:

1. Partition your hard drive in 4 parts: three of the same size and one of 1 GB. To do this you can substract 1 GB from your total hard drive space and divide the result by 3, and then y use some tool like cfdisk or gparted to make the partitions. We will call these sda1, sda2, sda3 and sda4, where sda4 is the 1GB partition. In your computer these might be called hda1, 2, 3, 4, if you are using an IDE HDD instead of a SATA one.

2. Format sda1 as NTFS, sda2 as NTFS, sda3 as EXT2 or 3, or whatever you want to install linux in and sda4 as linux swap. Again, use fdisk and then mkfs, mkdosfs or any other tool to do this. If this doesn't work you can do this after you install windows.

3. Install your favorite windows (or linux) on sda1. A windows installation disk will probably call this particion C: during installation, so just install in C: if this is the case.

4. Install all the programs you want in your installation. Don't connect to the internet yet, as you might infect this partition and make it impossible to restore a healthy partition in the future.

5. Once you have installed something in C: (sda1) install Damn Small Linux (DSL) in sda3 and use sda4 as swap. Consult the DSL website to find out how to do this. Choose grub preferebly as your boot loader.

6. When you are done, enter DSL from grub and use this command:

sudo gzip -c /dev/sda1 > ~/sda1.img.gz

This compresses all the bits in sda1 (where you installed your system) and sotres that in sda1.img.gz. This is what you will use to restore your system when it crashes.

7. To restore your system, back all your precious files up in sda2 (drive D: or E: or whatever) and simply enter DSL from grub again, but this time, use the command

sudo zcat ~/sda1.img.gz > /dev/sda1

This will restore the system you installed on sda1 (C and leave it the exact same way you left it in step 3.

Attached Thumbnails

   

Nice little guide, I only have one suggestions: I think that it is totally overkill to set up a third of your disk for such a small system like DSL, especially with modern harddisks in TB-size. It should be possible to install it in much less space.

1 members found this post helpful.

oh yeah it's a good guide . maybe you could make it better by also saying in it what the arguments for the commands you used do .. especially after gzip , what does the -c option do ? thanks

1 members found this post helpful.

Well, the thing is this... the whole purpose behind setting aside 1/3 of your HD for DSL is to leave enough space for the compressed disk image that you are going to create. That is so because this command

has the purpose of taking whatever binary sequence you created in your C: drive (that is, /dev/sda1) after you installed windows (or whatever you may have installed in it) compressing it, and storing that compression in the file called ~/sda1.img.gz. The "gzip -c 'file'" part outputs the compression of 'file' to stdout and "> '/path/filename'" redirects this output to a file called 'filename' in the path 'path'.

So let's say you have a 120 GB hard drive, you will want to have a 40 GB partition with windows in it, (which linux knows as /dev/sda1 and simply treats as a file, which is nothing but a long array of 0's and 1's ), another 40 GB partition for making backups of your files (/dev/sda2), the third 40 GB partition (/dev/sda3) which will have DSL installed, which you will use for storing your compression of /dev/sda1, which we will call ~/sda1.img.gz, and last but not least, /dev/sda4 which will be the much needed swap partition for your DSL installation.

The thing is that when you use the "gzip -c /dev/sda1 > ~/sda1.img.gz" command under DSL, what you are doing is taking /dev/sda1, which is a file 40 GB long, compressing it, and saving it in ~/sda1.img.gz inside /dev/sda3, which is where you will be running DSL. I came up with using DSL because it's a tiny distro (just 50 MB), and since most of the partition's space will be used by ~/sda1.img.gz, it seemed the most practical thing to do.

The problem is, ofcourse, that the compression rate provided by gzip can be very low and unpredictable. For example, with the 40 GB example from before, I've had the experience of getting around (40GB)*60% to (40 GB)*80% compression rates , so this is why you need 1/3 of your hard drive with a DSL system to make sure that your ~/sda1.img.gz will fit in. And now that I think about it, the correct size of the DSL partition should be something around ((HDSIZE-1GB)/3)+100MB (where 1GB is the size for sda4 swap and 100MB is a comfortable size for DSL), so that we can be absolutely sure that (even with a very low compression rate like 99%) ~/sda1.img.gz will fit in. sda1 and sda2 would have the size of the remaining space divided by 2, of course, and sda4, well, 1GB, or whatever you want swap to be.

This is very effective because it keeps any data you may have in /dev/sda1 safe under an ext2 or ext3 filesystem, which is invulnerable to virus attacks as long as you don't mess around with it and only use windows. This is so because windows doesn't even detect ext3/ext2 (at least windows xp, which is when I stopped using windows, so I don't know if, say, vista or 7 know about it).

And ofcourse, the step where you

is where you take the compressed file, output it's decompressed form to stdout and redirect that decompression, bit by bit, into /dev/sda1, where it will restore your windows system as it was when you gzipped it into ~/sda1.img.gz. As you can see, the files in /dev/sda2 remain untouched and this is how you can have your very own, relatively secure, free system restore with any OS of your choice.

One crucial thing to remember is to always keep a backup of your MBR and a copy of DSL or any other distro so you will be able to reinsert/reinstall grub in case it stops working. There are many guides online on how to reinstall grub or simply use dd to copy it raw into your MBR.

Now that I have come to think about it, I would appreciate some advice regarding filesystem compression and storage, because gzip just isn't doing it for me. A while ago I tried to develop my own NTFS compression algorithm but it implied investigating the inner working of NTFS throughly and I don't have the time to do that, also, the only things I found out about NTFS were in some crappy books by M$ which didn't explain well enough how NTFS works. The alternative would be to take a look at the libraries linux uses to handle NTFS, but I don't yet read code that well, so I suppose unless you guys make a good suggestion to me on how to get higher and more predictable compression rates for a windows partition, this project will have to wait for improvement.

Thanks for reading and posting btw, It's great to know it intrested you guys

well, as you say , that gzip treats the ntfs as a big huge 40GB file , then , this method isn't really useful since you would get a file around 20-30GB even when compressed , though , say you only use like 10GB of the partition .

Your best bet is to find out some command to read the filesystem and then compress only what the file system contains .

Anyways , why is this guide windows centered in the linux forums ?

And also, maybe you can learn something from partimage or clonezila

they read and compress the file system . perhaps you may find out what command line programs they use to do that.

1 members found this post helpful.

As a one time system restore, it's nice, but unfortunately impractical if you want regular updated system images. (too slow, and no method to do incremental changes) If you don't keep it current, there's not that much advantage over a reinstall of the OS the traditional way, then reapply the patches.

1 members found this post helpful.

I will check on that, thanks for the tip!

Oh, well, yeah, ofcourse it's intended for that, actually I took the idea from an old IBM T43 I used to have that had the system restore option, ofcourse the windows XP system was much better compressed there than in my procedure.

And, well, you see, the point of using gzip would be more of a versatility issue, because with this procedure, you can back up not only windows os partitions, but also mac os and even linux ones, or actually any OS in the world! without having to know the exact algorithms for compressing every single filesystem type known to mankind, as long as grub or lilo can handle the booting, of course. And also, you can update your ~/sda1.img.gz anytime you want, but the point would be to have a virginal, untouched-by-the-internet system, so yeah, it has it's advantages and disadvantages.

And also, it is more hands-free than re-installing your OS and all your software, you know, the usual headache of having to sit there for two hours and all... Heck, I think it's even less time-consuming in some cases!

what about bzip2 . or perhaps 7zip , but it's too slow , i think .

1 members found this post helpful.

I haven't tried those but feel free to hack at will, maybe when I have some time I will look into it, I'm a little busy currently reading "The C programming language, 2nd ed." so maybe some other time.

I was actually thinking of using dd instead of bzip2 because it probably won't take as long as bzip2 (or gzip) since it doesn't compress anything, it only copies bit by bit what is recorded in /dev/sda1. For example, something like

would create an exact copy, bit by bit, of /dev/sda1 into ~/sda1.img, and since the space in /dev/sda3 would be just enough to store it, it is possible. Maybe you could instead just buy an external hard drive with just as much storage capacity as your PC hard drive so that you may have sda1.img stored there in case of an emergency. Oh well, I don't know, there are many approaches to this problem. I suppose the ideal thing would be to have some sort of freakishly fast hard drive you could read and write ridiculous amounts of bits to in parallel, I could certainly find some uses for a device like that, for say, decrypting M$ files at top speed or, I don't know, stuff.

Anyway, thank you for your comments, you've been very helpful.

if you want to use dd , ashis nekhra once directed me to this blog.

he says that perhpas making with dd a big huge file to occupy all the free space left on the partition and then delete it.

then using dd +gzip make the copy to the new partition (it will write zeroes , and then gzip will compres those zeros to almost nothing , while compressing the actually used space )

nice useful guide. you should read it.

1 members found this post helpful.

Useful complement. You're right, you should probably add some extra parameters to dd to make it safer, like point 5 in that page you just posted, it might also be a matter of reading the dd man page throughly. Maybe you would prefer to dd into a file, if you want to move it around, split it in parts, analyze or do as you please with it.

Oh, and I didn't get your initial point, sorry. Yes, I belive making the big file with dd, and then compressing it with gzip would have the same effect as using "gzip -c /dev/sda1 > ~/sda1.img.gz", because gzip -c /dev/sda1 outputs, bit by bit, the resulting compressed file into stdout, which you then redirect (that is, write to a file) with "> ~/sda1.img.gz". It's worth trying both methods on a smaller file though, just to make sure you get the same result regarding compression rate, or even reading the source code of gzip. Not sure if this is what you ment, though.

BTW, FYI, fat16 and fat32 have a very low maximum file size, I think it's around 6GB or something, so, you might want to use NTFS, or some ext for backing up large files.

i knew it's 4Gb.

maybe using the filesystem that uses the lest disk space for itself . for example : fat16 uses 256KB for itself ,then comes fat32 which uses 7Mb .. see the pattern .. they all grow when they make out a new version . So it's best to use something like ext2 , if you aren't gonna touch that partition too much.

sure, sure, and also to keep the initial functionality of making the backup partition invisible to windows and thus relatively secure. I edited that last post btw.

and if you want to save disk space , why not try SliTaz .

but in my opinion , it is a basically good idea to also include the OS on the backup partition , that way, even if you don't have a live cd or live usb available , you can always boot to that untouched partition to restore.

perhaps , trying all these commands by doing them to a linux live cd (any , preferable to be big ~700MB ) so that you get an idea about the compression rates .

Maybe you're going a bit too far by reading the gzip source code , since you don't really need it . perhaps , reading the manpage , which would input alot of other useful info on what to add to the command in different situations.

as a last thought . it would be good to also add a boot manager to all this guide , and making slitaz boot directly from the iso located on the hardrive . and give it like 2 seconds before booting to default.

or you might want to install puppy linux with it's frugal install to the harddrive (which will use more space though)
but in it's menus it also has a option to use dd to make a backup of the drive. And maybe from that file , you can start compressing , or leave it as is , because anyways , since you will be making the partition for backup the same as the source one .

And if you leave it as is , you might also get faster restoring process , since it wont have to extract anything.

1 members found this post helpful.