アカウント名:
パスワード:
1. 面倒だから2. バックアップ作業では生産できないので3. 壊れない・誤操作はしないと信じているから
さてどれでしょう？
# たぶん、全部かとw
4.tapeの容量と転送レートが足らん3TBのHDDがゴロゴロしてる今の時代にどうしろって言うんだ。一回のフルバックアップが瞬く間にTBオーダーになっちゃうんですが、業務時間外に終わる程クラウドって高速なものなの?
本当はフルバックアップがそれほど必要無いように物理実装を設計するものなんですけどね.
たとえば容量上, 大きな物になる過去の実績データなんかは, 基本的にread onlyで問題無いはずなんで, 適当なタイミングで別領域に吐き出して同時にバックアップしておくとかすれば, 以降はバックアップ不要とかになるんですけど.
おそらくはそうした事前のバックアップ設計を考慮せずに実装したシステムにおいて, 対応可能なバックアップパターンがフルバックアップしか存在していない. そしてフルバックアップは時間の制約などで物理的に不可能. よってバックアップはしない. というような流れになっているのではないかと.
それはあるepochからの差分バックアップに過ぎないと思うけど?
差分バックアップで済むならそれでいいんですよ. 問題は現実的にバックアップ/リストアができるか否かなんですから. フルバックアップは単なる手段なので, それを至上としてバックアップ自体を放棄するのは本末転倒です.
必要もないフルバックアップをするからダメなんです. さらに言えばバックアップをする必要もないデータまでバックアップしようとするからダメなんです.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
その答えは (スコア:0)
1. 面倒だから
2. バックアップ作業では生産できないので
3. 壊れない・誤操作はしないと信じているから
さてどれでしょう？
# たぶん、全部かとw
Re: (スコア:0)
4.tapeの容量と転送レートが足らん
3TBのHDDがゴロゴロしてる今の時代にどうしろって言うんだ。
一回のフルバックアップが瞬く間にTBオーダーになっちゃうんですが、業務時間外に終わる程クラウドって高速なものなの?
Re:その答えは (スコア:1)
本当はフルバックアップがそれほど必要無いように物理実装を設計するものなんですけどね.
たとえば容量上, 大きな物になる過去の実績データなんかは, 基本的にread onlyで問題無いはずなんで, 適当なタイミングで別領域に吐き出して同時にバックアップしておくとかすれば, 以降はバックアップ不要とかになるんですけど.
おそらくはそうした事前のバックアップ設計を考慮せずに実装したシステムにおいて, 対応可能なバックアップパターンがフルバックアップしか存在していない. そしてフルバックアップは時間の制約などで物理的に不可能. よってバックアップはしない. というような流れになっているのではないかと.
Re: (スコア:0)
それはあるepochからの差分バックアップに過ぎないと思うけど?
Re:その答えは (スコア:2)
差分バックアップで済むならそれでいいんですよ. 問題は現実的にバックアップ/リストアができるか否かなんですから. フルバックアップは単なる手段なので, それを至上としてバックアップ自体を放棄するのは本末転倒です.
必要もないフルバックアップをするからダメなんです. さらに言えばバックアップをする必要もないデータまでバックアップしようとするからダメなんです.