JP1/AJS3の退避ボックスを整理していると、

「もう不要だから、このディレクトリごと消してしまえばいいのでは？」

と思うことがあります。

例えばLinux/UNIX環境で、

rm -rf /var/opt/jp1ajs2/backup/schedule/BACKUP01

のように、退避ボックス用ディレクトリをOSコマンドで直接削除するケースです。

しかし、これは注意が必要です。

JP1/AJS3の退避ボックスは、単なる「ファイル置き場」ではありません。

退避ファイルと、それを管理するための情報がセットで存在しています。

そのため、

本来 ajsbkudel で削除すべき退避情報を、先にOS側からディレクトリごと消してしまうと、JP1/AJS3から見た管理状態と、実際のファイル状態が食い違う可能性があります。

この記事では、

なぜ先にディレクトリ削除すると危険なのか
どんな不整合が起きる可能性があるのか
その後に ajsbkudel を実行したらどうなる可能性があるのか
やってはいけない復旧方法
実際に確認すべきポイント
再発防止策

を詳しく整理します。

まず結論

退避ボックスを完全に削除したい場合、本来の順序は次のように考えるのが安全です。

JP1/AJS側で削除
    ↓
ajsbkudel -n BACKUP01
    ↓
OS上に空ディレクトリが残っていれば確認
    ↓
必要ならrmdir

つまり、

ajsbkudel -n BACKUP01

を先に実行します。

その後に、残ったディレクトリが空で不要なら、

rmdir /var/opt/jp1ajs2/backup/schedule/BACKUP01

とします。

逆に、

OS側でディレクトリ削除
    ↓
JP1/AJS側の削除処理

という逆順にすると、状態によっては不整合やエラーにつながる可能性があります。

退避ボックスは単なるフォルダではない

JP1/AJS3の退避ボックス配下には、例えば次のようなファイルがあります。

BACKUP01/
├─ .ajsbkup
├─ 0001
├─ 0002
├─ 0003
└─ 0004

ここで、

は退避ファイルです。

そして、

.ajsbkup

は退避情報管理ファイルです。

つまり、JP1/AJS3の退避機能は、

退避ファイル
＋
退避情報管理ファイル

の組み合わせで管理されています。

このため、OS上からディレクトリごと消してしまうというのは、

退避データだけでなく、その管理情報も一気に破棄してしまう操作

になります。

何が問題なのか

一番大きな問題は、

JP1/AJS3が想定している削除手順を通らないこと

です。

本来 ajsbkudel を使用すれば、JP1/AJS3は退避ボックスや退避ファイルを「削除処理の対象」として認識し、製品仕様に沿って処理します。

しかし、

rm -rf BACKUP01

のようにOS側から消してしまうと、JP1/AJS3はその削除処理に関与しません。

その結果、

JP1/AJS3が認識している状態

と、

OS上の実体

が一致しない可能性があります。

問題1：ajsrestoreで参照できなくなる

例えば削除前には、

ajsrestore -t -n BACKUP01

で内容を確認できていたとします。

しかし、OS上から、

rm -rf BACKUP01

を実行すると、当然ながら退避ファイルも管理ファイルもなくなります。

その後、

ajsrestore -t -n BACKUP01

を実行しても、

退避ボックスが存在しない
管理情報を読めない
対象退避ファイルを取得できない

といった状態になる可能性があります。

つまり、

回復可能だったバックアップを自分で破壊してしまう

ことになります。

問題2：ajsbkudelが正常に完了しない可能性

次に考えられるのが、

「先にディレクトリを消してしまったけれど、そのあと ajsbkudel を実行すれば帳尻が合うのでは？」

という考えです。

例えば、

rm -rf /var/opt/jp1ajs2/backup/schedule/BACKUP01

を実行したあと、

ajsbkudel -n BACKUP01

を実行するケースです。

しかしこのとき、JP1/AJS3が必要とする退避情報管理ファイルや退避ファイルがすでに存在しません。

そのため、

対象退避ボックスが見つからない
退避情報管理ファイルを読めない
削除対象を認識できない
エラー終了する

といった可能性があります。

つまり、

「後からJP1コマンドを実行すれば元に戻る」とは限りません。

問題3：一部だけ削除した場合はさらに厄介

ディレクトリごと消すよりもさらに厄介なのが、

rm 0002

のように、一部の退避ファイルだけを直接削除してしまった場合です。

例えば元の状態が、

BACKUP01/
├─ .ajsbkup
├─ 0001
├─ 0002
└─ 0003

だったとします。

ここで、

rm BACKUP01/0002

とすると、

管理情報上
→ 0002が存在している

OS上
→ 0002が存在しない

という状態になる可能性があります。

この状態では、

管理情報
≠
実ファイル

となります。

こうした不整合は、ディレクトリ全削除よりも分かりにくいことがあります。

見た目では、

0001
0003

が残っているため、一見正常そうに見えるからです。

問題4：.ajsbkupだけ残る、または消えるケース

さらに、

.ajsbkupだけ残る

あるいは逆に、

.ajsbkupだけ消える

という状態も考えられます。

例えば、

退避ファイルはある
管理ファイルがない

という状態です。

この場合、物理ファイルが存在していても、JP1/AJS3がその内容を正しく認識できるとは限りません。

逆に、

管理情報はある
実体ファイルがない

という状態も問題です。

つまり重要なのは、

退避ボックスはディレクトリの中身全体で一つの管理単位

と考えることです。

問題5：誤って別の退避ボックスまで消す危険

rm -rf の怖いところは、JP1固有の問題だけではありません。

単純にOS操作として危険です。

例えば、

rm -rf /var/opt/jp1ajs2/backup/schedule/BACKUP01

のつもりが、

rm -rf /var/opt/jp1ajs2/backup/schedule/*

とすれば、退避ボックス全部を削除する可能性があります。

さらに、パス指定を間違えると、もっと広範囲を消す危険もあります。

そのため、

JP1/AJSの管理領域
＋
rm -rf

という組み合わせは、できるだけ避けた方が安全です。

問題6：削除したあとに「何が消えたか分からない」

ajsbkudel を使う場合は、

どのボックスを削除したか
どの退避ファイルを削除したか

がコマンドとして明確です。

例えば、

ajsbkudel -n BACKUP01 0001

なら、

BACKUP01の0001を削除

と分かります。

一方、

rm -rf BACKUP01

では、

.ajsbkup
0001
0002
0003
その他ファイル

を一気に消します。

あとから、

「どの退避番号があったか」

「何が回復できたはずなのか」

を確認しようとしても、情報がなくなっています。

問題7：復旧に必要な情報そのものを失う

災害時や設定変更時に、

変更前へ戻したい

となったとき、

退避ボックスは非常に重要です。

しかし、その退避ボックス自体を誤ってOS操作で削除してしまえば、

本来の復旧手段そのものを失う

ことになります。

例えば、

本番ジョブネットを修正
↓
問題発生
↓
退避ボックスから戻そうとする
↓
実は掃除のつもりで削除済み

という事故です。

そのため、退避ボックスの削除は単なるファイル整理ではなく、

復旧手段を破棄する操作

と考えた方がよいです。

では、誤って先にディレクトリを消したらどうするか

ここで重要なのは、

慌てて適当なファイルや空ディレクトリを作り直さないこと

です。

例えば、

mkdir BACKUP01

として、

「ディレクトリ名だけ戻せばよいのでは」

と考えるのは危険です。

なぜなら、

空のBACKUP01

を作っても、

.ajsbkup
0001
0002
...

は戻らないからです。

つまり見た目だけは元に戻りますが、退避情報としては別物です。

空ディレクトリを作り直しても復旧にはならない

例えば、

mkdir /var/opt/jp1ajs2/backup/schedule/BACKUP01

としただけでは、

BACKUP01/

という空ディレクトリができるだけです。

これは、

元の退避ボックス

ではありません。

元の退避ボックスは、

BACKUP01/
├─ .ajsbkup
├─ 0001
├─ 0002
└─ 0003

だったからです。

したがって、

ディレクトリ名を再作成することと、退避情報を復旧することは別です。

バックアップがあるならOSバックアップから戻す選択肢

もし、退避情報ディレクトリ自体を、

ファイルシステムバックアップ
スナップショット
VMバックアップ
ストレージバックアップ

で保存しているなら、そこから復元できる可能性があります。

ただしこの場合も、

対象JP1/AJS3環境の状態と整合性を確認してから戻す必要があります。

単純にバックアップから、

BACKUP01

だけコピーすれば必ず正常になるとは限りません。

運用条件やJP1/AJS3のバージョン、稼働状態によって確認が必要です。

まず確認すべきこと

誤って削除してしまった場合は、最低でも次を確認します。

1. 何を削除したか
2. いつ削除したか
3. ajsrestoreでどう見えるか
4. 実ファイルを確認
5. JP1/AJS3ログ・メッセージを確認

1. 何を削除したか

例えば、

退避ボックス全体

なのか、

0001だけ

なのか、

.ajsbkupだけ

なのかを確認します。

2. いつ削除したか

削除前後で、

JP1/AJS3の操作
バックアップ取得
リストア
ジョブネット変更

などが行われていないか確認します。

3. ajsrestoreでどう見えるか

ajsrestore -t -n BACKUP01

を実行して、JP1/AJS3からどう見えているか確認します。

エラー内容も重要です。

4. 実ファイルを確認

例えば、

ls -la /var/opt/jp1ajs2/backup/schedule/BACKUP01

で、

.ajsbkup
0001
0002

などが残っているか確認します。

5. JP1/AJS3ログ・メッセージを確認

エラーが出ている場合は、メッセージIDを控えます。

JP1製品では、

KAVSxxxx

などのメッセージIDが表示されることがあります。

これを公式マニュアルで確認します。

「消してしまったからajsbkudelを実行」は慎重に

例えば、

rm -rf BACKUP01

を実行したあと、

ajsbkudel -n BACKUP01

とすれば綺麗になる、と考えるのは危険です。

削除対象の情報そのものがなくなっているため、

ajsbkudelが何を見て削除するのか

という問題があります。

したがって、

OS側を壊したあとにJP1コマンドを実行すれば自動修復される、とは考えない方がよいです。

「空フォルダを作ってから削除」も万能ではない

例えば、

mkdir BACKUP01
ajsbkudel -n BACKUP01

という方法も、一般的な復旧手順として扱うべきではありません。

理由は、

空ディレクトリ

と、

元の退避ボックス

は同じではないからです。

元の退避情報管理ファイルがなくなっている以上、製品が期待する状態ではありません。

したがって、

ディレクトリを再作成してコマンドを通す、という方法を安易に標準手順として使わない方が安全です。

本当に重要な退避だった場合

もし削除した退避ボックスが、

本番変更前

や、

障害復旧用

の重要バックアップだった場合は、自己判断で操作を重ねるより、

OSバックアップ
VMスナップショット
ストレージスナップショット
ファイルシステムバックアップ
JP1/AJS3の別バックアップ

が残っていないか確認する方が先です。

操作を重ねるほど、復旧可能性を下げる場合があります。

OS側を消す前に必ずやるべきこと

削除前には、

ajsrestore -t -n BACKUP01

で中身を確認します。

そして、

ajsbkudel -n BACKUP01

を実行します。

その後に、

ls -ld /var/opt/jp1ajs2/backup/schedule/BACKUP01

で確認し、

空ディレクトリが残っているなら、

rmdir /var/opt/jp1ajs2/backup/schedule/BACKUP01

とします。

この順序なら、

JP1/AJS側
↓
OS側

という自然な流れになります。

正しい削除順序

整理すると、

1. 退避内容を確認
   ↓
ajsrestore -t -n BACKUP01

2. 不要であることを確認

3. JP1/AJS3のコマンドで削除
   ↓
ajsbkudel -n BACKUP01

4. OS上の残存ディレクトリを確認

5. 空なら必要に応じてrmdir

です。

逆順は避ける

避けたいのは、

1. rm -rf BACKUP01
2. あとからajsbkudel

です。

この順序は、

実体を先に破壊
↓
製品側に後から処理させる

という形になります。

管理情報を持つ製品では、このような操作順序は基本的に避ける方が安全です。

特に本番環境では「rm -rf禁止ルール」も有効

運用ルールとして、

JP1/AJS退避領域では
rm -rfを原則禁止

としてしまう方法もあります。

例えば、

削除はajsbkudelのみ
↓
残った空ディレクトリだけrmdir

というルールにします。

これなら誤操作リスクをかなり減らせます。

退避領域を一般ユーザーに書き込みさせない

さらに安全にするなら、

退避情報ディレクトリ

に対して、不要なユーザーが自由に削除できないようにします。

例えば、

所有者を限定
グループを限定
sudo経由だけで操作
運用ユーザーだけ書き込み可能

とします。

人間の注意だけに頼るより、

OS権限で事故を防ぐ

方が安全です。

削除前に一覧をログ保存する

もう一つおすすめなのが、

ajsrestore -t -n BACKUP01 > BACKUP01_before_delete.txt

です。

削除前に中身をログとして残しておけば、

何を消したか

をあとから確認できます。

さらに、

ls -la /var/opt/jp1ajs2/backup/schedule/BACKUP01 \
  > BACKUP01_oslist_before_delete.txt

も残しておけば、物理ファイル情報も記録できます。

運用手順にするとこうなる

例えば、本番運用では次のようにします。

【退避ボックス削除手順】

1. 対象ボックス確認
2. ajsrestore -tで中身確認
3. 出力をログ保存
4. 保管期限確認
5. 作業責任者確認
6. ajsbkudel実行
7. 結果確認
8. 残存ディレクトリ確認
9. 空ならrmdir
10. 作業ログ保存

これだけでも事故リスクはかなり下がります。

もし既にrm -rfしてしまった場合の考え方

まとめると、

rm -rfしてしまった
↓
慌てて空フォルダを作らない
↓
追加の削除操作を止める
↓
何を消したか確認
↓
ajsrestoreの結果確認
↓
OSバックアップの有無確認
↓
ログ・メッセージ確認
↓
必要ならサポート判断

という流れが安全です。

重要なのは、

状態が分からないまま操作を追加しないこと

です。

「rmで消えているからもう問題ない」は危険

OS上でファイルがなくなれば、

見た目上はきれい

になります。

しかし、

JP1/AJSとして正常な削除だったか

は別問題です。

特に管理情報を持つ製品では、

OS上で存在しない
＝
製品上でも正常に削除済み

とは限りません。

まとめ

JP1/AJS3の退避ボックスを削除する場合、

OSコマンドでディレクトリを先に削除するのは避けた方が安全です。

本来は、

ajsrestore -t -n BACKUP01

で内容を確認し、

ajsbkudel -n BACKUP01

でJP1/AJS3側から削除します。

その後、必要なら、

rmdir BACKUP01

で空ディレクトリを削除します。

一方、

rm -rf BACKUP01

を先に実行すると、

退避ファイルを失う
退避情報管理ファイルを失う
ajsrestoreで参照できなくなる
ajsbkudelが正常に処理できない可能性がある
管理情報と実体の不整合が発生する可能性がある
本来使えた復旧ポイントそのものを失う

といった問題につながる可能性があります。

特に重要なのは、

OS上のディレクトリと、JP1/AJS3の退避ボックスは完全に同じ意味ではない

という点です。

そのため、退避ボックスを削除するときは、

JP1/AJSコマンドで削除
↓
OS側は最後に整理

という順序を守ることをおすすめします。

もしすでにOSコマンドで削除してしまった場合は、

空ディレクトリを作り直したり、さらに削除コマンドを試したりせず、まず現状確認を優先する

ことが重要です。