| HDD GURU FORUMS http://forum.hddguru.com/ |
|
| Hetman Software Data Recovery Lab: Real Hardware, Real Failu http://forum.hddguru.com/viewtopic.php?f=7&t=46272 |
Page 1 of 1 |
| Author: | hetmansoftware [ September 5th, 2026, 7:06 ] |
| Post subject: | Hetman Software Data Recovery Lab: Real Hardware, Real Failu |
Hello everyone, In this thread, I plan to share results from our testing lab for Hetman RAID Recovery and Hetman Partition Recovery. We test the software with different RAID configurations, NAS devices, storage controllers, file systems, virtual disks, encryption, disk images, and various data loss scenarios. I would be interested in feedback from HDDGuru members, especially from people who work with data recovery in practice. Please feel free to comment on the tests themselves. If you think the methodology is weak, an important scenario is missing, or the test does not reflect a realistic recovery case, I would like to hear it. You can also suggest:
If there is functionality you would like to see in Hetman RAID Recovery or Hetman Partition Recovery, you are also welcome to describe it here. We can review such requests and, where they make sense, consider them for future versions. I will use this thread to post test results, technical notes, screenshots, and related videos. Feedback and criticism are welcome. |
|
| Author: | Lardman [ September 5th, 2026, 7:57 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
We heard you the first time, after 4 posts it's beginning to feel like spam again. |
|
| Author: | hetmansoftware [ September 5th, 2026, 9:29 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
In the latest version, we added support for VeraCrypt containers and encrypted partitions, including both standard and hidden volumes. Hetman Partition Recovery can unlock VeraCrypt volumes using a password, PIM, keyfile, or their combination, and then analyze the decrypted filesystem for existing and deleted files. In this test video: https://www.youtube.com/watch?v=NlgMI807V2I we covered three scenarios:
In all three cases, the volumes were unlocked and their contents were accessible for analysis and recovery. If you work with VeraCrypt in practice, please share the scenarios or features you would like us to support — we can review them for future versions. |
|
| Author: | WebClaw [ September 5th, 2026, 11:12 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Michael; your spamming now - a single thread can suffice. |
|
| Author: | hetmansoftware [ September 6th, 2026, 2:52 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
One area we have been working on in Hetman RAID Recovery is support for RAID controller metadata. When supported metadata is present on the member disks, the software reads it and reconstructs the array automatically, so it is available for further analysis. In recent versions, we added support for Infortrend EonStor DS 1000 / ESDS 1012 RC metadata used in Infortrend storage systems. In this test: https://www.youtube.com/watch?v=tSKfPN-k2Ho we covered:
We have also tested RAID metadata from a number of other hardware and motherboard controllers: Dell: PERC 6/i, H310, H700 LSI / 3ware: 3081E-R, MegaRAID SAS 84016E, 9280-4i4e, 9265-8i, 3ware 9750, 9650SE-4LPML Adaptec: ASR-6405, ASR-6805T Areca: ARC-1210, ARC-1260 HP/HPE Smart Array: P410/P410i, P822 IBM: ServeRAID M5016 Fujitsu: D3116, D2516-C11 GS1 Supermicro: AOC-USAS-S8iR Dawicontrol: DC-624E InLine: 76696C AMD: RAIDXpert2 Intel: Rapid Storage Technology Infortrend: EonStor DS 1000 / ESDS 1012 RC The corresponding tests on our YouTube channel also contain practical information that can be useful for manual reconstruction, including disk order, stripe/block size, block/parity order, byte order, and disk offset. If there is a controller or metadata format that you regularly encounter in real recovery cases and would like us to test, please suggest it. WebClaw, Lardman, Understood. The purpose of this new thread is exactly to keep all future Hetman Software tests and related technical updates in one place. I’ll contact the forum administrator and ask to have the other Hetman-created threads in this section removed, so that going forward I will use only this thread for our tests and updates. |
|
| Author: | hetmansoftware [ September 7th, 2026, 3:36 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Another area we are working on is support for different disk image formats. Forensic images. Recent versions added support for EnCase / EWF (.e01, .s01, .ex01), AFF (.aff, .afm, .afd), AFF4 (.aff4), and AFF4 Directory Volumes. Single-file, split/multi-segment and compressed images are supported where applicable. In this test: https://www.youtube.com/watch?v=UlN933-iRLA we created forensic images of a USB drive with Exterro FTK Imager. The drive contained a prepared test dataset, with some files deleted before imaging. We then mounted the resulting images and tested recovery of both existing and deleted files. Apple disk images. We also added support for .dmg (UDRO, UDRW, UDZO, UDBZ, ULFO, ULMO, UDSP, UDSB), .asif, .sparsebundle, .sparseimage, .cdr, .toast and .iso. Regular, split, sparse, compressed and encrypted images are supported where applicable. In this test: https://www.youtube.com/watch?v=jhkg52Tx2bY we mounted several image types, scanned their filesystems and recovered files from them. Support for .sparsebundle is also useful when working with Time Machine backups stored on devices such as Time Capsule, NAS systems or network storage. Another practical case is a partially damaged image that can no longer be mounted by its original software or operating system. In such cases, the image can still be opened and scanned to determine whether part of the filesystem and files can be recovered. Raw / sector-by-sector images. The software can create a sector-by-sector image of an entire disk, a partition, or a selected range defined by starting sector and size. It can also work with raw byte-for-byte images created by other tools, including GNU ddrescue, FTK Imager, PC-3000 Data Extractor, Guymager and X-Ways Imager. This is particularly useful when repeated access to the original media should be avoided, for example when a drive has bad sectors or behaves unstably. Once mounted, an image is handled much like a physical disk: it can be scanned for existing and deleted files, encrypted volumes can be unlocked, and supported encrypted files can be processed. If RAID metadata is present, it can also be used to reconstruct the array. Physical disks and disk images can be combined when working with RAID arrays or storage pools. I would be particularly interested in feedback from people working in digital forensics: which image formats, metadata, validation features or forensic workflows are still missing for your day-to-day work? |
|
| Author: | hetmansoftware [ September 8th, 2026, 5:25 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Another area we are working on is support for virtual machine disks and snapshot chains. Hetman Partition Recovery and Hetman RAID Recovery can mount either an individual virtual disk file or an entire virtual machine folder. In the latter case, the software analyzes the VM structure, identifies base disks, differencing/overlay files, snapshots, and the relationships between them. Supported layouts include fixed/thick, dynamically allocated/thin/sparse, split/multi-part and differencing disks, as well as internal and external snapshots and multi-level snapshot chains. Main platforms and formats
For snapshot chains, the software determines parent-child relationships, finds the base disk and reconstructs the available disk states. For example, this may be a base VMDK plus delta VMDKs in VMware, VHDX plus AVHDX in Hyper-V, or a base QCOW2 plus external overlay files in QEMU/KVM. Each reconstructed state can then be analyzed as a regular disk for partitions, file systems, existing files and deleted data. Example: Proxmox VE In this test: https://www.youtube.com/watch?v=DYHb8K775yE we created a Windows 10 virtual machine in Proxmox VE and attached disks in RAW, VMDK and QCOW2 formats. Test files were copied to the disks and some of them were deleted. We then demonstrated:
We also tested a scenario where the virtual disk files themselves had been deleted. The VM disk files were first recovered from EXT4, then mounted and analyzed for the data stored inside the guest system. Example: Unraid and snapshot chains In this test: https://www.youtube.com/watch?v=JyDpjjelim0 we created a virtual machine in Unraid on an XFS storage volume and attached RAW, IMG and QCOW2 disks. After writing test files to the disks, we created external snapshots and then deleted part of the data inside the guest system. After recovering and mounting the VM folder, the software automatically identified the base disks and their related snapshot/overlay files. For the disks, both the state before the snapshot and the current state with the snapshot changes applied became available for separate analysis. Both states could be scanned for existing and deleted files. We also tested a different case where the virtual disk files had been completely deleted from XFS. Instead of recovering the VM disk as an XFS file, a full scan of the physical storage detected the NTFS filesystem of the guest Windows system directly in the sectors that previously belonged to the virtual disk. So there are two possible recovery paths: Host filesystem -> recover VM disk file -> mount VM disk -> recover guest files or, when the VM disk file itself cannot be recovered: Host storage -> detect guest filesystem directly -> recover guest files Another practical case is a partially damaged VMDK, VHDX, VDI or QCOW2 file that can no longer be opened by the original hypervisor. If enough of the disk structure remains readable, it may still be possible to mount and scan it without starting the virtual machine. I would be interested to hear from people who deal with VM recovery in practice: which formats, snapshot chains, damaged-disk scenarios or unusual configurations would be useful to add to our future tests? |
|
| Author: | hetmansoftware [ September 9th, 2026, 7:59 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Another area we are working on is support for physical NAS, DAS and SAN storage systems in Hetman RAID Recovery. For these systems, we have implemented support not only for RAID reconstruction itself, but also for the storage layers that may exist above it: physical disks -> RAID -> volume management -> filesystem / LUN -> data Depending on the storage architecture, snapshots may exist at the filesystem, volume or storage-pool level. The software can read RAID metadata directly from member disks or their images and reconstruct the array automatically. If the RAID metadata is damaged or unavailable, the array can also be reconstructed manually by specifying disk order, stripe size, offsets, parity layout and other parameters. NAS For NAS systems, we have implemented support for common Linux-based storage stacks, including Linux MD (mdadm), LVM, Ext2 / Ext3 / Ext4, XFS, Btrfs and ZFS. Vendor-specific RAID layouts are also supported, including:
The software also handles multi-device storage configurations such as Btrfs and ZFS pools, mirrors and RAIDZ. For Btrfs and ZFS, the software can also work with snapshots. After RAID reconstruction, Hetman RAID Recovery can continue through the higher storage layers, depending on the layout: partition tables, LVM, filesystems, snapshots and LUNs. Example: Synology SHR-2 and LUN recovery In this test: https://www.youtube.com/watch?v=NZP2e7991t0 we demonstrated automatic SHR-2 reconstruction from the member disks and also examined the standard parameters required to reconstruct the same array manually. We also tested recovery of a deleted LUN file. After the LUN was recovered, it was mounted in the software as a separate block-level source, analyzed, and the files stored inside it were recovered. In this particular test, the recovery path contained several storage layers: SHR-2 -> filesystem -> LUN -> filesystem inside LUN -> files NAS devices used in our tests:
Across these systems, our tests covered RAID metadata detection, reconstruction of standard and vendor-specific RAID layouts, filesystem analysis and recovery after failure of the original NAS hardware. DAS / external RAID storage For DAS systems, Hetman RAID Recovery can reconstruct an array from directly accessible member disks or their images without relying on the original enclosure. Devices used in our tests include:
For Oyen Digital, we also tested manual RAID 5 reconstruction from the member disks. With MicroNet Platinum FireWire800, we tested RAID 5 analysis and data recovery after loss of access to the array. SAN For SAN storage, Hetman RAID Recovery can also work with logical block storage presented above the underlying RAID, including LUNs. In our hardware tests, one such system was D-Link DSN-1100 with RAID 5. The software can reconstruct the underlying RAID and then continue with analysis of the block storage and filesystem inside the LUN. I would be interested to hear from people who work with NAS, DAS or SAN recovery in practice: which vendor-specific metadata, storage layers, LUN structures or unusual RAID layouts would be useful for us to add to future tests and support? |
|
| Author: | hetmansoftware [ September 10th, 2026, 5:05 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Another area we have been working on is support for encrypted volumes and encrypted files in Hetman Partition Recovery. Encryption may exist at different levels of a storage structure. It may protect an entire volume, or only individual files and directories. Hetman Partition Recovery handles both cases: physical disk / disk image / virtual disk -> encrypted volume -> filesystem -> data or physical disk / disk image / virtual disk -> filesystem -> encrypted files / directories -> data With valid credentials, the software can unlock supported encrypted volumes and continue filesystem analysis, including existing and recoverable deleted data. At the volume level, we currently support BitLocker, LUKS and VeraCrypt. At the file and directory level, we support Windows EFS and Linux fscrypt. BitLocker https://www.youtube.com/watch?v=CbMA34Zr0ak In this test, we worked with BitLocker encryption on a Windows system drive, an additional HDD and a BitLocker To Go USB drive. We tested access to encrypted storage and recovery after file deletion, formatting and filesystem corruption. LUKS https://www.youtube.com/watch?v=8CnT2iARsGE In our LUKS tests, we covered LUKS1 and LUKS2 volumes containing Ext4, Btrfs and XFS filesystems, unlocking with a password or keyfile, LUKS container files, and detection of an encrypted volume after its partition entry had been deleted. Windows EFS https://www.youtube.com/watch?v=8-E0E0V7A_8 Unlike BitLocker, EFS encrypts individual files and directories on NTFS rather than the complete volume. We tested detection and recovery of existing and deleted EFS-protected files after deletion, formatting, partition loss and NTFS corruption. When the corresponding certificate and private key are available, Hetman Partition Recovery can decrypt the recovered files. In this test, the certificate and private key were supplied in a PFX file. Linux fscrypt https://www.youtube.com/watch?v=sDJd8C4E72k fscrypt provides file and directory encryption at the filesystem level rather than encrypting the complete block device. For this test, we used an Ext4 filesystem on a USB drive. We tested recovery after deleting files from an fscrypt-protected directory and after deleting the entire Ext4 partition containing that directory. Hetman Partition Recovery detected the available filesystem structures and fscrypt-protected data. With valid credentials, both existing and recoverable deleted files could be accessed. Filesystem metadata that is not protected by fscrypt can still be analyzed during recovery, helping the software identify encrypted objects and reconstruct the filesystem structures that remain available. Valid credentials are still required Recovery and decryption are separate tasks. Hetman Partition Recovery can locate lost encrypted volumes, deleted partitions and encrypted files, reconstruct the available filesystem structure, and recover data whose contents have not been overwritten. However, decryption still requires the correct password, recovery key, encryption key, certificate/private key, keyfile or other valid credentials. The software is designed for recovery from encrypted storage, not for cracking or bypassing encryption. I would be interested to hear from people who work with encrypted storage in real recovery cases: which encryption/filesystem combinations or failure scenarios involving encrypted storage would be useful for us to test next? |
|
| Author: | hetmansoftware [ September 11th, 2026, 1:47 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Another area we have been working on in Hetman RAID Recovery is support for software NAS platforms that can turn an ordinary PC or server into network-attached storage. In an earlier post, I described our work with physical NAS, DAS and SAN systems. This time I would like to focus on platforms where the storage architecture is defined mainly by the operating system and the storage technologies it uses rather than by a specific NAS controller. From a recovery perspective, these systems are quite different. TrueNAS is built around ZFS, OpenMediaVault commonly uses Linux MD/mdadm for software RAID, Rockstor is based on multi-device Btrfs, while Unraid uses its own architecture with independent data disks and parity. TrueNAS TrueNAS uses ZFS as its primary storage technology. In this test, we worked with RAIDZ1, RAIDZ2, RAIDZ3 and Stripe, automatic ZFS pool reconstruction, missing drives and deleted data: https://www.youtube.com/watch?v=x39jwpLwe4o In another test, we focused on higher-level ZFS objects, including Datasets, ZVOLs and Snapshots, as well as virtual disks stored inside a ZFS pool: https://www.youtube.com/watch?v=vMw3zFfzBwQ A ZVOL is a block device provided by ZFS, while datasets provide filesystem-level storage. Snapshots can be associated with these ZFS objects and represent another source of recoverable data. For recovery, this means that reconstructing the RAIDZ layout is only one part of the task. The software also has to recognize the ZFS pool and the objects stored inside it. A simplified view is: physical disks -> ZFS pool / RAIDZ -> datasets or ZVOLs -> data with snapshots associated with the corresponding ZFS objects. OpenMediaVault In this test with OpenMediaVault 8.2.8, we worked with mdadm RAID 0, RAID 5 and RAID 6: https://www.youtube.com/watch?v=xz3rfgPD2J4 Hetman RAID Recovery reads Linux MD metadata from the member disks and can use it to reconstruct the array automatically. We also tested manual RAID reconstruction for cases where the available metadata is incomplete or the array parameters need to be specified manually. After the MD array has been reconstructed, the software can continue analyzing the storage layers above it, such as partitions, volume structures and filesystems. A simplified structure is: physical disks -> Linux MD/mdadm RAID -> volume/filesystem -> data Rockstor Rockstor takes a different approach. Its storage is built around Btrfs, where filesystem and multi-device storage management are closely integrated. In this test with Rockstor 5.1, we worked with Btrfs RAID 0, RAID 5 and RAID 6 profiles: https://www.youtube.com/watch?v=MN2dgOMJ3IY Hetman RAID Recovery automatically detected the multi-device Btrfs layout. We also tested recovery from Btrfs snapshots and analysis after deletion of a Btrfs pool. Unlike a traditional mdadm-based stack, there is no mandatory separate RAID layer here. Information about how data is distributed across the devices is part of Btrfs itself. A simplified structure is: physical disks -> Btrfs multi-device filesystem -> subvolumes / snapshots -> data Unraid Unraid uses a substantially different storage model. Unlike traditional striped RAID, complete files are stored on individual data disks, while one or two dedicated parity disks provide protection against disk failure. In this test, we worked with Unraid Single Parity and Dual Parity: https://www.youtube.com/watch?v=hkCEM_dciYY Hetman RAID Recovery can analyze the available XFS data disks individually, determine the original disk order and filesystem offset, and virtually reconstruct missing data using parity information. In our tests, we reconstructed one missing data disk in a Single Parity array and two missing data disks in a Dual Parity array. For this reason, an Unraid array should not be treated simply as another variation of RAID 5 or RAID 6. A simplified view is: independent data disks + parity disk(s) -> individual filesystems -> data For Hetman RAID Recovery, supporting these platforms is therefore not just a matter of reading a particular filesystem. The software has to understand the relationship between physical disks, RAID or pool metadata, volume structures, filesystems, snapshots and block-level objects, and reconstruct the available storage layers before filesystem recovery can begin. I would be interested to hear from people who work with software NAS systems in real recovery cases: which platforms or storage layouts would be useful for us to test next - complex ZFS pools, Btrfs configurations with missing devices, mdadm/LVM stacks, unusual Unraid arrays, or other NAS operating systems? |
|
| Author: | hetmansoftware [ October 9th, 2026, 6:54 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
October 2026 Update: Encrypted ZFS, dRAID, VMware/VirtualBox Encryption, and RAID Reconstruction Improvements We've released new versions of Hetman RAID Recovery and Hetman Partition Recovery, with several additions related to encrypted storage, RAID reconstruction, and virtual machine disk recovery. I'd like to share the main technical changes and some of the recovery scenarios we've been testing in our lab. 1. ZFS Native Encryption and dRAID We've added support for native ZFS encryption, including:
We also added support for ZFS dRAID1, dRAID2, dRAID3, and RAIDZ Expansion. We tested encrypted ZFS recovery on FreeBSD 15.1 using two configurations. Test A: Deleted files and destroyed encrypted ZFS pools We created three separate ZFS pools on GPT partitions of a physical disk, using native ZFS encryption on their root datasets. One was unlocked with a password, another with a key file, and the third used a different password. After deleting files, we exported the first two pools. For the third, we executed Code: zpool destroy and then deleted its GPT partition.We connected the physical disk in read-only mode to a Windows 10 VM running under bhyve. Hetman Partition Recovery detected all three pools, including the destroyed one, unlocked their encrypted data, and found existing and deleted files. Fast Scan was sufficient in this test. Test B: Encrypted dRAID1 with one missing disk We configured four physical disks with three separate dRAID1 pools. Each used two data columns, one parity column, and distributed spare capacity equivalent to one member. All three pools used native ZFS encryption with AES-256-GCM. We tested three failure scenarios:
For recovery, we connected only three of the four physical disks. Hetman RAID Recovery automatically identified all three dRAID1 pools, including the destroyed one, and marked the unavailable member as missing. After unlocking the encrypted data, we could browse existing and deleted files and access files from the earlier snapshots, without rebuilding the array. These experiments used encryption configured on the root datasets. More tests involving separate encryption roots, inherited keys, clones, and encrypted ZVOLs are planned. 2. Encrypted VMware Workstation and VirtualBox Disks We've added support for encrypted virtual disks created by VMware Workstation and Oracle VirtualBox, including their snapshot chains. VMware Workstation test We created a fully encrypted VMware Workstation VM with two additional NTFS disks, one preallocated and one sparse. After creating two snapshots and deleting some files, we deliberately overwrote both the primary and backup NTFS boot sectors on the preallocated disk. Windows could no longer recognize its filesystem. Hetman Partition Recovery opened the encrypted VM disks using the VM folder and password. Full Analysis located the damaged NTFS filesystem and its files. We also accessed the earlier encrypted disk snapshots and recovered files without starting or reverting the VM. VirtualBox test We created nine encrypted virtual disks using VDI, VHD, VMDK, HDD, QCOW, and QED formats, covering preallocated and dynamically allocated storage. We created two snapshots, added and deleted files, and then analyzed the encrypted disk images directly. The software identified the disk and snapshot relationships, unlocked the encrypted data, and allowed us to examine files from both snapshots and the current state. One implementation detail worth mentioning: a VMDK encrypted by VirtualBox must be handled using VirtualBox's encryption mechanism, not VMware's, even though the underlying disk image format is VMDK. 3. RAID Constructor: Detecting RAID Configurations with Encrypted Volumes Previously, RAID Constructor could search for unknown RAID parameters, including disk order, block size, data offset, and layout, by testing candidate configurations against recognizable filesystem structures. This becomes more complicated when the logical volume on top of the RAID is encrypted. We've extended the detection algorithm to handle encrypted volumes, including LUKS, BitLocker, ZFS Native Encryption, and encrypted APFS. When evaluating a candidate RAID configuration containing encrypted storage, the software can request the required password or key, unlock the volume, and examine the underlying filesystem to help validate the candidate. This functionality is available during automatic parameter detection and in RAID Constructor's manual reconstruction workflow. The important distinction is that the RAID itself is reconstructed first. Encryption is applied to the logical volume above the RAID members, rather than independently to each member disk. We've previously demonstrated reconstruction of Linux MD RAID6 and LVM RAID6 configurations with LUKS2 and fscrypt, including scenarios with two missing disks. The new functionality extends RAID parameter detection by allowing encrypted volumes to participate in candidate validation. 4. LUKS1/LUKS2 with Detached Headers We've also added support for LUKS1 and LUKS2 volumes created with a separate header file. This allows the software to work with configurations where the LUKS metadata is stored separately from the encrypted data area, provided the required header and unlocking credentials are available. 5. Other Changes This release also includes:
For reference, here's an already published example of our existing RAID + LVM + LUKS + QCOW2 recovery workflow on RHEL 7.9, including internal QCOW2 snapshots: KVM/QEMU recovery experiment on RHEL 7.9 This video demonstrates an earlier recovery workflow, not the newly added encryption features. I'd be interested in technical feedback from people working with encrypted storage and complex RAID configurations. |
|
| Author: | athena [ October 14th, 2026, 4:41 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Hi I have v 4.9 licensed copy though I have not used it even once. I want to know whether it has capabilities to decrypt Bitlocker Standby encryption . Also want to compare it with UFS explorer / PC3K UDMA for standby Bitlocker decryption . Can it mount corrupted Bitlocker volume and mount it and provoke password window with skip -decryption feature. |
|
| Author: | hetmansoftware [ October 14th, 2026, 6:45 ] |
| Post subject: | Re: Hetman Software Data Recovery Lab: Real Hardware, Real F |
Hi athena, Thanks for your questions and for purchasing our software! First, you'll need to update your version of Hetman Partition Recovery, as BitLocker support was introduced in a newer release. The software automatically detects BitLocker-encrypted volumes on connected drives. If you have the password or recovery key, you can unlock the volume and then scan it to recover files, including deleted files or data from a damaged filesystem. All these features can be tested in the trial version. I'd also like to clarify a few things:
We're actively researching different encryption and data recovery scenarios, so your practical experience and suggestions would be very valuable. |
|
| Page 1 of 1 | All times are UTC - 5 hours [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|