Author |
Message |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 19-Aug-07 16:29
|
Frederic Thomas
Joined: 20-Jul-07 14:25
Messages: 43
Offline
|
Hello,
Does QRecall have a problem with virtual machines? See attached log, the Parallels machine fails to backup.
On a side note it would be best if one failed file did not stop the entire backup...
Filename |
QRecall.log.zip |
Download
|
Description |
|
Filesize |
3 Kbytes
|
Downloaded: |
709 time(s) |
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 19-Aug-07 17:24
|
James Bucanek
Joined: 14-Feb-07 10:05
Messages: 1548
Online
|
It shouldn't have any problems. A virtual machine is just another file as far as QRecall is concerned.
But that's not your problem. It appears that your archive has become corrupted. QRecall found an invalid checksum in the archive's data file.
First, run disk utility on your volume to make sure you don't have any cross-linked files or directory problems. Then try repairing the archive and see what happens.
|
- QRecall Development - |
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 19-Aug-07 18:23
|
Frederic Thomas
Joined: 20-Jul-07 14:25
Messages: 43
Offline
|
James Bucanek wrote:It shouldn't have any problems. A virtual machine is just another file as far as QRecall is concerned.
That's what I thought.
run disk utility on your volume
Volume header problem - fixed.
Try repairing the archive and see what happens.
Log attached. Pretty much 22GB of useless junk.
Fred
Filename |
QRecall.log.zip |
Download
|
Description |
|
Filesize |
10 Kbytes
|
Downloaded: |
667 time(s) |
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 20-Aug-07 07:46
|
James Bucanek
Joined: 14-Feb-07 10:05
Messages: 1548
Online
|
Frederic Thomas wrote:Pretty much 22GB of useless junk.
Far from it. According to the logs, QRecall found approximately 2 MB of damaged data. The other 99.992% of 12.4GB is just fine.
Following a repair, damaged and suspect files will be marked as such. If you follow the repair by a new capture, all damaged files will be recaptured. You can then merge the new layer with the damaged one and restore the archive to pristine condition.
What's odd is how scattered the damage is. Can I ask you a few questions about this archive?
Is this archive new or have you been using it for some time? If it's old, approximately what version of QRecall was used to create it?
What were the actions (if any) leading up to the one that failed?
Where is the archive stored? Are there other files/archives on this volume and are they OK?
When you repaired the archive, did you tell QRecall to recover incomplete files?
|
- QRecall Development - |
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 20-Aug-07 09:51
|
Frederic Thomas
Joined: 20-Jul-07 14:25
Messages: 43
Offline
|
James Bucanek wrote:QRecall found approximately 2 MB of damaged data. The other 99.992% of 12.4GB is just fine.
Then I guess some reserve may be needed when such an archive is displayed after "repair": -damaged- was written all over it.
Is this archive new or have you been using it for some time?
New. The first capture did not finish.
What were the actions (if any) leading up to the one that failed?
Nothing manual. I started a capture of the entire disk on a remote volume. It never finished. The machine may have slept.
Where is the archive stored? Are there other files/archives on this volume and are they OK?
OS X Server afp:// share. 288GB used out of 400 GB. After this I did run DU on it as you suggested and it repaired the volume header. As far as I can tell, all files are OK on the volume.
Note that I did try to backup on a volume mounted by an Airport Extreme and also had strange issues (see other thread). I am only mentioning it because it's again a strange issue associating QRecall and network mounted volumes (which seem to work OK for everything else).
When you repaired the archive, did you tell QRecall to recover incomplete files?
Nope, there is an option about making a copy that I did not select. I only did the backup to test QRecall in the first place. It did not capture the entire volume. So there was little value in recovering the archive.
Hope this helps!
Fred
This message was edited 1 time. Last update was at 20-Aug-07 09:52
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 27-Aug-07 11:05
|
James Bucanek
Joined: 14-Feb-07 10:05
Messages: 1548
Online
|
For what it's worth, I've been unable to reproduce this problem. I used a fairly large (~30GB) disk image file and captured it to a remote archive via AFP. It worked fine on three different tests, using a mixture of servers. One of those was an XServe running 10.3 (I don't have access to an 10.4 Xserve at the moment).
In all tests, the image was captured just fine.
Note that I did try to backup on a volume mounted by an Airport Extreme and also had strange issues (see other thread). I am only mentioning it because it's again a strange issue associating QRecall and network mounted volumes (which seem to work OK for everything else).
This is indeed odd. Several people have reported problems capturing to Airport Extreme volumes, but all of those have been traced back to problems with the Airport Extreme's handing of files larger than 2GB. I'm sure this is not the problem with the Xserve.
This message was edited 1 time. Last update was at 27-Aug-07 11:05
|
- QRecall Development - |
|
 |
|