1Srest Info

Last Update: 05/12/2019 see end of page

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

1Srest Program

Below are a couple snapshots of the Jan 2016 ver 1.00 of my 1Srest program. It may change a little with time, but seems pretty stable and your version should look a lot like this.

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 this had been a backup that spanned multiple media and did not contain a catalog the following display would have been seen:
1Srest version 1.00
Backup name: test8 2 disk uncompressed
Job 7 Backup Disk 1
no Catalog on this disk
----------------------------------------------------------------

See the separate document on the 1-Step format if you are interested in the details. However the Session data in data structure 7 tells the program how many data disks were used in the backup. If data compression was not used the files data in structure 3 is sufficient to extract the files. If data compression was used for the backup the Comp data in structure 4 is also required. The Disk (in structure 1) and Dir (in structure 2) data are required to create the path information for the 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...
'L' and 'A' are safe, and 'N' will extract the full backup per below.

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:
I have gotten it to successfully extract data from several small backup files. I have three sample multi-disk backups that use two media files and these also work successfully.

This is not very user friendly but I intend it to remain a tool that is used from the command line with just a few options to accomplish the task. It is quite possible no one is interested in this anyway.

A C source code distribution is available 1Srest-src.tar.gz.
I'd rather you built it yourself than trying to make more OS specific downloads available. Make files for the compilers and OS I have attempted are provided. The linux version has been tested fairly rigorously but you have to build it yourself. I built an MSDOS version with Microsofts CL compiler, but this only supports 8.3 style file names. It will list a backup's contents, but aborts if asked to extract a file with a longer file name. It turns out google sites won't allow *.exe files in the downloads area so I have provided an Zip archive of the Windows NT console application executables which should run under Win9x or WinXP and I suspect later versions of Windows. These executables were created with the freely available Open Watcom compiler.

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 to you if seen 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.

1Scfg Program

This is a much simpler program, but potentially useful so I included it. The test machine I used to create the sample *.1-Step files contains a configuration database which it apparently uses to save the interactive selections the user makes before creating a backup. In the 1Step backup version 5.3 it appears to only save the file selections from the most recent backup. It creates *.BKF and *.CDX files. For more information see 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 -f and -o options when used with a *.1-Step backup file displays all record data, rather than the summary provided by 1Srest with the -f and -v options. Unforunately when I wrote the 1Srest program I did not realize there was one more 0x20 byte structure definition header record ahead of the structure definition data. The first record is this header. The 2nd record always has the field name 'SERIAL' in the sample data I have seen. One could search the *.1-Step database for the key word 'SERIAL' to find where the structure definitions begin. The current 1Srest program displays where the field name 'Serial' occurs. The 1Scfg program needs the starting offset 0x20 bytes ahead of this as the arument of the -o command to list a region. In 1-Step output example above for Job 6, the 'Disk' definition region begins at 0xa377.

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


The following command would display the 'File' structure fields and record data for IO2drv.bku
'    
1Scfg -fIO2drv.bku -oe852 -d
ie add -d option to display the data in addition to the fields.

UPDATES

02/16/17  original release
12/18/17  ver 1.00 minor change to download source code archives.  Change linux
          makefile to remove test and debug program build instructions.
          Switch to *.zip archive for Win32 console applications in downloads.
03/11/19  ver 1.01 minor change to allow 64 bit compile 
05/12/19  ver 1.02 bug fix identified by David Schmidt where a multi disk file with
          no full files on last disk tried to access a NULL name pointer.