kevinflynn

no problem. I wouldn't say I didn't know what I was doing at all. Just that the utility was all I had that would work. The restore process was somewhat convoluted but I figured it out "restore disk" is the TARGET and archive disk is the SOURCE. Either way I got it to work. Now my only challenge is to get it to boot. The files are all there but it didn't backup the boot partition just the primary NTFS one. Not a big deal at all. What this boils down to is if it were some regular laptop like a latitude and had a built in CDROM drive I'd never even had to have posted here! Turns out the stupid llaptop is really weird. It's BIOS is not PE friendly at all. The CSM mode and the USB ports are not compliant. Essentially what happened was the left USB port would not show any devices connected. What tipped me off is when I switched the USB HDD and the USB CDROM (because this piece of garbage has no CDROM) then TRK could NOT BOOT!!! It wouldn't see the CDROM drive once the kernel was loaded. So I went to my trusty dell and restored to a brand new HDD just fine. I am about 90% there. What I will do is take my good HDD which has windows 7 on it already, and boot to falcon and copy all of the files over from my image. After that I should be good. I will let you know the outcome. So none of this was UNPI related it was because the system in question is junk. When I tried on my dell it worked perfectly first run.

I normally just use Falcon and Ghost. This was the closest I could find without really knowing anything about it or having any prior experience. I was wondering why it was called PI. I am hoping to god that it being specific to raspberry pi that it is capable of doing what I did. Either way, the restore process is not as comprehensive as the backup process was.

The total size of the backup is 107GB. Oh to clarify and be specific to answering your questions... 1)Taget laptop 900x samsun 250GB SSD HDD 2)Destination was a USB 2TB connected to the same system. The backup was of the entire PC to a folder and subsequent spanned 2GB files. it totaled 107GB The output folder was "BACKUP" inside were the following: FOLDER: 2017-12-22-DIR-sda2 Root: FIle: partition-info.txt File; pi.cfg Inside folder: FILES: 2017-12-22-I-sda2.000 through to 2017-12-22-I-sda2.054 Presumably the actual backup data itself.

Yes that is a correct assessment. Sorry if this was not clear before.. Scrambling for a solution to get this re-imaged to the new PC. It's an executive's laptop! :S I know a lot of people may be wondering why.. I had an extreme time crunch. NONE of the boot PE environment discs would be able to see the internal HDD. This is one of those new laptops that has a very funky drive type and controller. Similar to when SATA came out and none of them could read the drives. Later they baked in a layer which would be able to do UEFI and the like. As far as this system is concerned I do not know the specific drive type but it's an "SSD" although it really isn't it's just a proprietary RAM stick in a socket that may be standardized. It shows as SATA in bios but we know that cannot be the case as it's not compliant at the bios level. Only at the OS layer. The hardware controller and BIOS are obviously able to see the drive at this pre-boot state however utilities cannot. TRK was the ONLY utility that I tried out of 8 which could see the drive. Falcon Four System Rescue Bart WinPE and a few others could NOT. So I know you're wondering why I'd use TRK or PI to do this backup but literally it was all that was able to see the drive. It's a Samsung 900x laptop with a 128GB drive the source was the same but a 250GB drive. Here's the partition info txt file: Disk /dev/sda: 256.1 GB, 256060514304 bytes 255 heads, 63 sectors/track, 31130 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xba2c4f98 Device Boot Start End Blocks Id System /dev/sda1 * 1 13 102400 7 HPFS/NTFS Partition 1 does not end on cylinder boundary. /dev/sda2 13 28950 232429568 7 HPFS/NTFS /dev/sda3 28950 31131 17525760 27 Unknown Disk /dev/sdb: 2000.4 GB, 2000365289472 bytes 256 heads, 63 sectors/track, 242247 cylinders Units = cylinders of 16128 * 512 = 8257536 bytes Disk identifier: 0x16f2a91f Device Boot Start End Blocks Id System /dev/sdb1 1 266306 2147483647+ ee GPT and the config file: PI.CFG: # No space before and after the = sign # The names are case-sensitive # No backslashs: \, only slashs/ # Destination backup unit. It may be a network drive, for example: # BACKUPDRIVE =//192.168.1.4/pibck # In this case the parameters LOGIN and PASSWORD are required # Or a local unit such as BACKUPDRIVE=/sdb1 BACKUPDRIVE=/dev/sdb1 LOGIN= PASSWORD= # Backup directory DEST=BACKUP # Partitions to backup # If there are multiple partitions, separate them by spaces, # and put it between quotation marks # Example PARTITION = "sda1 sda5" PARTITION="sda2" # If AUTO=1 and a pi.cfg configuration file was found # the backup is done without any user intervention AUTO=1 KEEP=2

What if it is a Windows 7 notebook? samsung 900x my main goal is to restore this to another drive

This is a laptop with an SSD, not a Pi will this work? also I had thought it was ok because the back up size was 107GB and the dest drive is 128gb

Any help at all is greatly appreciated. Thanks in advance!

Hello to all. I am hoping someone may be able to provide some insight on an item within TRK which is extremely vague and unsupported. There are these utilities which will image a backup of your entire system but the RESTORE aspect is extremely vague. In fact there's a menu item to backup but no menu item to restore. I ran unpi on the console and essentially it is extremely confusing. Rather than using target and source or source and destination is has "archive" and "directory" which if you can make sense of that, kudos. I tried all combinations of dev1,2,3 and using archive and source. What's strange is the partitions listed show the internall HDD and the USB HDD however UNLIKE pi, unpi doesn't ever see the USB HDD when you're selecting the 'source' and 'destination' Either way can anyone please assist me? I am in a bind professionally. This is a time sensitive item and I must get this restored asap. I have the image spanned across a bunch of 2GB files each with an incremental numeric extension. I can even restore to a VMware vm if needed or if possible (which would be GREAT) convert this backup to some other format. Ghost image would be my main preference. Here is the byproduct of pi's backup: FOLDER: 2017-12-22-DIR-sda2 Root: partition-info.txt pi.cfg Inside folder: 2017-12-22-I-sda2.000 through to 2017-12-22-I-sda2.054 107GB total. Target drive is 128GB Drive that was imaged was 250GB I either get a choice of folders to pick from to find the backup that aren't the USB HDD or it gives me some kind of error talking about midnight commander causing the problem "If you ran unpi in midnight commander this may be the issue" however I haven't done that. I loaded shell and rand it.