Salient Soft

Update 27/7/22

I created a recovery disc for our Surface Pro 4, but the challenge was that it only has a single USB3 port – I needed 2 ports, one for the recovery flash drive and another for the backup drive.

I purchased a Sabrent 4 port USB3 hub which worked fine, and also a StarTech USB3 to eSATA adapter cable. These worked fine on the PC. Also, Paragon Backup would also boot fine when plugged into the hub. However, the Paragon recovery environment would not load the eSATA backup drive when it was plugged into the hub via the adapter cable. Interestingly, it would recognise it if I plugged the adapter cable directly into the USB port on the Surface Pro 4, removing the recovery disk. However, then naturally the recovery environment whinged about the lack of its recovery disk/system disk. I looked online but could not find a solution to this.

In the end I decided that in practice I was unlikely to ever need to do a bare metal restore on the Surface Pro 4. The drive is not replaceable by me and would need doing by MS as was the previous repair, and a new OS install would be done with this. It was however worth doing a full backup of the system without using the recovery disk, so that I had all the files if needed, so I did this and left matters there.

Update 25/7/22

Added a new rescan-drives.bat file plus associated diskpart-rescan-drives.txt file, to allow a rescan to be done easily in case I forget the diskpart command in future. This has been added to all the recovery discs as a convenience.

Update 22/7/22

I have now switched to using flash drives for the recovery disks – each PC has its own. Each drive was created from the Windows image rather than the ADK which simplifies things. I found that where a PC used custom eSATA drivers, I still needed to load these via mount-backup.com as with the CD ISO image, but this worked fine. The flash drives are more convenient and boot more quickly, and no CD drive is needed.

On my newer PCs with the drivers included, i.e. eSATA on the motherboard and windows drivers already present, mount-backup did not need to load drivers so I added the rescan command after the automount enable command. This allows mount-backup to be run twice if necessary, before and after turning on an eSATA drive. Sometimes I found that Paragon would do a drive scan later when powering on the drive if I had already issued a rescan in diskpart earlier directly after booting, but this was not consistent.

On the older PCs where custom drivers were loaded, I could not run mount-backup twice so did not bother with the rescan command. I could in future add a second batch file to just do the rescan, but it is easy to do in diskpart anyway, but does need remembering how to do it.

Update 23/4/22

When using a Windows 11 recovery disk for a new PC, I had not included the extra drivers or the batch file below, as the Asus motherboard already had SATA ports on it – I had just added a SATA to eSATA back plate on the PC to make the internal ports available externally. This meant that the necessary drivers were already included in windows.

When trying the recovery disk again a few weeks later, I found that when the backup drive was connected at boot time, it was visible when the recovery disk had loaded. However, the recovery disk had made a complete mess of the drive letter assignments – they were confusing and all over the place when viewed in diskpart with a list volumes command.  I was not clear how this might or might not affect backup/restore operations – it possibly would not, but it made navigating the drives and browsing manually a complete pain, so I resolved to eliminate the problem. When booting without the backup drive on, the drive letters were assigned normally. However, when turning on the backup drive, it did not load and mount. This was much like recent behaviour I had seen in Windows 11 – auto loading of eSATA drives was intermittent, and it often needed a “Scan for hardware changes” in HotSwap to load and mount the device.

I found that diskpart has a rescan command (which may well be the command called under the hood by HotSwap). When run after turning on a backup drive after booting the recovery disk, this command loaded and mounted the disk successfully, and crucially, the drive letter assignments were all sensible.

I would shortly be updating backup strategy when some new SATA backup drives arrive shortly, so at that time, I will change the recovery disk for the Windows 11 PC to also include a mount-backup.bat batch file which will just issue the rescan command in diskpart, for convenience and consistency.

Original

I installed the community version of Paragon Backup and tried to create a recovery disk (which boots and runs under Windows PE) from the settings menu.
To create an Iso that you can burn to CD requires that you install the Windows ADK before creating the recovery disk.
I had some trouble locating the correct ADK version for Windows 10 21H2 build 19044. Strangely it was not very clear from the Microsoft site but this site here helped https://www.prajwaldesai.com/windows-10-adk-versions/ and I went for the ADK for Windows 10 version 2004 and this installed and worked fine.

I also tried creating a bootable flash drive which also worked fine, and which does not need the ADK installed, but preferred to use a CD/DVD as my bootable recovery media.

The Paragon Documentation states that you can load optional drivers, either just temporarily for a single run after booting the recovery media, or permanently which you do when creating the recovery media with Paragon. In my case, I needed to install a Silicon Image eSATA driver for the backup media. To install permanently it states that you need the ADK installed. However, when I tried this, I could not find the option to add a driver when building the recovery media at all despite repeated attempts and careful reading of the Paragon docs. I tried this with and without the ADK installed, and to no avail. I also could not find another way to plant a boot up call to a batch file of my own in the recovery media build.

I therefore went for an alternative solution. The paragon recovery environment has an option under the settings menu to open a command prompt. When I checked online, it was possible to load a driver from this prompt using the Windows PE drvload command, and just passing it the .inf file for the driver kit to be loaded. Again, this is a temporary load just for this bootup, but it works fine.

When I first tried this, it loaded the driver and the disk, but did not mount the disk and assign a drive letter. I could see the disk using diskpart, but no drive letter was assigned. I then investigated and found that auto mounting was not enabled under the recovery environment, and this caused the problem. Whilst I could mount and assign a driver letter seperately, a nicer solution was to enable automounting before loading the driver. This could be done with the automount enable command in diskpart. Once this was done, loading the driver with drvload caused the disk to load and mount fully, and after switching back to the backup/restore view the recovery environment indicates that this load/refresh is in progress and then displays the backup disk correctly.

To simplify this, I created a batch file and diskpart script to do these operations, and placed these along with the driver kit on the bootable media, with the main batch file mount-backup.bat in the root and a subfolder mount-backup containing the other files/drivers. It was then only necessary to run this batch file from the dos prompt after the recovery environment had initially booted, e.g. typing “J:\mount-backup” was enough. Note that a CD/DVD drive did not show in the drive list displayed by Paragon, even though it was loaded and mounted – it only showed the disks. (If booting from a flash drive, this does show up so you don’t have this issue.) An easy way to find the drive letter for the CD/DVD drive was to run diskpart from the command prompt, and just enter “list volume”. This listed all the drives and their drive letters. Note that “list disk” is similar but does not display the drive letters. From this I saw my DVD drive listed as drive J and could immediately run the batch file on it. Whilst this is not a “one click” solution, it is fine in this situation as performing a bare metal restore using bootable recovery media is not a one click operation anyway.

mount-backup.bat

%echo on
set _SCRIPT_DRIVE=%~d0
set _SCRIPT_PATH=%~p0

diskpart /s “%_SCRIPT_DRIVE%%_SCRIPT_PATH%mount-backup\diskpart.txt”
drvload “%_SCRIPT_DRIVE%%_SCRIPT_PATH%mount-backup\drivers\SI3132\SI3132.inf”

diskpart.txt

automount enable
exit

Comments Off on Creating a Paragon Backup Recovery Disc

This article here discusses how to perform Linux backups and restores using tar ( I have also saved a pdf of the post in the Linux section of the repository).

I wanted to at least backup my system so that I had all the custom configuration and shell scripts backed up.

I was not looking to do a full restore – if I lost the system I would reinstall from CD and then probably pull from the backup piecemeal manually as required.

As an Imedia system is so small (mine is only 2GB), I backed up to a FAT32 flash drive and then archived the backup elsewhere. Imedia does a good job of handling USB drives, but will need FAT32 rather than NTFS.

tar appears to do a pretty good job of backups – symbolic links are handled correctly by default (it backs up the links rather than following to the files), and permissions etc. are backed up as per the above article.

The following example shows my backup script, generated with the help of the above article:-

#!/bin/bash

if [ -z $1 ]; then read -p "Enter Backup Name:" name;     else name=$1; fi
if [ -z $2 ]; then read -p "Enter output directory:" dir; else dir=$2; fi

file="${name}_`date +%Y-%m-%d_%H-%M-%S`"
if [[ $dir != */ ]]; then dir=$dir/; fi
file=$dir$file

echo Backup: $name started at: `date +"%d-%m-%Y %H:%M:%S"` > $file.log
echo Output File: $file.tar.gz >> $file.log
echo >> $file.log

tar -cvpzf $file.tar.gz --exclude=$file.* --exclude=/proc --exclude=/lost+found --exclude=/sys \
    --exclude=/mnt --exclude=/media --exclude=/dev --exclude=/var --exclude=/tmp / >> $file.log 2>&1

echo >> $file.log
echo Backup: $name completed at: `date +"%d-%m-%Y %H:%M:%S"` >> $file.log

No Comments »

I tried using Acronis TIH 2010 to backup to 2 different removable drives, to rotate them. Initially I mounted each drive as R: when used, which requires changing the drive letter each time. As a consequence of this, I was also using a single TIH backup task and a single TIH validate task for both removable drives. However, when I came to do a separate validation of the backup on the 2nd drive, having already done the first, I received the error “The operation failed” with no other detailed information. This was strange, as the backup process had just done its own validation successfully. I suspected that Acronis was confused between the 2 backups, as both had the same name (as they were done on the same date during testing) and were on the same drive letter, even though they were different volumes. Acronis keeps an internal database of its backups as detailed here, and as the post indicates, it needs to keep track of the renaming/moving of backups. The confusion on this was compounded by this post concerning Acronis Backup & Recovery 10, which states that when using multiple usb drives as rotating backups, the same drive letter should always be used. However, this is clearly not correct in my scenario. In another test, I performed a second incremental backup on each removable drive, and Acronis asked me to browse for the correct full backup when doing the validation phase of the backup – it had clearly become confused.

I switched to using a different drive letter for each volume, R: and S:. As a consequence I also created separate backup and validate tasks for each volume, as each would point to a different drive letter – this also improved clarity as  a side effect – it separated the activiy/logs for each volume which gave a clear view of what had been done. Having done this, I did a full backup with each volume in turn of the same PC, and did an additional validation as well. All of these worked correctly. Crucially, in addition I re-did a validation of the first again at the end, having backed up and validated the second. This still worked correctly – Acronis was now able to track the backups correctly.

The other advantage of separate drive letters is that Windows will try to reuse the same letter for a volume as it used previously, meaning that mostly you will only need to set them once with Disk Manager (this can get messed up if you have additional removable drives in at the time you mount one of the backup ones, as Windows may have already re-used the ‘reserved’ drive letter, but mostly it works fine).

Although I did not test it, I suspect that another solution would be to uniquely label each backup file on each volume, perhaps by incorporating the volume name (e.g. “Backup1”, “Backup2”) as part of the file name. I suspect that this also would remove the ambiguity which was tripping up Acronis. In my case, I was happy to use the same folder and file naming convention on each backup volume, and just keep the drive letters different. You should use drive letters consistently in acronis – if you do not, it will be unable to find the backups it has in its database and will end up prompting for the location of backups when asked to run tasks.

No Comments »