That is probable mostly correct with one complex exception.
It is possible to first uncompress the image file to the raw state.
Then you can mount that file as a loop process. Have done it a few times,
but uncompressed size is size of the original disk/partition so needs lots of space.
The loop mounting process is also something I'd have to look up, since it depends if it is a partition
or disk image, and OS might make difference. Usually easier to just restore to an external disk.
So, mostly Not Possible with an easy process is a bit level image of disk, so doesn't have file information listed.
It's purpose is to get the whole disk/partition back up to a known state versus file level backup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Agree that it isn't an easy process and it is probable more work than restoring to a spare disk. Recall I once needed a file from a smaller partition I had imaged, and didn't have a spare disk at time were I was, so tried it. Probable more just to see if it would work, and it did. So. Definitely agree that quickest option would be to just restore to a spare disk, and then search it.
On issue that might be of concern. If doing this on same system with original disk, the bllkids on disk would be identicle and if OS uses blkids versus using partition names.
Recall cloning a disk /dev/sda to /dev/sdb. If rebooted with both disk in machine, it would have issues since blkids were same on both disks. If imaged to an usb disk, then disconnecting it on boot would solve that issue.
Thanks for message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have successfully accessed files from the G4L image file.
The backup have been from a Windows 7 system and a Windows 10 system.
I have accessed these from a Windows 7 and Windows 10 system.
I create backup with the default lzop compression, thus I had to uncompress the image prior to mounting to it. As mentioned previously you will need enough hard drive space for the original size of the hard drive that was backed up. Also if your image file is on a network this will take a lot of time to uncompress. I recommend copying the image file locally prior to uncompressing it. It still will take some time.
I installed lzop from www.lzop.org.
Use command
C:\Tools\lzop103w\lzop.exe –d –o HD_Backup_UnComp.img HD_Backup.img
I installed OSFMount from www.osforensics.com/tools/mount-disk-images.html
Using OSFMount
File -> Mount new vitual disk..., select image file, <open>, <next>, select partition to mount to (typically larger one), <next>, <mount>
Note the drive letter.
You should now be able to use Windows Explorer to access the files from the backup image.</mount></next></next></open>
Kevin Eisinger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done similar on Linux. Used lzop to extract the compressed data image to a file that is the original size of partition. Then used the linux loop mount option? Would have to look up the process since it has been a long time. But generally just restoring to a spare disk is faster.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just like it says. If I make a G4L backup can I see individual files in it? Can I pull a file from the backup?
Thanks!
No. It's an image backup, and you have to restore the image somewhere to see and pull files from it.
That is probable mostly correct with one complex exception.
It is possible to first uncompress the image file to the raw state.
Then you can mount that file as a loop process. Have done it a few times,
but uncompressed size is size of the original disk/partition so needs lots of space.
The loop mounting process is also something I'd have to look up, since it depends if it is a partition
or disk image, and OS might make difference. Usually easier to just restore to an external disk.
So, mostly Not Possible with an easy process is a bit level image of disk, so doesn't have file information listed.
It's purpose is to get the whole disk/partition back up to a known state versus file level backup.
That complex "exception" is actually a multi-step restoration of the image to a state in which files can be extracted.
Agree that it isn't an easy process and it is probable more work than restoring to a spare disk. Recall I once needed a file from a smaller partition I had imaged, and didn't have a spare disk at time were I was, so tried it. Probable more just to see if it would work, and it did. So. Definitely agree that quickest option would be to just restore to a spare disk, and then search it.
On issue that might be of concern. If doing this on same system with original disk, the bllkids on disk would be identicle and if OS uses blkids versus using partition names.
Recall cloning a disk /dev/sda to /dev/sdb. If rebooted with both disk in machine, it would have issues since blkids were same on both disks. If imaged to an usb disk, then disconnecting it on boot would solve that issue.
Thanks for message.
I have successfully accessed files from the G4L image file.
The backup have been from a Windows 7 system and a Windows 10 system.
I have accessed these from a Windows 7 and Windows 10 system.
I create backup with the default lzop compression, thus I had to uncompress the image prior to mounting to it. As mentioned previously you will need enough hard drive space for the original size of the hard drive that was backed up. Also if your image file is on a network this will take a lot of time to uncompress. I recommend copying the image file locally prior to uncompressing it. It still will take some time.
I installed lzop from www.lzop.org.
Use command
C:\Tools\lzop103w\lzop.exe –d –o HD_Backup_UnComp.img HD_Backup.img
I installed OSFMount from www.osforensics.com/tools/mount-disk-images.html
Using OSFMount
File -> Mount new vitual disk..., select image file, <open>, <next>, select partition to mount to (typically larger one), <next>, <mount>
Note the drive letter.
You should now be able to use Windows Explorer to access the files from the backup image.</mount></next></next></open>
I've done similar on Linux. Used lzop to extract the compressed data image to a file that is the original size of partition. Then used the linux loop mount option? Would have to look up the process since it has been a long time. But generally just restoring to a spare disk is faster.