Last Update: 02/04/2017
The programs described here to recover files from these *.1-Step backup files are compatible with backup files produced by this Iomega 1-Step backup program version 5.3. See 1-Step File Format documentation for information on how to identify this file type. Two programs are described:
1Srest - program to list or extract files in an *.1-Step backup file
1Scfg - program to view selection data base on machine that generated backup
Below is the usage screen displayed when no command line arguments are given:
1Srest version 1.00 abort: target path to archive is required as the first argument usage: ISrest [-f] [-l] [-p] [-x] [-vv] or [-vs#] with just displays the file header info and exits -f is primarily a debug and validation tool, which just displays where structure definitions are. use -f with -v to display structure headers -l list files that -x would extract -p set path string to limit List and Xtract operations -x extract files, without this option just displays catalog -v verbose mode and -vv is very verbose mode for additional information -vs# verbose mode to just list structure data for # where 1 <= # <= 7---------------------------
If you have looked at the 1-Step File Format page provided, this may make some sense. Initially I had a fair amount of trouble locating the data regions and the -f option helped me work out an algorithm to do that.
The two key options are -L to list the files in the backup and -X to extract them.
The -p option allows some selective Listing and Extraction. One supplies a path, or partial path, and any file in the archive with a path that matchs the specification will be Listed and/or extracted. This allows one to extract on a directory path basis. Below is a listing where a small sample file, IO2drv.bku, is used as the source file with the -L option to list the contents:
1Srest version 1.00 Backup name: test4 Job 6 Backup Disk 1 Catalog at offset 0x92a7 attempt to step through catalog and locate structure definition regions start of Structure Definition 1: Disk at 0xa377 start of Structure Definition 2: Dir at 0xc4fe start of Structure Definition 3: File at 0xe872 start of Structure Definition 4: Comp at 0x10c4c start of Structure Definition 5: Job at 0x129f6 start of Structure Definition 6: Path at 0x13a96 start of Structure Definition 7: Session at 0x15c9f data is not compressed link_data() 7 files 0 comp groups 4 unique paths cum data size 37031 catalog Files listing: 1: C:\Dos\HELP\ALT.TXT 20050421120728 len 1827 2: C:\Dos\HELP\aol.txt 20001212153536 len 3994 3: C:\Dos\text\boatmail.txt 20100510074010 len 9984 4: C:\Dos\text\Negus-P.txt 20051026091858 len 1445 5: D:\Inet\HTML\pdp-doc\1105.HTM 20011207091910 len 1975 6: D:\Inet\HTML\wwhome\Mac-68k.htm 20050204122834 len 7771 7: D:\Inet\HTML\wwhome\msbk-faq.htm 20040131103750 len 10035
display of catalog
Disks with 2 entries
Dirs with 9 entries
Files with 7 entries
Paths with 4 entries
Job data: Job number 6 number of disks 1
Session with 1 entries
The backup file above contains all the data as well as the catalog. You must start with the media disk containing the catalog to provide the information needed to restore files. Most of my example data are small single media disk backups which are easy to work with, but I have done three backups that span two data files to work out those details. As shown above the program starts by listing where the various structure definitions are located in the catalog region. You can view details of these regions by using the -vs# command line option and optionally also the -v options to make the display a progressively more verbose. They are different options and full the most verbose display both are required. The # in -vs# is between 1 and 7 to control which of the data structure regions should be sumarized in more detail. Some of the -vs# displays are very short, ie -vs5 for the Job region just redisplay whether or not the Job is compressed. -vs4 displays the Comp records if there are any, but does nothing if the job is not compressed.
These are primarily debug aids, but of interest in case there is a load problem. All these regions must be parsed before files can be extracted. The listing above with the -L options shows this backup contained 7 files from several different directories. The -X option would attempt to extract these same files.
I am trying to keep this simple, its just a tool. At this date it is unlikely
you will be attempting to restore to the machine the backup was made on. That
was the original intent of the 1-Step program. So for extraction I mangle the
path names. I've done most of my work in Linux, and in that environment I
replace the path delimiter, '\', with the Unix delimiter '/'. The program
no longer extracts to the dos drive letter either, C: and D: are replaced
by C_ and D_ or what ever drive letter was used. These root nodes are created
in the current directory that the program is run in. Sub directories are created
below these root nodes. Files are extracted to these sub directories. All sub
directories in the structure 2 definition, 'Dirs', are created before extractions
begins regardless of whether it a selective extraction or a full extraction.
If the backup is entirely contained in a single media file things are fairly straight forward and after loading the catalog all the files can be extracted. The more interesting case is where there were multiple media files created by the backup. In this case one needs to start with the media file for the last disk in the set to load the catalog to memory. Then switch to the first media file and sequentially open it and each additional media file to extract the files in the order they were backed up. In general it does not appear to be possible to extract files if you are missing any of the original media. It depends on the sequential order to do the extraction, and its hard to extract anything after the sequence is broken by a missing media file.
I believe I have worked out a system to recover the files from the last disk
in the set if one or more of the others are missing. In a multi media set
the program provides a few interactive prompts. The first asks if you want
to attempt to recover any files it can from the last disk in the set. If you
are desperate, try using 'Y' to this prompt, but its experimental...
The prudent solution is to say 'N' and start with the 1st media file in the set. The program will prompt interactively for each of the file names from the first to the last.Open them and try to do the extract. If all goes well it will eventually prompt for the last file again which it will reopen to complete the extraction and exit. Entering an empty file name, ie just pressing the Enter key at any of the prompts for a file name will abort the process. If a file name is entered that the program can't find or validate as part of this backup the prompt will be repeated.
Note the source files can be renamed, I make no attempt to force you to use the original names. Primarily because they were so long it was painful typing them in during debugging! However this program does attempt to validate the headers on each media file and insure that the time stamp matches that of the catalog media file. I show a typical name below, and mention them in my 1Step-format document. 'Backup Job 6, Disk 1, 16-10-23 02.47.01.1-Step' It includes the Job #, Disk #, and time stamp with a '1-Step' extension.
A few other thoughts:
A C source code distribution is available 1Srest.tar.gz
I suspected fairly early on that these backups used some form of LZW compression when compression of the data was requested. It took me a while to work out a solution to this,but eventually found the Zlib Distribution home page. I downloaded and built this library and after some testing worked out how to use it to decompress the raw data in the backup files the 1-Step program creates. Its a nice package, and is required to build my 1Srest utility. I used version 1.2.8, the most recent Zlib distribution. Their linux build works fine when linked with my program. I had to make minor modifications to their watcom build file to create the WinNT version of 1Srest.exe and provide this makefile as makefile.w32 in the source distribution. Warning, there is no linux style .configure in the source code distribution. You may have to adjust some of the library paths depending on how you build the required Zlib to create the full 1Srest executable.
There are a lot of built in error messages which will probably mean nothing unless you search the source code or ask me. For instance some of them have to do with the pre-allocated space I reserve for path names, directory paths and nesting level. I also validate the fields found in the various free format regions that define structure definitions. The version 5.3 of 1-Step backup I have used for my trials passes this validation, but other versions may not. Hopefully you will not see any errors, but I'm not really very confident that its bug free yet! Let me know if you try it and get a fatal error message.1-Step File Format. The 1Scfg will parse the *.DBF files and list there contents. The screen shot below is the display when no arguments are given. It lists the default file names and the numeric option at access the file.
usage: 1Scfg ? [-d] [-f] [-o] where ? maybe '1' through '7' for one of *.dbf: 1: IOAARCF.DBF 2: IOADIR.DBF 3: IOADISK.DBF 4: IOAFILE.DBF 5: IOJOB.DBF 6: IOSESS.DBF 7: IOTEXT.DBF -f attempts to open a named file: note -f option overrides default entry of '1' to '7' which is no longer required -o in conjunction with -f seeks to hex before parse default offset is 0
Use an integer value from '1' to '7' to list the fields in one of these files.
Additionally use the '-d' option to display the file data, record by record.
With the two options above you can see the configuration database contents. However this is a slightly more generic program. Structure definitions used at the beginning of these files is a free format database definition. The records in the structure definitions regions of the *.1-Step files described above use the same format. You can access and display these regions with the 1Scfg program if interested. Its a good way to explore or validate the logic I present above for the 1Srest program.
The -f and -o options allow the program to parse any suitable region in
any file. The name of the source file must be specified via -f which
overrides the normal specication. If the -f is used the digit '?' shown
in the usage message above is not required.
The following command would display the 'Disk' structure fields for IO2drv.bku 1Scfg -fIO2drv.bku -oa357 ie specify the file with -f and the start offset (less 0x20) with -o