Hello all, we would like to use hotcopy to backup our 3.60 database on a unix (AIX) machine, the database comprises of 4 x 2048 MB raw devices (/dev/rdb1 - /dev/rdb4). We have disk space in the machine available, and the whole backup process works perfectly. Only BIG problem is, that the resulting hotcopy target files cannot be linked together as a new database. 
I can start the server on aix with database=/rdb1copy/rdb1+ … +/rdb4copy/rdb4" (note: /filesystem/file+/filesystem/file …) without errors, but if I connect from a client, it says “The filesize on disk differs from the file size stored in the file itself …”, basically telling me I cannot use the copied database. OK, true, if backing up database parts that are raw devices via hotcopy, the resulting files on a filesystem differ from the original raw device file in size (2097152 KB raw devices make 2097664 KB files, due to file system overhead or what). Now I´m no AIX guru, and I understand that hotcopy can only use directories on filesystems as target container of the database part copies. Leads to three questions: Is it possible under AIX to manipulate the target file system (block size, allocation size, stripe size) to get the hotcopied files to the same size as the raw devices ? If not: Is it in any way possible to get hotcopy to write to (exact same size) raw devices (e.g. via a symbolic link ???) ? If not: Is it in any way possible to work around this client side file size check (by telling the server “your DB parts are now bigger, now sit down and shut up” ;-))) ? If the answer to the latter is still no, hotcopy would be useless for unix with raw devices installations - no restore means no backup at all ;( Last resort: I do not really have to dd the hotcopied files back into raw devices, do I ? This would render the cc useless … Thanks for all advice, folks Best regards, cruiser
Update: Seems like noone of you guys is using AIX no more is it ?? With THIS amount of replies ;-)) I placed a call with Navision, they currently investigate the issue in DK - however, they don´t seem to have had this raw device / hotcopy problem ´til now. Any comments from you guys still welcome, though !! TIA, cruiser
Me myself again … Seems like DK was able to reproduce the behaviour of hotcopied raw devices. As far as I understand DK´s answer it´s indeed simply not possible to use raw devices hotcopied onto file systems as a replacement database in case of restore, and either not possible to hotcopy raw devices to raw devices. They told us they plan to change the help files and documentation of hotcopy respectively, but no effort to correct the behaviour will be taken. UNIX installations must stick with an fbk for backup. IMHO DK didn´t realize the severe impact on UNIX installations - raw devices are (well, WERE we must say by now…) the measure of choice to get Navision on UNIX fast as lightning. Sure disks are much faster nowadays, so I can gain the same performance on filesystems as I got out of raw devices in earlier days. But we do IMHO waste valuable performance protential here - raw devices on modern very fast hard disks are still faster than filesystems on the same disks. Guess we will have some mean conversations on the issue with our customers soon …
Hi Christian! I just post this to avoid that this thread becomes a lonesome “Single-User-Thread” [:D] So, you’ll have hard discussions with your customer about this HotCopy-issue, but think of the discussions, when MBS stops supporting UNIX at all [xx(] … (when) will this happen … who knows ??? cu Jörg
Just to close this topic: 22-08-2003/Answer from DK: Thanks - your comments have been received and evaluated. We have evaluated this issue and have concluded that it will not be corrected in this or coming releases. Seems that servers on UNIX have no future …
Seems like a standard answer for all bugs 
Hi, in association with our customer we found a workaround for the restore problem which works fine within our specific situation as far as we can see now: it is possible to “cat” the data from the resulting hotcopy files on filesystem back into raw devices - into the same raw devices the hotcopy originated from, or into different raw devices. The target raw devices for the cat job only have to be big enough to enclose all the blocks from the hotcopy backup files. Syntax is sometheing like “cat /filesystem/hotcopyfile > /dev/rawdevice” - with more than one database part you can launch several cat jobs in different shells to get it done parallel to save time. Only nasty bit: a consistency check on the logical structure of the database blocks is of course not done by cat - expect to see the scary “Rebuilding free block list” message in Navision once the first client connects to the restored DB… so be warned and use the workaround on your own risk. We do not guarantee for the workaround to be reliable at all or possible in all environments. anyway, we did quite some backups and restores using the workaround now and didn´t fall flat on our face yet … I would be pleased if some Navision tech guy or girl could confirm on the workaround, but have no response whatsoever yet. Regards, C. Krause