verified image cant be mounted

Hi there,

tib 7.0 Images of a W2K Server are made and verified regularly - so far everything is o.k.

The images are verified and said to be o.k.,
The images can be mounted on another pc,
The images can be restored on another pc,

BUT

the Source PC refuses to mount the very same tib-Image
(although tests have been successfull some weeks ago)

Does anyone have a slightest Idea what the problem could be?

Peter

 

Hello Peter,

Could be that the Acronis True Image Backup Explorer drivers (tifsfilt.sys & timntr.sys) are misbehaving/not loading. Worth doing a quick re-install of TI 7.0 onto the source PC to see if it cures the problem.

Regards

 

Hi, pniklaus

Try what as Menorcaman suggested, also make sure you have enough Free Space to mount the Image.

Take Care,
TheQuest

 

What do you mean with Free Space ? A letter from a to z not yet used for a Windows-Volume (floppy, hd, cdrom, ...) ?

 

TheQuest means that you need enough free space on your system disk to allow TI to create the mounted, virtual, partition. e.g. Say you imaged a total of 10GB of used space, then you need at least 10GB of free space on your system disk in order to mount that image.

Regards

 

At least in version 8 this is not true: I have succesfully mounted 10GB images with less than 2GB available on the system partition!...

 

Hello Roger,

Note that I did say system disk not system partition .

Regards

 

I have often wondered what actually happens when a backup .Tib is mounted. The first step seems to be that a drive letter is assigned to the image that in my case resides on a separate slave drive. My example is a 12 GB image of the 15GB main HDD. The drive letter assignment happens in a few seconds and the virtual drive can then be viewed and copied from using Explorer. I do not think that the Image is actually written to anywhere on the main system drive. My impression is that the "mounting" process merely opens up for Explorer to work within the image.
However where the image is on DVDs or CDs these have to be copied to some free space to become Mounted in the more convential sense before it can be viewed etc. in Explorer.
Does this explain the apparent differences in the thread or am I on the wrong track altogether?

Xpilot

 

Hi Xpilot,

I can mount an image that resides on an external USB drive, then switch off the external drive and still be able to explore the mounted image and copy files from it. That wouldn't be possible if TI was merely making the source image visible to Windows Explorer.

Hopefully, someone more knowledgeable about the "mounting" process than I will be able to chip in with more information.

Regards

 

Hi Menorcaman,
I have not been brave enough to switch off my USB HD while it is still in use. I always follow the safely remove hardware process as I have lots of other files on that drive which I do not want to put at risk.
I just have difficulty in taking on the idea that when the virtual drive letter is assigned, in those two seconds, the image 12GB image is copied to the main drive and expanded to its original 15GB size. I must say that is what seems to happen and it can be explored straight away however there is minimal activity of the main drive while the "mounting" takes place.

Xpilot

 

I thought that the image was mounted into ram and or into the pagefile. I think that while a small physical file may be 'issued' the rest is virtual in some way - a bit like downloading large files where a temp folder is made for parts of the file and parts are stored in temporary ram.


Colin

 

Hi Colin,

As Xpilot said, it does seem rather too quick to copy the data from the source image to another temporary partition. However, I only have 1GB of RAM and I can still mount the image even if the Pagefile has been disabled. So I wonder what's really going on .

Anyone out there know for sure .

Regards

 

Not true.

Mounting a virtual volume from a backup program requires only sufficient memory/disk space to build certain magic structures.

The files themselves are not copied to the media.

 

I've not yet tried to figure out how TI does this, but Ghost 10 creates a file to correspond to each mounted volume, I guess each file contains structures to hook into te backup file. And there's likely some stuff in memory.

 

I think you are on the right track Howard. I've repeated the test of copying files from the mounted image with the external source drive switched off and find that I can only succeed with certain, and fairly small, files. So it looks as if the disk/partition layout and directory trees are stored in RAM + Pagefile (if enabled), along with a number of files (up to to RAM + Pagefile limit) from the folder on the mounted drive that happened to be selected at the time the external drive was disconnected. If I try to copy a file that doesn't already reside in memory then the copy process hangs until the external drive is reconnected (although it tends to end with an I/O error message).

Now I wonder how much spare RAM and Pagefile capacity the original poster had on that particular problematic system?

Regards

 

Thinking about this - it would be feasible that it works this way; as Howard has just mentioned about file structures - the file structure could be loaded into ram, or copied to a temporary file on the hardrive and a ram pointer holds the location and drive letter assigned, then the imaging program of your choice (TI natch ) only needs the windows API to,

a) Find and pass to itself the ram pointer

b) de-encrypt its' image and pass it back tp the API for display in File Manager or load the file into working ram for actual access.

This would explain why you could disconnect an external drive but XP would still have the directory structure - as the file session hasn't been closed (unmounted). This wouldn't explain how you can still actually load files, unless by some chance these were files that might have been accessed before the experiment and were residing in pagefile space.

I have just experimented with this! If I open a file from the image, then after disconnecting the drive (but not unmounting it), I can still access that file - but no others.

I can unmount the file with the drive disconnected.

Colin

 

Windows has built-in support for mount manager, etc.
Being a masochist, I've recently started investigating the mechanisms used.

You cannot "disconnect" a mounted drive.
Either it's mounted or it's not.

Files do not get mounted.

Unless TI fully copies the file to a physical drive, you will not be able to access the FULL file after unmounting a drive. and, even then, to be consistent, you should not be able to access the file, or Windows should prevent unmounting whilst the file is open. Nothing else makes sense.

 

Okey doke I was a bit loose with my verbs there.

Disconnecting the drive - ostensibly removing the external drive from the system by powering it down.

File - The image file created by TI - which it mounts as a virtual/logical drive.

I can unmount the image file with the drive disconnected.

Being able to still read a file from the mounted image, after disconnecting the external drive that contains the image - this can only happen - if the file has been accessed whilst the external drive was in-situ. Either XP memory manager doesn't close the allocated ram space or the file is read into the pagefile and the filehandle is still listed in memory management so it can be reopened.

Using the MS provided ISO mounting program appears to work in a similar way - although of course the only physical drive is that upon which the ISO is lurking.

Colin

 

I think between us we have more or less cracked the puzzle of what goes on within the image mounting process. I'm not as big a masochist as Howard so it's close enough for me .

However, it doesn't solve pniklaus's original problem so perhaps it's time he popped back in and gave us some figures for free RAM and the Pagefile's free capacity just prior to his attempt to mount the image?

Regards

 

Sorry for that, Paradiseman (just love Menorca )...
Will TI use free space from just that disk or can it also use it from other disks?
Just asking as I almost could swear that sometime ago I did not have 10GB free on that disk and it did mount the image anyway...

 

Hi again Roger,

Seems my original understanding of how this mounting thing works was somewhat off (read "way off"!!) the mark . It looks very much as if the image isn't copied from the source location to any local hard drive after all (other than, possibly, to the Pagefile) but rather the disk/directory structure sits in memory (physical and virtual?) until a particular file is copied out of the image. At least, that's my inexpert interpretation of the situation .

Regards

 

Any program has a choice of using:

1. Physical memory.
2. Virtual memory in the pagefileS.
3. Temporary files wherever it wants to, usually, in the Temp directory.

The ultimate test is easy, but I've got other things to do.

a. Open a huge file, say a large (several GB) TI backup file with a programming language.
b. Read the bytes, say 64K at a time.
c. Try disconnecting the drive while the program is running.

THe proper action would be for Windoze to NOT allow you to disconnect the backup drive, no different than trying to disconnect a USB drive properly via the icon in the system tray, which cannot be done if windoze knows some program is using the drive.

Now try the same experiment with a, say, 100MB file. Such a file is small enough to copy to memory or to a page file or to a temp file. In this case, depending how the TI driver interacts with the file system, you may (or may not) be able to disconnect the drive.

It is my current (mis)understanding that Windows has File System Recognizer that knows which "driver" supports a file system. So, I'm guessing that when you access a physical drive, the file system driver used is one built-into windows, and when you access a virtual volume, there must be some well defined spec for a driver interface to make it look like its actually a native file system driver.

The details are as yet unknown, but that's really the only way it could work.

For example, when I was with DEC, we designed our implementation of ISO 9660 so that the file system thought that the drive was really a native DEC drive. THere was an interface that translated things before it got to the native ODS-2 (at that time) file system. It was a lot of work, but to the application program, a CD was no different than any other sector structured drive.

Anywho, I'm unsubscribing here, toodles!

 

Hello Peter,

Thank you for choosing Acronis Server Disk Backup Software.

As Menorcaman noticed, most likely Acronis True Image 7.0 Server drivers fail to load. If the re-installation doesn't help please submit a request for technical support. Provide the files and information collected in your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. We will investigate the problem and try to provide you with the solution.

You do not need a lot of RAM or free space on a hard drive in order to mount an image. Acronis True Image doesn't copy the content of the image file to the hard drive, instead it allows Windows to recognize an image as a volume and Windows uses its own NTFS or FAT drivers to access the image file in turn.

Here you can find Acronis True Image 9.1 Server for Windows system requirements

Thank you.
--
Anton Sherkhonov

 

Solved: verified image cant be mounted

Thanks to you, Menorcaman, a complete de- and reinstall of TI solved the problem.

Peter

 

A clarification is required. NTFS or FAT, as buil into windoze cannot directly process ANY backup program's files. tI has to supply a driver that acts asan interface.

And a file on a volume mounted from TI cannot be processed with the backup drive disconnected. To demonstate this:

1. Download http://www.standards.com/index.html?ReadFile
2. Mount a volume from TI.
3. Use the ReadFile program to read a file on the mounted volume.
4. During the read, try using th eicon in the system tray to disconnect th edrive withe backup files. Windows, correctly, will not allow you to do so.