Tape backup solutions for QNX6?

Hello.

I just finished looking on the web and did a search through the QNX
newsgroups regarding tape backup solutions for QNX6. We are going to be
purchasing a Dell PowerEdge server that has an internal tape drive connected
via a SCSI backplane, and so I was trying to figure out how I could perform
a backup of my code natively under QNX6.

I would like to know if anyone else is doing anything similar and what sort
of options are available for me.

Regards.

Rodney Lott

Rodney Lott <rlott@fct.ca> wrote:

I just finished looking on the web and did a search through the QNX
newsgroups regarding tape backup solutions for QNX6.

Last I heard, QNX 6 support for tape devices was non-existant. Which means
if you want to run a tape, you will have to connect it to a non-QNX6 machine
and backup over the network.

and so I was trying to figure out how I could perform
a backup of my code natively under QNX6.

fs-pkg will bite you in the ass on this one.
You will be able to backup just fine, but restores will completely fubar your system.
The reason for this is that tar and other utilites for creating backups have no knowledge
of fs-pkg and how it “virtualizes” files. That means that when you do a restore you
will cause EVERY SINGLE FILE to spill and be replaced with the backup version, which
now causes the virtualized files to become real files. In some cases, you won’t be
able to restore at all, if the file being restored lives in a directory that is also
virtual vis fs-pkg, then spilling a file to that directory may fail.

In terms of tape support and backups of QNX6 hosts, QNX6 just is not ready for prime
time.

Cheers,
Camz.

<camz@passageway.com> wrote in message news:all48i$gfs$3@inn.qnx.com

[snip]
fs-pkg will bite you in the ass on this one.
You will be able to backup just fine, but restores will completely fubar
your system.
The reason for this is that tar and other utilites for creating backups
have no knowledge
of fs-pkg and how it “virtualizes” files. That means that when you do a
restore you
will cause EVERY SINGLE FILE to spill and be replaced with the backup
version, which
now causes the virtualized files to become real files. In some cases, you
won’t be
able to restore at all, if the file being restored lives in a directory
that is also
virtual vis fs-pkg, then spilling a file to that directory may fail.

Okay, here’s a question: Does fs-pkg deal with the system files only? I
was planning just to merely back up development files in the home
directories and the CVS repository that we will set up, not any OS files.
Would these non-OS files also be spilled?

Rodney Lott

rlott@fct.ca sed in <all4mr$he6$1@inn.qnx.com>

Okay, here’s a question: Does fs-pkg deal with the system files only? I

Not always, but usually is if you’re using the stock QNX-provided packs.

was planning just to merely back up development files in the home
directories and the CVS repository that we will set up, not any OS files.
Would these non-OS files also be spilled?

No, your own files aren’t spilled.

Do a "pkgctl -i " and if it says something pkg, it’s under the
fs-pkg and restoring will spill it.


I presume QNX6.x is not prepared now for disk backups
(it’s an embedded OS, not a desktop OS) but
my suggestion is

  • reboot in another 6.x installation (CDROM boot will suffice)
  • backup the whole partition in raw form (dd if=/dev/hd0t77 of=backupfile)
    or
  • Press [space][F5] during boot, and drop into emergency shell
    (do NOT start fs-pkg)
  • Poke into /pkgs/base directly for the executable:
    = /pkgs/base/qnx/os/core-2.1.3/x86/bin/dd if=/dev/hd0t77 of=backupfile
    or
    = /pkgs/base/qnx/os/utils-2.1.3/x86/usr/bin/tar --one-file-system -cf /fs/backupfile /
    Emergency shell has limited capability so it’s only recommended
    for manual operation.


kabe

You will be fine if you only backup your own files, fs-pkg only deals with
those inside packages. For backup solution the only option right now is a
DVD-RAM drive. It is not bad option, media is about $10-$15 and capacity is
about 4Gb+ per side. Cheaper than tape actually I believe.

Any device should work, I can recommend Panasonic LF-D3x1 as it has best
seek time (important if you want to have filesystem on the media and backup
files selectively). I also tested Toshiba drives, they are slower but appear
to have better environmental specs and MTBF.

– igor

“Rodney Lott” <rlott@fct.ca> wrote in message
news:all4mr$he6$1@inn.qnx.com

camz@passageway.com> > wrote in message news:all48i$gfs$> 3@inn.qnx.com> …

[snip]
fs-pkg will bite you in the ass on this one.
You will be able to backup just fine, but restores will completely fubar
your system.
The reason for this is that tar and other utilites for creating backups
have no knowledge
of fs-pkg and how it “virtualizes” files. That means that when you do a
restore you
will cause EVERY SINGLE FILE to spill and be replaced with the backup
version, which
now causes the virtualized files to become real files. In some cases,
you
won’t be
able to restore at all, if the file being restored lives in a directory
that is also
virtual vis fs-pkg, then spilling a file to that directory may fail.


Okay, here’s a question: Does fs-pkg deal with the system files only? I
was planning just to merely back up development files in the home
directories and the CVS repository that we will set up, not any OS files.
Would these non-OS files also be spilled?

Rodney Lott

kabe@sra-tohoku.co.jp wrote:

  • reboot in another 6.x installation (CDROM boot will suffice)
  • backup the whole partition in raw form (dd if=/dev/hd0t77 of=backupfile)

I don’t reccomend this. There is a 2G limit on filesize, so this is only
useful for creating images of partitions that are <2G in size.

Cheers,
Camz.

kabe@sra-tohoku.co.jp wrote:

I presume QNX6.x is not prepared now for disk backups
(it’s an embedded OS, not a desktop OS) but

Embedded does not neccisarily mean small or resource constrained,
there are many examples of embedded systems that would require or
benefit from tape support.

Personally, I think QSS should correct this and add tape support
to QNX6.x

Cheers,
Camz.

Hey, thanks everyone for your replies. That has given me alot of food for
thought.

Regards.

Rodney Lott

<camz@passageway.com> wrote in message news:alqal8$b0k$2@inn.qnx.com

kabe@sra-tohoku.co.jp > wrote:

  • reboot in another 6.x installation (CDROM boot will suffice)
  • backup the whole partition in raw form (dd if=/dev/hd0t77
    of=backupfile)

I don’t reccomend this. There is a 2G limit on filesize, so this is only
useful for creating images of partitions that are <2G in size.

Cheers,
Camz.

camz@passageway.com sed in <alqal8$b0k$2@inn.qnx.com>

  • backup the whole partition in raw form (dd if=/dev/hd0t77 of=backupfile)
    I don’t reccomend this. There is a 2G limit on filesize, so this is only

Hm. Then you also can’t tar-backup the partition containing >2GB files
(at least onto qnx4 filesystem; should pipe out to something else?)

This could be a real gotchas when people start housing big projects
on self-hosted RTP considering backup…

kabe

Muhahahaha. Somebody noticed :stuck_out_tongue:
You can redirect tar to a RAW partition, that won’t have 2Gb limit. With
files there is no way, regardless of what FS you write to.

Somebody, kick QNX, it is time to wake them up.
– igor

<kabe@sra-tohoku.co.jp> wrote in message news:am0fad$n6i$1@inn.qnx.com

camz@passageway.com > sed in <alqal8$b0k$> 2@inn.qnx.com

  • backup the whole partition in raw form (dd if=/dev/hd0t77
    of=backupfile)
    I don’t reccomend this. There is a 2G limit on filesize, so this is
    only

Hm. Then you also can’t tar-backup the partition containing >2GB files
(at least onto qnx4 filesystem; should pipe out to something else?)

This could be a real gotchas when people start housing big projects
on self-hosted RTP considering backup…

kabe

kabe@sra-tohoku.co.jp wrote:

Hm. Then you also can’t tar-backup the partition containing >2GB files
(at least onto qnx4 filesystem; should pipe out to something else?)

Well, for starters, you can’t have files in a partition that are >2G,
I think the limit for a file is actually 2G - 1 or something. That aside,
as igor mentions, you CAN backup to a raw partition, which is also why
the whole DVD-RAM thing works (right igor?).

This could be a real gotchas when people start housing big projects
on self-hosted RTP considering backup…

In all honesty, this isn’t specific to QNX. Linux ALSO has a 2G file limit
within their filesystems. The difference, of course is that linux supports
tapes, and qnx6 does not.

Cheers,
Camz.

<camz@passageway.com> wrote in message news:am2cio$3gp$1@inn.qnx.com

kabe@sra-tohoku.co.jp > wrote:
Hm. Then you also can’t tar-backup the partition containing >2GB files
(at least onto qnx4 filesystem; should pipe out to something else?)

Well, for starters, you can’t have files in a partition that are >2G,
I think the limit for a file is actually 2G - 1 or something. That aside,
as igor mentions, you CAN backup to a raw partition, which is also why
the whole DVD-RAM thing works (right igor?).

You’re right about the limit, it is 2Gb. As of backup, if one wants to
backup to a filesystem it is usually because one wants to backup
individual files, rather than large consolidated tar archives (otherwise one
would rather use raw device because it is faster, especially in the case of
DVD-RAM). That makes the issues somewhat less important and ‘DVD-RAM thing
works’.

However it does limit options. When single size of DVD-RAM could hold
maximum 2.6Gb, it was almost moot point, but now they can hold twice that
much and gonna double their capacity yet again in short term future.

This could be a real gotchas when people start housing big projects
on self-hosted RTP considering backup…

In all honesty, this isn’t specific to QNX. Linux ALSO has a 2G file limit
within their filesystems. The difference, of course is that linux
supports
tapes, and qnx6 does not.

NTFS supports much larger files (i don’t even know how large, but they can
be larger than 4Gb). FAT32 supports files up to 4Gb. I don’t see why QNX
could not, especially since they are about to change filesystem to support
LFN anyway.

– igor