|
From: Per O. <pe...@ds...> - 2004-02-25 15:43:43
|
On Wed, Feb 25, 2004 at 13:09 +0100, Szakacsits Szabolcs wrote: > Right. Here is the simplest scenario: > > backup: ntfsclone -o mybackup.img /dev/hda1 > restore: ntfsclone -O /dev/hda1 mybackup.img > > The restoration will not write the unused blocks back to the disk. Oh, sorry, I overlooked this one for some reason. It indeed writes a sparse file image reliably. > Well, there is (FIBMAP ioctl) but it's not used because it's very > inefficient. Only XFS supports this efficiently. I wrote about these in > the ntfsclone manual. Did you check it out? Yes, I did, but you only talked about efficiency. I was more interested in whether it was possible to _reliably_ detect where holes in a sparse file are located. The method above which uses ntfsclone to restore the image doesn't look at where the holes are, it reads the actual NTFS filesystem to determine which parts to write onto the target device. > What about cp and tar? They are unable to restore an _image_ to a block > device (partition), they will give an error when one tries to open the > device. Okay, I thought that they would. In principle, they should be able to write to a block device, but I assume that they won't because of some built-in sanity checks then? > And now comes the interesting part. What if you want to copy/create an > image with cp or tar with the -S option to a _file_? Can they mess up > data? The answer is again no. Both will create a new file and if they > detect there is somewhere only zeros then altough they skip that part in > the target but the filesystem will set them 0. They will be also sparse > files, no messed up data. > > I hope I could explain the issue, if not please give a specific example > when you think the process would be unreliable. This is what I thought would be unreliable: cp --sparse=always sparse-image-file.img /dev/hda1 But since you're saying that cp won't allow that, this apparently isn't an issue. > > And therefore, this use of ntfsclone is not reliable. Is this correct? > > It's not correct. I don't know many NTFS imaging softwares but I've heard > several times from several sources that e.g. Ghost can trash NTFS. > Partimage, Mondo (based on Partimage) is unreliable. I wrote about it here > longer: Note that I was referring only to this specific potential use of ntfsclone, not ntfsclone in itself. My intent was not to say that ntfsclone is an unreliable program as such. Still, there is one drawback with ntfsclone. It's not possible, AFAIK, to restore images efficiently from a pipe. If you want to put an image on a web server, or more importantly, if you want to multicast an image to many computers, you need to have some kind of temporary storage on the computer(s) you're writing the image to. I have written a utility quite similar to ntfsclone which instead of sparse files uses "sparse images" to store the filesystem. The images are stored in a special format which explicitly marks the segments of the filesystem which are unused, and leaves those out the file. With this, you can do something like: On server: ntfsimage /dev/hda1 >image.simg On client: wget -O- http://server/image.simg | simgrestore /dev/hda1 And no unused blocks need to be transferred. Unfortunately I haven't spent much time on this utility so it's still buggy, although it works on simple test cases. It would be interesting to try to integrate this functionality into ntfsclone. -- Pelle |
