バックアップ on 或る阿呆の記

脱Dropbox再考: そもそも同期は必要か

Wed, 04 Mar 2026 00:00:00 +0900

この前Dropboxのプレミアム会員の権利が終わった。2020年から6年続けていたらしい。2020年に31,680円で3年分まとめ買いしたのと、2023年にAmazonで29,800円で購入していた。今はもうこの価格で出ることはないだろう。なので6万円ほど（月額約860円）だが、最後の1年はほとんど使っていなかったので、あながち得したともいえない。長期割引の罠にはまってしまった感じはする。正直なきゃないでよかった。

ただ、Dropbox自体は嫌いなサービスではない。むしろ個人的には好きですらあった。最近アカウントBANの騒ぎがあったのを見た時はちょっと悲しかったけど、全体的には良いサービスだと思う。

Linuxでも使えるし、Macでは文字コード正規化問題のようなニッチだがクリティカルなところも対応していたし、スクリーンショット横取りなんかは気が利いていたし、カメラアップロードも便利だし、アプリの使い勝手もまぁ悪くないし、復元機能などはかなり強力で何度か助けられたし、なにより同期という単純ながら難しい課題の精度を着実に上げていた。

Dropboxほどの機能はOSSやNASでは恐らくだいぶ厳しくて、僕はQNAPのNASについてきたQSyncという同期アプリを今は使っているが、正直安定性はDropboxに及ぶべくもない。大量のファイルについて読み書きすると平然と取りこぼすので、あまり信用できない感じだ。OSSではNextcloudやSeafileもあるが、あまりマジメに試していないものの、運用者の記事を調べるとやはり苦労していそうな感じがある。

そこへいくと、業務として同期が必要なのであれば、Dropboxは安心して高いなりの仕事は任せられるのはそうだと思う。本当に必要ならね。

個人や中小規模において、同期に毎月1,500円払えるかと言われると、それはちょっとどうかな。正直900円くらいでも、よく払っていたなぁと思う。結局どこまでも経費だからねぇ。正直ほとんどオーバースペックと思われる。たいてい、少しの工夫でどうにかなりそうなんだよなぁ。

そして厳しくなるばかりのアカウントBANリスク。バックアップがわりになるというが、自宅が火災にあってデータ消失するリスクより、謎のアカウントBANでデータ消失するリスクのほうが現実的に高いだろうさ。ちょっと厳しいよなこれは。

考えてみると、本当に同期が必要なシチュエーションってもはやあまりないんだよなぁ。結局やりたいことは、コンピュータAでやった操作を、コンピュータBで続きができる、ファイルが分裂しないっていうことだと思う。これについて、アプローチとしてはクライアントサーバ型と、すべてのPCにばら撒く分散型があるわけだが、分散が適切な状況ってのはあまりない感じだ。ただDropboxが手軽だったら使っていた。

その手軽さは、ファイルという実体を直接操作できるところが大きい。しかし最近は、ファイルを直接操作することはあまりなくて、アプリケーション経由であることが多くなった。セルフホストが手軽になったことや、AIによってちょっとした自分用ツールをサクッと作れるようになったことが大きい。

そうすると、僕が「そもそも同期する必要あるか？」と疑問に思うようになったのは、ここ数年のAIの隆盛と、セルフホスト・自宅サーバに再び傾倒し始めたことが影響しているかもしれない。

Dropboxをはじめとしたクラウドサービスは、アカウントBANに象徴されるように、なんつーか健全な商売にしか使えないというか、自分のプライバシーを預けるにはあまりにも危なっかしい相手になってしまったし、ここらへんが転換期なのかもしれない。

<関連記事>

あわせて読みたい

DropboxでアカウントBANされた人がいるらしい

/dropbox-ban/

DropboxでアカウントBANされた人がいるらしい

Fri, 30 Jan 2026 00:00:00 +0900

オンラインストレージ・サービスで垢BANされた人の話は定期的に流れてきますが、今回はDropboxのようです。

Dropboxのアカウントが規約違反により突然BANされて博士課程の研究データの一部や趣味の写真などが取り出せなくなった…問い合わせメールも全て無視されている - Togetter

垢BANによって、博士課程のデータや趣味データの一部が取り出せない自体になっているようです。問い合わせは無視されているとこのこと。これはたいへん。

Dropbox、お前もか

いつものことではありますが、第一印象としては「Dropboxか」ではありました。垢BANというのは極めて重大なペナルティで（実行する当事者にその自覚がないようですが）、ビッグテックが片手間でやっているGoogle DriveやOneDriveではちょくちょくきくものの、オンライン・ストレージがコアビジネスで、それ一本でやってきたDropboxではあまり聞いたことがなかったからです。

まぁまったく初めて聞いたということはなく、以前に調べたときも、Dropboxで垢BANされた人の話は見つけることができました。その人もデータが取りだせなくて困っていました。結局解決されたのかどうか、記憶になく、保存しておけばよかったと思います。記事は一期一会（なのでこうして記事にしている）。

一発BANが企業の合理

なぜこうもカジュアルにデータを凍結するのか、ユーザからは不可解ですが、企業側からすると、これがもっともコストが低いと判断されているのでしょう。

いちいち警告すれば、本当に悪意あるユーザが相手だったときに手の内を明かすことになります。また、担当者をつけるのはコストです。アルゴリズムで判断したら悪即斬、これがもっとも合理的、ということですね。ユーザからすれば横暴かつ不合理でしかありませんが。

スレッド内にもあったとおり、本来であれば日本国憲法に規定された財産権(第29条)の侵害にあたると考えられます。しかし相手は米国の企業であり、デジタールデータであり、また利用規約に同意したという建前があります。実態を考慮すると、法律は善意のユーザの味方になっていません。完全に、大きなもの、企業の味方になっています。法治国家（笑）

対策: クラウド最小権限

根本的な対策は存在しません。

個人的には「クラウドを使う金でNASを買え」と言いたいところですが、それだとあんまりなので、「利用を最小限にとどめる」くらいにしておきましょうか。具体的には、以下の徹底です。

インターネットを介した同期が必要なファイルのみ
ローカルのバックアップとして位置付ける
必要なデバイスにのみインストールする

多分これだったら無料枠で十分です。有料顧客になって機能をフル活用するほうが危険性が高いというバグみたいな仕様だから仕方ないですね。

オンライン同期を使わせたがってきますが、邪悪な企業にデータの本体を差し出す愚行をしてはいけません。

企業はユーザのことなんか考えていません。利益しか見てません。

データの保存は基本に忠実に

それではデータのバックアップはどうしたらいいのかという問題があるわけですが、大事なデータは3-2-1バックアップを実践しましょう。

3-2-1バックアップは、一言で言えば3つのコピーを2つ以上の媒体で、1つは遠隔地に、です。元データはSSD、バックアップはNASまたは外付けHD、そして1つは遠隔地に持っていく、という形になります。遠隔地について、クラウドサービスを使ってもいいですが、こういう事件があるのですから、私としては実家など信頼できるところに、暗号化のうえで置かせてもらう、のが一番良いのではないかと思います。

これは前時代的に思えるかもしれませんが、謎の基準でアカウントBANされる現時代よりはいいでしょう？未来時代はきっともっとひどいですよ。

重要なことは基本です。基本は変わりません。ITの世界は進化が早いなどと言われますが、あんなもんはマーケティングのポジショントークですよ。

ルールの源を考える：我々は力を行使できない

最後に、規約について。スレッドで、投稿者の方は「規約違反だからBANは仕方ない」と物分かりよく考えられています。

「規約に違反したのは仕方ないからアカウントの復帰は諦めてるけど、それとは別にデータには財産権があるからダウンロードリンクを発行してほしい」とメールを送っても返信なし。選択的同期でローカル端末から消えてて救出できないデータが大量にあるんですが、なんとかなりませんか

— https://x.com/fukusanity/status/2016445862315213287?s=20

規約は確かに強力な建前です。しかし一方で、財産権というより強力な建前が通用しない現実にも直面されたことと思います。メールを送っても音信不通であったとのことです。ではどうしたらいいのでしょうか？アメリカの企業に日本国憲法に基づいて法的措置をすれば？いやまさか。

しかし今回、SNSで大いに取り上げられ、トレンドにもなったことで、騒ぎが大きくなったためか、この投稿にDropboxからリプライがついていました。データを救済できる道筋がついたのかもしれません。

これは我々に、ルールとは何かを強く考えさせます。折しも、アメリカがトランプ大統領のもとに国際法なにそれおいしいの言わんばかりの蛮行で、しかし着実に成果を出し、また誰も実質的に文句が言えていない、という状況が思い出されます。これでは、ルールとは弱いものだけが守り、強いものだけが守らなくて良い特権にさえ見えてきます。

これについて、私はルールには裏付けがある、と考えております。そのもっともわかりやすい裏付けが暴力です。これは別に特殊な考え方ではないでしょう。私は専門ではありませんが、社会契約論とか好きな人たちはだいたい国家の暴力の独占についてそういうことを言うんじゃないですか。

しかし、何も直接的な暴力だけではありません。つまり、 「筋の通らないことをするならこちらにも考えがある」という何かができるのか、ということにあります。たとえば商売であるならば、「そんな不義理をするなら、君との取引はこれまでだ」というのは力の行使になり得ます。ですが、DropboxをはじめSaaSに対し、月額1000円ばかりのユーザが取引停止をちらつかせたところでなんの抑止力にもならないことは明らかです。

では、法的措置。これも通常あるべきですが、現実的に市民の手に負えません。特に今回は外資が相手です。

ここで、SNSが最後の武器となります。「Dropboxにこんな仕打ちを受けた」というツイートがSNSの世界でトレンドになるほど広まるのは、これは企業にとって確かに困るわけです。ツイートをバズらせて初めてようやく、企業が話し合いの土俵に立ちます。バズらないと絶対にいじめ（暴力）を調査しない学校と一緒です。今をときめくIT企業も役所と一緒なんです。

いったいぜんたい、こんなことでいいのかと義憤に駆られますが、現実はこうなっております。

私としては、この力の非対称性を考えると、今一度「所有すること」の意味について市民一人一人が考え直すべきときがきたと思います。

結論：セルフホストがすべてを解決する

<関連>

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

/data-self-hosting/

Homebrew環境におけるGiteaのエクスポート：brew services start giteaとgitea webの違いがわかる男

Fri, 12 Sep 2025 00:00:00 +0900

なんか色々躓いたので、復元は後日にして、今回はエクスポートについてのみ。なんか色々ハマった。

具体的には、最初に gitea web で動かして、その後 brew services start giteaのほうがいいやんけと思ってそっちにしたんだが、その後バックアップ手順を確認しようと gitea dumpしたら、なぜか最初に gitea web で作ったほうがバックアップされる。よく見たら実行プログラムのパスが違っており、それによって読み込まれる設定ファイルが違ったと思われる。

環境

M2 Pro Mac mini, Intel Mac mini 2018
macOS 14.7.7 (Sonoma)
gitea 1.24.5 (via brew)
brew services start giteaで起動

giteaが分裂した。

公式: Backup and Restore | Gitea Documentation

公式にあるとおり、エクスポートはコマンドが用意されており、 gitea dump -c /path/to/app.iniに尽きる。ただここで問題は、 gitea のパスとコンフィグファイルのパスである。

たとえばコイツを見てくれ。コイツをどう思う？

> ps aux | grep -i gitea
user 19745 0.7 0.5 412867040 168992 ?? S 7:38PM 0:00.56 /opt/homebrew/opt/gitea/bin/gitea web --work-path /opt/homebrew/var/gitea

> which gitea
/opt/homebrew/bin/gitea

すごく……パスが違います……。

giteaコマンドは /opt/homebrew/bin/giteaなんだが、brewで起動する giteaは /opt/homebrew/opt/gitea/bin/giteaという。

ただ、こいつらはバイナリとしては同じ臭い。

> ls -la /opt/homebrew/bin/gitea 
/opt/homebrew/bin/gitea@ -> ../Cellar/gitea/1.24.5/bin/gitea
> ls -li /opt/homebrew/Cellar/gitea/1.24.5/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 

> ls -la /opt/homebrew/opt/gitea/bin/gitea
/opt/homebrew/opt/gitea/bin/gitea*
> ls -li /opt/homebrew/opt/gitea/bin/gitea
251898619 -r-xr-xr-x 1 user admin 107386178 Aug 14 01:34 /opt/homebrew/opt/gitea/bin/gitea*

なので、実行プログラムのパスで、読み込まれる暗黙のコンフィグパスが異なったものと思われる。brewで起動した方は、–work-pathを指定しているね。ここにコンフィグファイルもある。

パスの違いがわかる男

ということで、work-pathも踏まえて、dumpのコマンドは以下となる。停止できるなら停止したほうが安全だね。

brew services stop gitea
gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini
brew services start gitea

ファイル名に日付けを入れるなら

gitea dump -c /opt/homebrew/var/gitea/custom/conf/app.ini -f gitea-backup-$(date +%Y%m%d-%H%M%S).zip

こいつをunzipすると以下のような感じだ。

gitea-backup-YYYYMMDD-HHMMSS.zip
├── app.ini # 設定ファイル
├── data/ # アプリケーションデータ
│ ├── attachments/ # 添付ファイル
│ ├── avatars/ # アバター画像
│ ├── gitea.db # データベースファイル
│ └── ...
├── repos/ # Gitリポジトリ
│ └── user/repo.git/ # 実際のGitリポジトリ
└── gitea-db.sql # データベースダンプ

このうち、app.iniは違うマシンでやるときにはゴチャゴチャと手動調整しないといけなくなると思う。ネットワーク環境とか、リポジトリのパスとか、環境によって変わるはずなので。特にMacからLinux……とかやるとね。

所感

サクッとできるだろうと思ったら思いのほか躓いた。LLMは永遠に存在しないパスを教えてくれるので10倍疲れた。インフラ周りになると途端に無能になるLLMさんェ……。それでもいるだけマシだろうと言われたらそうかもしれないんだが、昔は検索したら同じようなところで躓いた人の記事が出たもんだけどなぁと思ってしまう。

まぁ今回は brew services あんまり使ったことなかったから、それでちょっとハマったよね。自分でplist作ったら問題なかったんだろうけど。

今回はMacかつHomebrew経由特有の問題があったので、Dockerコンテナなら環境の共通化は多少できると思う。けど、ネットワーク環境とかはやっぱり違うだろうし、 app.iniは同一マシンでの復元以外は基本的に編集しないといけないんじゃないかな。となると、編集項目が1箇所でも5箇所でも、編集しないといけない時点で大して変わらないし、Docker使うと docker-compose.ymlの管理もあるから、どっちがいいかはちょっとわかんないね。

疲れたので、復元はまた後日。

<関連記事>

あわせて読みたい

脱GitHubに向けて：Giteaを試し始める on Mac

/github-gitea-1/

劣化の早いCrucial CT2000BX500SSD1のそのまた後

Thu, 11 Sep 2025 13:04:36 +0900

こんな記事を読んだ。

Crucial BX500（2025）レビュー：酷い性能でも競争がなければ売れるSATA SSD市場 | ちもろぐ

これを見て、そういえばうちも使っていたなぁと思い出した。というか今も使っている。CrystalDiskInfoで見る健康寿命がゴリゴリ減っているなぁと思う今日この頃。この数値をみるたびに、僕の人生でcrucialはもういいやと思う。まぁモノによっては評判いいのがあるのはわかるが、生涯に購入するSSDなんてそう多くないのだし、あえて購入しようとは思わんね。

前回記事

あわせて読みたい

異常に劣化が早かったCrucial CT2000BX500SSD1のその後

/crucial-sata-ssd/

2024年7月末の時点で77%だった。2023年9月初頭、つまりちょうど今から2年前の時点では83%のようだった。

あれから一年、あるいは数年

あれから一年、77%から今は64%になっている。うーん。購入日は2023年2月だから、2年半か。

今回については、けっこう本当に理由がわかっていない。やはりDropboxのディレクトリにしているからなんだろうか。以前ほど激しいファイルの入出力はしていないとはいえ、そこそこある。とはいえ、一年で-13%となると、この調子だとあと5年もつんだろうか、という感じだ。劣化が早くなっているのならさらに危うい。

まぁ数値は目安として、実際本当に使えなくなるタイミングがいつかは謎だけど、それにしてもやっぱり不安にはなるなぁ。購入から2年半だからひとまず3年は使えるかね。しかしデータ用でこれだから、システム用に使ってたらもう死んでそう。

SSDより先にPCが逝く説もある。このSSDを搭載したPC自体が2018年春に買った物で、もう7年以上使われているわけだから、PCが先に逝くのはありえる。今さらSATA SSDを使い回すことはあまりないだろうから、PCと一緒にお役御免になるだろう。と言いつつ10年以上前に買ったと思われるSSDを外付け化して使っていたりする。2TBのポータブルSSDはそれなりに価値もあるので、やはり使える限りは使いたい。

まぁまだ逝ってないので

しょうもない話は置いといて、コイツの寿命については先行きが不透明であり不安にさせられる。大丈夫なのか……。この一年を振り返ってみたが、Dropboxは確かにそれなりに負荷をかけるだろうし、まぁ使ってないことはもちろんないが、しかしねぇ……。このPCでDドライブの利用は限定的だし……ちょっとなぁ。とはいえ数万時間起動したなら、まぁ十分か……ハードディスクも壊れるとはきは壊れる。

しかしなぁ……。まぁ人生でSSDが逝ったのは何度かあるものの、やはり気分の良いものではないね。まぁまだ逝ったわけではないし、引き続け経過観察を続けていく所存。なんだかんだ言いつつ粘るかもしれない。

[itemlink post_id=“14824”]

FreeFileSync + FTP on Mac -> QNAP NASで文字コードも問題なくバックアップできている

Mon, 08 Sep 2025 02:38:51 +0900

FreeFileSyncは僕がバックアップで使っているGUIツールだ。無料でも使えるが、幾ばくを寄付することで寄付版になり、長いことお世話になっているから寄付版を手に入れた。

今はMac上のファイルを、FreeFileSyncで、プロトコルはFTPを使い、QNAPのNASに問題なくバックアップできている。これをわざわざ書いたのは、文字コードの正規化問題にずっと悩まされてきたからだ。

環境

M2 Pro Mac mini
- macOS 14.7.7
- FreeFileSync 14.4 寄付版
QNAP NAS TS-233
- QuFTP Service

NFCとNFD

Mac使いならば悩まされてきたであろう、Unicode正規化方式の違い。Windows/LinuxではNFC(Normalization Form Composed)が使われているが、Macでは何故かNFD(Normalization Form Decomposed)という方式が使われる。これによって何が起きるかというと、Macで作成した「がきぐげご.txt」をNAS(Linux)に転送して保存すると「か゛き゛く゛け゛こ゛.txt」になってしまい、アクセスできなくなったりなんだりするという、割と深刻な問題だ。

これに対応するため、昔rysncとか使っていた時には特殊なオプションが必要だったりなんだりして、色々と苦労している。

/30878779-2/

オンラインストレージのDropboxはなんとこれについて補修をしてくれているようで、あれは一時期Dropboxをバックアップ先に使っていた理由の一つであった。

この問題は普通の人にはかなりしんどい問題だと思うんだが、みんなどうしていたんだろうと思うものの、まぁ考えて見ると一般的な人は家庭に複数のOSでバックアップなどということにはならないのかもしれない。

MacはSMBつらいつらい

これは一時期、僕がNASをあまり使わなくなった理由の一つとも思えるが、その後なんやかんやあって、2023年7月よりまたNASを使うようになっている。数ヶ月後に控えている次のDropbox有料会員は契約更新しないつもりだ。

あわせて読みたい

QNAP TS-233

/qnap-ts-233/

いつの間にやら、SMBでNASとやりとりする限りは特に困らなくなっていた。Unicode文字列の扱いが良くなっているとかなんとか聞くが、詳細は知らない。ただ、とりあえず濁点問題は起きなかった。

なのでしばらくずっとSMBを使っていたのだけれど、これとは別個、MacのSMBクライアントはめちゃくちゃ遅いという問題があり、これはなんかもうずっと未だにどうにもならない。

あわせて読みたい

MacとReadyNAS 104の通信速度が遅い時の対処法(SMB)

/rnas104smbup/

この頃から悩んでいるんだけれど、多少マシにする方法はあれど、未だにどうにかなっていない。しかも不安定でしょっちゅう接続が切れる。

そうだ、FTP、しよう

ということで、非常にNASがバックアップ先として非常に使いづらい状況で、最近は外付けHDを引っ張り出してきてそこにバックアップなどもしていた。まぁこれ自体はNASを使っていようがいまいがやったほうがいいことではある。

ただまぁやっぱり面倒くさくて、NASへのもうちょっとどうにかならんかなぁと思っていたところ、ふと「ファイル転送ならFile Transfer Protocolでは？？？」と急に思い出した。

で、前述の文字コード問題などあるので、やや不安がありつつ、もう2025年なんだ頼む、という気持ちで、QNAPのNASでFTPサービスを立ち上げ（QuFTP Serviceというのがある）、FreeFileySyncからFTP経由で転送。とりあえず、データ転送速度は爆速。めっちゃFileをTransferしてくれてる……。

3分30秒足らずで8GBを転送してくれている。これなら十分に実用的。

問題は濁点問題だが……起きていない。普通に問題がない。これがFreeFileSyncとQuFTPあるいはQNAPのなんかのソフトウェア、どちらかあるいはどちらも頑張ってくれているのか、ちょっと調べた感じだとわからなかったのだけれど、とりあえずうまくいく。おー。

所感

ということで、なんかしらんがうまくいってますという身も蓋もない記事になり申した。どっかのタイミングで一度ちゃんと調べたい気はしつつ、とりあえずよかったよかった。

[itemlink post_id=“15811”]

脱Dropbox：NASの音楽ファイルをストリーミングで再生する試み

Sat, 30 Aug 2025 21:49:44 +0900

やろう、やろう、と思いながら、面倒臭くてずっとやらなかったNASの音楽ファイルをAndroidからストリーミング再生する環境をやっと構築した。ちょっと軽くランニングしてきた感じでは、十分使えているのではないかな、と思う。これでDropboxを使う大きな理由の一つをなくすことができたね。

はまりどころもあったので、そのうちにハウツー記事にしたいと思うが、今回はとりあえず所感をつらつらと。

ちょっとマニアックな構成

構成自体はちょっとマニアックな感じになってしまったかなと思う。

graph LR
subgraph Internet
android(Android)
cloudflare(Cloudflare)
end
subgraph Home
nas(NAS)
pc(PC)
end
android --> cloudflare
cloudflare -->|Cloudflare Tunnel| pc
pc -->|webDAV| nas

この時点で特に技術系ではない一般ユーザにはオススメできない構成になってしまっているのはまぁそう。といっても別に何かコード書くわけじゃないし、頑張ればできると思うけど。

元々、構成的にはそりゃ出来るだろう、とは思っていたものの、WebDAV使えてストリーミングとオフライン両方できるAndroidアプリあるのかな、とか、NASでWebDAVの設定どうするのかな、とか個別に調べないといけないことも多くて、なかなか進まなかった。あと家の回線がJ:COMなので、クソザコ上り回線で大丈夫かなぁと思ったのもある。

まーでも、多少手こずったけれど、とりあえずうまくいったかなぁ、という感じ。ただフォルダがたくさんあると一覧表示に時間かかるようで、これはスペックというよりネットワークの問題の気がする。このへんはもうちょっと整理がいるかな。

AndroidアプリはCloudBeatsを使った。有料オプションは1500円くらいだったかな。オプションは複数のクラウド接続とオフライン再生に必要だった。妥当な料金じゃないかな。サブスクじゃないなら全然いいよ。だいたいNASとストレージの代金からすれば誤差みたいなもんだし。NASはQNAPのTS-233。ドメインは元々取得していてCloudflareで管理している自分用ドメインを流用した。

[itemlink post_id=“15811”]

世界線の修正作業

まぁもうちょっとしばらく使い混んで使い勝手は調べる必要があるかな。フォルダも整理しなおさないといけない。iTunes時代の名残で、全アーティストのフォルダがフラットに並んでしまっているんだよね。それで阿呆みたいに長いリストになってるからさ。

ああiTunes、今にして思うと、僕にソフトウェアの進歩について強い疑念を抱かせた最初のアプリケーションだったかもしれない。毎度毎度、強権的な仕様変更に振り回され、頼んでもない新機能を見せつけられ、その癖出来たことが出来なくなり、そしてファイルが壊される。途中Apple Musicなんて契約しようもんならもう最悪なことになる。なった。

冷静に考えると、自前のライブラリを知らないサーバに置く必要はないし、ストレージが足りないならmicroSDを使えばいいし、microSDも挿せないならNASからストリーミングもあるし、別にプレイヤーを買ってもよかった。今でもiPodモドキはたくさん売ってるし。でもあの時は、なんかこれが未来なんかな、という気にさせられていたよね。実際このブログでもApple MusicとかiTunesで検索したら色々出てくるよ。懐かしい。

結果的には、間違えた世界線だったんだなと思う。こうしてフォルダの再整理に勤しまねばならないのがもうね。っていうか消失している曲とかもあるんだよな。MOTHERっていうゲームのアレンジサントラでやけに凝ったのがあったんだけど、マニアックかつオムニバスでアーティストが分散しているのもあって、なんか気がついたら曲が何曲か見当たらない。一番気に入っていた曲は幸い（？）残っていたので、買い直すのもなんだかなぁ、みたいになってる。やれやれだなぁ。

[itemlink post_id=“18951”]

まぁ今からでも少しずつなおしていくさ。

Dropboxに恨みはない

一応言うと、僕はDropboxに対しては案外と好印象だったりする。実際最近このブログではクラウドについて腐していることが多いが、その中でもDropboxに対して悪口めいたことは言ったことはないんじゃないかな。Dropboxは便利だし、非常にマニアックな文字コード問題の対応、Linux対応などもあって、かゆいところに手が届くサービスだと思う。価格も決して高すぎるとは思わない。安いとも思わないけど。

あわせて読みたい

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

/data-self-hosting/

いつだったか不本意なアカウントBAN事件について書かれた個人の記事を見て「Dropboxもあるかー」と思ったことはある。しかし、少なくとも僕はこれまでアレゲなファイルも置いてきたが特にBANされたことはなく、またされたところで別に大して困らないので、使い続けている。まぁ、三年契約しちゃって、契約期間がまだあるからさ。

まーでも、次の契約更新はないかな。別にDropboxに恨みはないけれど、クラウド、サブスクはもう嫌だっていう気持ちのほうが強い。僕自身はこの流れから脱せられているわけではないけれど、せめてプライベートではまず離れたいところだね。

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

Sun, 09 Mar 2025 13:13:11 +0900

クラウドという言葉が定着してもう10年以上経過する。僕はバズワードに過ぎないと思っていたのだが、思いのほか概念として定着したようだ。クラウドとはとどのつまり「他社にデータを預けても良い仕組み」そして「それをクールだとする社会的な思い込み」の総称だ。

本来、データを預けるのは多くの人にとって受け入れがたい仕組みである。データとは財産であり、その財産を他人に預けるなど正気の沙汰ではない。

狂気の沙汰を正気の沙汰に

実際、自分の財を第三者に預けるなど、本来的には狂気の沙汰だと思われるが、その狂気を正気ということにする商売はある。金融業なんかその典型だろう。狂気の沙汰を正気の沙汰とするために、彼らはありもしない信用を唱え、勝手なことはしませんよと言うわけだが、僕らがそれを信用するのは、彼らが信頼に足る人物・組織だからではなく、彼らが勝手にやりづらい制度が社会的にあり、また彼らも彼らで一応実績を積み上げてきた、という現実による。

その意味で、クラウドサービスは金融業と近い面がある。彼らもまた、データという顧客の財を預かるサービスだ。そのサービスが使われるほどに、彼らもまた儲かる。まぁ金融業よりは不動産業に近いかもしれない。その性質のために、最近はGAFAの基盤上でサービスを展開する事業者をデジタル小作人などと呼ぶ人もいる。

個人的には、デジタル小作人のような見方はかなり一面的な見方だと思うが、しかし本質的に金融業や不動産業と近い側面があることは事実だ。

つまり、クラウドサービスというのはその本質に、財を預けても良いという信用があり、それをベースにしたみかじめ商売である。

その警戒されるべき本質を、クラウドというぼんやりした流行語によって見えづらくしている。いまや、クラウドを理解しないものは遅れているという社会的な空気さえ醸成されている。クラウドは、ビジネスのうえで非常に便利な言葉だった。だから定着したのだと思う。

クラウドサービスもまた本質は狂気

クラウドサービスはその本質に財を預ける狂気がある。まぁこれはいささか極端な議論かもしれない。クラウドサービスにも色々あって、コンテナの実行基盤やAWS LambdaのようなFaaSは、財を預けているという感覚は薄いだろう。実際、実行基盤として利用している、その利用料を払っている、というのはユーザとしての素直な感覚である。しかしそれでもやはり、本質としてプログラムという財を預ける信用なくしてできないことは確かだ。

Dropboxのようなオンライン・ストレージサービスはクラウドの中でも特に財を預けるという感覚が強いものもある。オンライン・ストレージサービスはクラウドの先駆けとも言えるもので、クラウドという言葉流行る前に出来たモノだから、いまでもオンライン・ストレージサービスと言われる。しかしその本質はクラウドに包括されるものだ。

オンライン・ストレージサービスは信用できない、という言説は昔からあった。実際僕の考えも錯綜している、当ブログを「Dropbox」で検索すれば、NASを主体にしたり、Dropboxを主体にしたりと、あれこれ試行錯誤していることがわかる。

あわせて読みたい

Dropbox Plus + 外付けSSD でNASいらずに挑戦中

まぁなんだかんだでDropbox Plusの有料会員は続けているという事実から、僕はDropboxを信用していると考えられる。実際、Dropboxを使い始めてからかれこれ15年たっていると思うが、特に問題が起きたことはない。

しかしそれも、今の契約が終わるまでで、次の契約更新はしないつもりだ。まぁまだあと1年くらい残っているのだが、今その準備を進めているところで、既に大方のデータをバックアップとしてNASに引っ越している。あと数ヶ月かけて少しずつDropboxの依存度を下げていくつもりである。

理由として、Dropboxというよりクラウドサービス全体に対する個人的な信用の低下や、サービス全体の肥大化、また、代替手段の技術の向上がある。

手元の運用が楽になった

信用の低下といっても、元から大して信用していたわけではない。オンライン・ストレージサービスの場合は、昔からプラットフォーマー側の基準による勝手な垢バン問題があった。子供とのお風呂写真が、欧米諸国の勝手な倫理基準で児童ポルノ扱いされBANされた、という話は実際に聞く。独身である僕は特に子供の裸写真のようなものは持っていないが、あちらの勝手な基準で勝手に垢バンされる、というリスクは常に警戒してきた。そのために、僕はDropboxと使いながらもずっと外付けハードディスクなどにデータの退避を怠ることはなかった。

だったら何故Dropboxを使っているのかと言えば、純粋に便利だからである。オンライン・ストレージサービスとはただデータを雲の上に預けるだけではない。雲の上に預けたデータを、様々なアプリケーションで連携できるところに、クラウドの妙味がある。たとえばDropboxにある音楽データをストリーミング再生するアプリなどは、身近な応用例だろう。

同じ事をオンプレでやろうとしたら、昔はだいぶ苦労したものだ。サーバーの構築とメンテ、そしてインターネット公開のためのネットワーク環境の構築、セキュリティ設定。なので、僕は現実的な選択肢として、Dropboxのようなサービスを利用してきた。

しかし、今はこれがだいぶ楽にできる。サーバについては、なんといってもコンテナが大きい。コンテナの良いところは、環境のスクラップ&ビルドが滅茶苦茶楽なところだ。設定をコードで書けるのもよい。Linuxマシンを用意して、何かあったらOSの再インストールから……なんてやらなてくいい。そしてネットワークについては、Cloudflareの存在が大きい。特にCloudflare Tunnelは、ネットワーク公開を楽かつセキュアにできる現実的な選択肢だ。

まぁ結局DockerやCloudflareに依存していると言えばそれはそのとおりで、特にCloudflareについてはデータ監視のリスクもあるが、しかし同様のことができるサービスはあるわけだし、なにより財を預けているわけではないから、依存度としてクラウドサービスの比ではない。重要なことは、依存しないことだ。依存しないとは、データという人質を取られないことである。

依存度を下げた運用は昔から可能ではあったけれど、労力を含むコストが大きかった。今、それがかなり現実的なレベルにまで下がっている（といっても非IT技術者には厳しいとは思う）。むしろ、自分の使い方に合わせてソフトウェアを組み合わせることができるという点では、お仕着せのサービスよりもよほど使いやすい。

地震雷火事よりも親父（プラットフォーマー）のリスクが大きい

運用について非常に楽になったのはそうだとして、もう一つ問題がある。それは、オンプレ環境が破壊されたらどうするのか問題だ。これはバックアップを取ればいいじゃないかという程度の話ではなく、自宅が火事になったり、あるいは大災害に巻き込まれたらどうするのか、というレベルの話だ。

これについては、どうしようもない。まぁデータくらいなら、遠方の家族の家にたまにハードディスクをおかせてもらえば、すべてがゼロになるという事態は防げるかもしれない。まぁ可能なら、遠隔地にNASをおいてネットワーク越しにバックアップなりできればいいと思う。

しかしそんなことをするなら、クラウドサービスを使えばいいじゃないかという話になるだろう。実際僕もその観点から、クラウドサービスの利用について肯定的だったし、今も業務においては使う。ってか最近個人開発で公開したWebアプリもフツーにAWSのDynamoDBにデータ保存してる。認証はCognito使ってる。

が、プライベートではなるべく避けたい、という感じだ。その理由は簡単で、災害でデータがぶっ壊れるリスクよりも、プラットフォーマーの謎の振る舞いでデータが破壊されたりアクセスできなくなったりするリスクの方が大きいと思うからだ。

プライベートの使い方って非常に広範で、それこそ家族の思い出から個人的ポルノ大全まで色々あり、しかもそのデータは自分の人生が続く限り保持されてほしいものだ。これは通常のサービスよりも実は要件が厳しい。サービスは特定の目的でしか使われないし、なによりサービスの寿命と自分の寿命では、だいたいサービスの寿命のほうが短い。

だから特定のサービスならば、クラウド利用はリスクとベネフィットを天秤にかければ、利用する、という選択は多くの場合正しいと思う。まぁコストに見合えばだが。

しかしプライベートの場合、クラウドはいかにも危なっかしい。確かに地震雷火事には強いだろうが、親父ことプラットフォーマーの気まぐれが怖い。地震雷火事よりも、親父のほうがよほど身近な脅威であり、しかもその親父はアースクエイク・サンダー・ファイアー一通り使える。こんな怖い親父がいるか。

雲の上の頑固親父にデータを預けられない

ということで、現実的に手元の運用コストが下がったことと、雲の上の頑固親父の横暴が酷くなる一方の昨今、とてもそんな親父に僕の大事なデータを預けられねぇなぁという気持ちが強くなっている。

実際、プライベートでは脱クラウドを進めている。まぁさすがに2025年にオンプレはどうなのって話もあるが、その場合でも、最近はVPSのバランスの良さを再評価している。コストも値頃だし、スペックの範囲で好き勝手できるし。コンテナ使えるアプリなら移植性も高いし。そもそもクラウドサービス使わなきゃいけないほど非機能が求められる状況ってあんまりないんだよな、僕の場合、というのもあるが。

そんなわけで、気がつくとMac mini 2018はコンテナサーバとしてなんか常に十数個のサーバが立ち上がっている。まぁめんどくさいこともあるけれど、そういえばサーバって楽しかったぁ、なんてことも思う。こんな楽しいものは、雲の上より自分の部屋にあったほうがよい。そんな360度回ったことを思う今日この頃だ。

複数ブラウザやChromeマルチユーザはEverSyncでブックマーク同期が便利

Sun, 22 Dec 2024 13:19:59 +0900

ブラウザ間、あるいはChromeのマルチアカウント運用でのブックマーク同期は面倒だ。なんでそんなことする必要があるかといえば、組織やプロジェクトごとに異なるブラウザプロフィールを運用する必要性があるからだ。ま、僕の場合は趣味で複数ブラウザを運用しているということもあるが。Chrome, Brave, Firefox、全部起動している。

ブックマークの一元管理したいはやくしたい

特に趣味で複数ブラウザを運用している場合に顕著だが、業務上の都合で複数運用している場合でも、すべてのブックマークを独立させるのは非効率だろう。というか、普通に面倒臭い。

かつては、Xmarksのような拡張機能があって、これが複数ブラウザ間でのブックマーク同期を可能にしていた。しかし今はサービス終了している。まぁChromeとかブラウザ自身が同期機能もったのが大きいだろう。たいていの人は一つのブラウザで一つのプロフィールしか使ってないだろうし。

EverSyncで同期できる

ということでしばらくブックマーク同期難民だったのが、今はEverSyncを使っている。EverSyncはChrome、Firefoxで使える拡張機能で、BraveのようなChromiumファミリーでも利用できる。

https://chromewebstore.google.com/detail/eversync-sync-bookmarks-b/iohcojnlgnfbmjfjfkbhahhmppcggdog

自動同期的なこともできるが、僕はこの手の同期アプリで双方向は可能な限り避けたいと思っている。いや、双方向は絶対こう、バグるんだよね。バックアップも双方向同期はまず避けてるな。そんなわけで、僕は正と決めたメインのBraveブラウザのみをアップロード元とし、その他のFirefoxやChromeにおいてはダウンロードオンリーの運用をしている。めんどくさいっちゃめんどくさいけど、ブックマークが破壊された時の手間を思えば、安い保険だと思う。

Manual Syncしかしないしけた客

数ヶ月これで運用

いつからこの運用を始めたのか明確に覚えていないが、数ヶ月ばかりは経過していると思う。まぁ実際Bookmarkの同期は便利だし、ブックマークバーに「エロサイト」なんて名前のフォルダでも入れてない限り、誰が見ても特に問題ないものだから、実際的だと思う。どこぞのサーバにアップロードしているのが不安という見方もあるだろうが、内容的にはURLのメモでしかないので、あまり問題にならんだろう。っていうかそこまで不安な人はそもそも同期とか考えるもんじゃないだろうし。

という、EverSyncはいいですよというだけの記事。

MacとWindowsのバックアップはNAS + FreeFileSyncを使っている

Thu, 31 Oct 2024 08:32:00 +0900

データのバックアップは面倒臭いけれど、やっていないといざという時にとても後悔する。まぁ保険のようなものだ。

ただ本当に面倒臭いので、できれば自動化、あるいは自動化とまではいかなくても半自動化くらいはしたいものでもある。というか面倒臭さを解消しないと続かない。

今は色々あって、FreeFileSyncというフリーソフトを思い出した時に実行してNASにバックアップを取る、くらいの運用になっている。なんとなく、自分のプライベートPC環境におけるバックアップの軌跡について書いてみる。

バックアップ遍歴

僕のバックアップ遍歴を見てみると、自分のPCを持ち始めた頃はせいぜい大事なデータを外付けハードディスクに入れておくくらいだったと思う。で、その後に多少ものを覚えてからは、どうやらrsyncを使ってバックアップをしていたらしい。それをTimeMachineに全面切り替えしたことを2015年の記事で書いている。

あわせて読みたい

MacのバックアップにrsyncからTimeMachineに全面切り替えした話

/45283123-2/

が、NASをTimeMachineサーバにすると不安定とか、ローカル接続の外付けハードディスクなら安定するがうるさいし、できればNASでバックアップしたいとかあって、1年くらいすると結局rsyncに戻ったようだ。

その後は、バックアップとしては結局NAS + rsyncを使っていた。しかし前述のとおりNASの接続はMacだとちょくちょく切れるので、自動化しづらい面があった。せっかくrsyncを使うなら自動化までさせないとありがたみないよなぁと思いつつ、それが面倒だった。そりゃちゃんとやればちゃんとやれるだろうけど、ちゃんとやる気にならなかった。

Dropboxの有料会員なので、2TBまではクラウド保存できることもあり、一時期はもうバックアップそれでいんじゃね？と思ったが、本当に保存したいファイルを2TBまで削減することができず、結局頓挫した。それにまぁ、クラウドは垢BANもあるから怖いしね……。Dropboxはあまり変な話は聞かないけれど、意味不明なBANをされたという記事は見たことがある。

GUIがよかった

結局、NASへのバックアップは続けざるを得ない。めんどくさい。自動化すれば良いが、自動化自体の手間がかかるし、運用していればなんだかんだでトラブルも起きそうだ。

色々考えて、まぁたまに手動バックアップでいいかと、いつもの結論に立ち戻る。ま、家のPCだし。仕事のデータもあるけれど、本当に重要なソースコードなどのデータはさすがにクラウドにある。クラウドが真なので、ローカルが死んでも問題ない。

ということで、回数が少ないのであれば、rsyncのようなコマンドツールよりも、GUIのツールが良いなと思うようになった。rsyncなんだかんだでトラブルも多いんだよな。それに、Windowsでも使いたかったし。

で、結果的に選ばれたのがFreeFileSync。GUIで操作できて、Windows版もLinux版もMac版も揃っている。

FreeFileSync: Open Source File Synchronization & Backup Software

まぁだいたい一週間に一回くらいの割合で、思い出した時にバックアップしている。これまでやけに自動化にこだわって色々苦労したが、別にこの程度でよかったなと、PC使って15年以上して思うのであった。

DockerのボリュームをCLIでバックアップ・復元する

Mon, 09 Sep 2024 09:55:54 +0900

最近色々セルフホスティングでコンテナ動かしているため、バックアップの必要が出てきた。ので、その内容と実際の手順についてメモする。

ボリュームのバックアップは何をやるのか

まずDockerのボリュームのバックアップとはつまり何をすることなのかについて。これは公式の「Back Up and Share Docker Volumes with This Extension | Docker」を読むとよいのだが、つまりは以下のスニペットに帰結する。

`docker run --rm \ -v "$VOLUME_NAME":/backup-volume \ -v "$(pwd)":/backup \ busybox \ tar -zcvf /backup/my-backup.tar.gz /backup-volume`

このコードの詳細な解説はChatGPTに譲るが、まぁ要はバックアップを作るためのコンテナを作成し、ホストマシンにデータをコピーしている形だ。復元はこれの逆をやると良い。DBなんかは通常dumpのユーティリティがあるが、記事によればDockerの場合はこれでまるごとコピーするほうが良いとのことだ。

ChatGPTによるコードの解説

このコマンドは、Dockerを使って簡単にバックアップを作成するための手順です。以下に各部分の解説を行います。

docker run --rm :

docker run は Docker コンテナを実行するコマンドです。--rm は、コンテナが終了した後にそのコンテナを自動的に削除するオプションです。これにより、バックアップが完了した時点で不要なコンテナが残らないようになります。

-v "$VOLUME_NAME":/backup-volume :

-v オプションは、ホストマシンとコンテナ間でボリュームをマウントするためのものです。$VOLUME_NAME はバックアップしたい Docker ボリュームの名前を指します。これがコンテナ内の /backup-volume ディレクトリにマウントされます。

-v "$(pwd)":/backup :

こちらも -v オプションですが、ホストマシンの現在の作業ディレクトリ（$(pwd) で取得される）をコンテナ内の /backup ディレクトリにマウントしています。このディレクトリにバックアップファイルを保存します。

busybox :

これは Docker イメージの名前です。busybox は非常に軽量な Linux ベースのイメージで、基本的なユーティリティ（tar など）を含んでいます。このコンテナが一時的に起動され、バックアップ処理を実行します。

tar -zcvf /backup/my-backup.tar.gz /backup-volume :

tar コマンドで圧縮ファイル（.tar.gz）を作成しています。
- -z: gzip 形式で圧縮するオプション。
- -c: 新しいアーカイブを作成するオプション。
- -v: 詳細な出力（アーカイブ中のファイル名を表示する）。
- -f /backup/my-backup.tar.gz: 出力するファイル名を指定しています。この場合は、/backup/my-backup.tar.gz という名前で圧縮ファイルが作成されます。
- /backup-volume: アーカイブ対象のディレクトリで、マウントされたボリュームです。

まとめ:
このコマンドは、指定した Docker ボリューム（$VOLUME_NAME）を tar コマンドで圧縮し、現在のディレクトリに my-backup.tar.gz という名前のバックアップファイルを保存します。

これを実行するものとして、v4.29.0以降のDocker Desktopでは拡張機能として公式で提供されている（「Volumes Backup & Share - Docker Extension | Docker Hub」）。上の記事によれば、この拡張機能はボリュームをアタッチしているコンテナを調べて一時停止し、再起動するところまで含めてやっているようだ。

黒塗りしてるのは開発中のアプリ名が出ちゃってるvolume 気にするな

便利な拡張機能だが、もうすぐdeprecatedになる見込みで、どうやらこの機能は近日中に公式で提供されるものらしい。その際、手動バックアップは普通に使えるが、スケジューリングはサブスクプラン専用機能になる模様（Explore Volumes | Docker Docs）。

CLIで無料でやりたい

バックアップはスケジューリングしてやりたいし、お金はないし、そもそもVPSとかDocker Desktopない環境でも使いたい。ということで、フツーにスクリプト書くかなと思った。

やっていることは単純なので、全部自分で書いてもよかったが、上記記事の中でも紹介されている「https://github.com/BretFisher/docker-vackup」がシンプルなシェルスクリプトでそのまま使えて便利そうだったので、これを使うことにした。

インストール手順はREADME.md見ればよいが一応書いておく。LinuxとMacならそのまんま。

`sudo curl -sSL https://raw.githubusercontent.com/BretFisher/docker-vackup/main/vackup -o /usr/local/bin/vackup && sudo chmod +x /usr/local/bin/vackup`

このスクリプトは特にコンテナの停止などしていないようなので、ユースケースから必要なら停止する処理を入れたスクリプト書くべし。

vackupを使ったバックアップと復元

いざという時に使えるように、練習する。

テスト用コンテナのセットアップ

テスト用のDockerネットワークを作成

`docker network create test-network`

MySQLコンテナを起動し、データを保存するためのVolumeを作成

`docker run -d --name mysql-test \ --network test-network \ -e MYSQL_ROOT_PASSWORD=rootpassword \ -e MYSQL_DATABASE=testdb \ -v mysql-data:/var/lib/mysql \ mysql:latest`

データの投入

MySQLコンテナに接続

`docker exec -it mysql-test mysql -uroot -prootpassword`

データベース内にテーブルを作成し、データを挿入。SELECTクエリの結果に、バックアップ時に挿入したデータ (id = 1, data = ‘backup test’) が表示されることを確認する。

`USE testdb; CREATE TABLE test_table (id INT, data VARCHAR(100)); INSERT INTO test_table (id, data) VALUES (1, 'backup test'); SELECT * FROM test_table`

バックアップの実行

`vackup export mysql-data mysql-data.tar.gz`

コンテナとボリュームの削除

`docker stop mysql-test docker rm mysql-test docker volume rm mysql-data`

コンテナを再作成

`docker run -d --name mysql-test \ --network test-network \ -e MYSQL_ROOT_PASSWORD=rootpassword \ -e MYSQL_DATABASE=testdb \ -v mysql-data:/var/lib/mysql \ mysql:latest`

MySQLコンテナに接続

`docker exec -it mysql-test mysql -uroot -prootpassword`

データが空であることを確認する。

`USE testdb; SELECT * FROM test_table`

復元

コンテナの停止。

`docker stop mysql-test`

ボリュームの復元

`vackup import mysql-test.tar.gz mysql-test`

MySQLコンテナを起動して接続

`docker start mysql-test docker exec -it mysql-test mysql -uroot -prootpassword`

データの確認。

`USE testdb; SELECT * FROM test_table`

SELECTクエリの結果に、バックアップ時に挿入したデータ (id = 1, data = ‘backup test’) が表示されることを確認する。

復元OK。

以上。

異常に劣化が早かったCrucial CT2000BX500SSD1のその後

Sun, 28 Jul 2024 17:00:00 +0900

一昨年、セールで安くなっていたSATA SSDをホク顔でポチったが、いざ使って見ると異常に劣化が早く、経過観察をしていた。

/crucial-ct2000bx500ssd1-2 9/4の記事

最後に記事を書いたのが去年の9/4であれから9か月経過しているわけだが、記事を書かなくなったのは、便りが無いのは無事の便りというやつで、まぁその後特に問題なく使えるようになったからだ。というか、使い方を変えたからだ。正直あまり良くないSSDだったのはそうだと思っている。モデルとしてよくなかったのか、ハズレの個体だったのかはわからないが。

前回からの変化

前回記事では、2023/9/3の時点で健康状態が83%であった。で、その後1年近く経過した現在、77%程度でおさまっている。

まぁ以前として「劣化早くね？」というのが偽らざる気持ちではあるものの、許容できないほどではない。少なくともあと10年このSSDを使う予定も特には無いし。

なのでまぁいいか、ということで、記録もしなくなっていた。

Dropbox経由で激しくファイル操作をしていた

変わったことといえば、Dropbox経由での大量のファイル操作をしなくなったことだと思う。

自分はDropbox Plusのユーザなので、2TBのオンラインストレージを利用できる。で、Dropboxの同期能力はたいへん高いので、多くのファイルを高い頻度で作成・削除してもうまくこなしてくれる。これはオンラインストレージとしてたいへん素晴らしいことで、同様のことをQNAPのNAS + ソフトウェアQsyncを使ってやろうとするとたいへんつらいことになる。まぁDropboxも昔はすごい勢いで重複ファイルが出来たものなので、地味だが着実な改善を続けてきたのだろうと思う。これはDropboxがすごい。

で、Dropboxの非機能試験をするかのごとく、自分の使い方では激しいファイルの作成・削除があった。具体的には流行のAIイラストをローカルのStable Diffusionで大量に生成しては削除を繰り返していた。多い日は一日1000枚くらいやっていた。また、プログラムを使ったリネームはファイルの補正なども大量にしていた。……と言っても、逆に言うとその程度なんだが……どうやら、この程度でもCrucialのCT2000BX500SSD1には重たかったようだ。

この操作をSATA SSD上から外した（Dropboxをとおさないようにした）ところ、健康寿命の減少速度は急激に収まった。なので、多分この操作の負荷に耐えかねていた、ということでいいと思う。

大容量の書き込みで速度が突然遅くなる現象もあり

他にも、このSSDはかなり性能に難があるものであることが使っていてわかった。大容量のファイルや大量のファイルなどで、転送に一定時間かかるファイルものだと、一定時間経過すると突然書き込み速度が低下する。なんならハードディスクより遅いくらいになる。これは地味に不便なところの一つだ。

よろしくなかった

Dドライブでデータ保管的な用途が多い現在はさほど問題はないが、Cドライブだと耐えられなかったのではなかろうか。総合的に見て、あまりよくないSSDなのはそうだと思う。モデルの問題なのか、個体の問題なのかはわからない。いずれにせよ、Crucialに対する僕の信頼はちょっと落ちた。

まぁ、今となってはわざわざSATA SSDを買うこともないだろう。NVMe SSDも値段が熟れてきたし……と思ったけどまたちょっと高くなってるのかな最近。まぁでも、スロットさえ空いているならNVMe SSDのほう買いたいね。

[itemlink post_id=“14821”]

LAN内DropboxとはいかないQsyncの使いどころ

Thu, 23 Nov 2023 15:52:24 +0900

Dropboxの有料会員なのに、QNAPのNAS、TS-233をポチってNASに移行できないかを試行錯誤している。QNAPはいくつかの便利なソフトウェアを提供しており、そのうちの一つがQsyncだ。これはNASとクライアントマシン間で同期フォルダを作成するもので、まぁ一言で言えば自前のDropboxをLAN内に作成するようなものと言える。

Qsyncは便利なソフトウェアなんだが、やはり同期というのは難しいようで、「Dropboxはすげぇんだなぁ」という再認識することもある。DropboxのヘビーユーザがQsyncに置き換えるのは厳しいと思う。一方でQsyncにも使いどころは確かにある。

Qsyncを使っていて起きたこと

Qsyncの機能を使い始めて1,2ヶ月程度だが、「TBクラスのフォルダの同期」「大量削除」「大量リネーム」「既にファイルがあるフォルダ同士で同期」など色々やったので、一通りのことは経験出来たのではなかろうかと思う。

これで起きたことは、「同期漏れ」「ゾンビのように復活する削除ファイル」「大量に生まれた重複ファイル」「クライアントアプリが（中途半端に）落ちる」である。

同期漏れとは、たとえば 「同期されなければいけないファイルが永遠に同期されない」現象である。しかしクライアントでは「すべて同期済み」になっている。なんでそうなるのかはよくわからない。常に起きるわけではない。サブフォルダ内のファイルであれば、ファイルのあるフォルダごと削除してもう一回作り直すなどすれば同期されると思う。いずれにせよ、そのままにしておくと端末間で同期フォルダの中身が違う状態が続く。

また、 「あれ？消したファイルが復活してる🤔」ということがある。これはファイルのリネームなどでも「リネーム前のファイルが残っている」などが事象として発生した。多くはダウンロードしてすぐのファイルを操作した時なので、まぁ事情はわかる。とはいえDropboxではこういうことはほとんど起きないことでもある。

「クライアントアプリが（中途半端に）落ちていた」ということも頻発した。中途半端にというのは、フォルダの同期が完全に止まったわけではなくて、サーバ→クライアントのダウンロードはできているのに、クライアント→サーバのアップロードだけ止まっているような状態だった。

そのため気づきづらく、ツールバーにQsyncのアイコンがないことで「あれ、止まってる？」と思って気づいて再起動をかけるのだが、そうすると、落ちていた間にクライアント側で削除したファイルなどが大量復活することになる。この落ちる現象は、作業量に比例しているように思う。大量のファイルを頻繁に追加・削除・移動を繰り返していると起きやすいような。Mac上で起きたが、Windowsでも起きるのかどうかは（試していないので）わからない。

また、ファイルの重複判定もけっこうつらいところがあって、たとえばファイルがあるフォルダ同士で同期をかけるとカオスなことになるため、やめたほうがよい。たとえバックアップツールなどでバックアップしたフォルダであってもやめたほうがよい。最初の同期は、時間がかかっても片方のフォルダを空にしておくほうが無難だろう。

普通にしていても、「両方保管する」にしてしまうと知らない間にduplicateなファイルが出来ているので、NASかクライアントか、どちらかを真とする設定にしておいたほうが良い。ちなみに僕はクライアントを真としている（NAS側を直接操作することはない運用）。

問題は、こうした意図しない同期について、必ずしもユーザが気づけないことだ。たとえば階層の深いところで人知れず起きていた場合、それに気づくのは難しい。また、フォルダ構成が複雑であるほど期待しない挙動も多かったように感じている。

結論としては、 「階層の深いたフォルダの同期」や「頻繁に削除・リネームを実行するフォルダ」では使わないことにした。つまり、Dropboxのようにまるまる2TBの同期フォルダ、という使い方はしない。

Qsyncの使いどころ

それではQsyncは使えないのかというとそんなことはなくて、実際僕は便利に使っている。前述の不安定要素を加味したうえで、「端末間でファイルをやりとりしたい」フォルダをピンポイントで同期すれば、なかなかうまくワークする。特にDropboxフォルダの下という制約がないことによって、部分的にはDropbox超えの使い勝手の良さがある。

具体的には、たとえば「ダウンロード」フォルダだ。ノートPCでダウンロードしたものをデスクトップPCでも開けるのはけっこう便利だ。今まではこれを実現するために、Dropboxフォルダの直下にわざわざDownloadsフォルダを作っていたのだが、Qsyncによってシステムのダウンロードフォルダをそのまま同期フォルダとして指定できるようになり、便利になった。

こういった一時保管場所的なものだけではなく、アプリケーションの設定ファイルや素材置き場など、「頻繁ではないがたまに追加があって、変更があった時にはすぐにデバイス間で同期されてほしい」みたいなフォルダでも使っている。これも、Dropboxフォルダの下という制約がないのでやりやすくなった。

rsyncじゃダメなんですか

そうしてピンポイントに同期フォルダを作成すると、残りのフォルダについては、必ずしも常に同期されていてほしいわけではないことに気づいた。ほとんどのフォルダは、1日に1回程度の同期でも十分だ。つまり、定期的にrsyncを動かすだけで十分だった。

Macとrsyncについては文字コードの正規化問題でかつては苦労させられたものだが、そんなことも今は昔だ。そのへんの話は下記の記事でも触れている。

あわせて読みたい

QNAPのNASを使ったバックアップとファイル同期

/qnap-nas/

上記の記事でも触れているが、WindowsだったらFreeFileSync: Open Source File Synchronization & Backup Softwareが使いやすいかなと思う。

Dropboxは有能だが

こうして使って見ると、何も考えずに快適に全ファイル同期できていたDropboxは本当にすごいなと思う。思えば昔はduplicateとかもよくあったが、最近はあまり見なくなった気がする。地味な進化を続けているのかなぁ。Macの文字コード正規化問題についてはDropboxは手当てしてくれていたし、痒いところに手が届く。

Dropboxの2TBの同期フォルダは、非常に強烈かつ優秀な機能であり、これをセールであれば3年契約月額1000円相当というのは、十分に価値があるものだと個人的には思う。

2TB以上の容量を求めると個人ではつらい感じもあるが、これは前述のとおり、「常に同期されていてほしいフォルダは実はそんなに多くない」ものである。ただまぁ、Dropbox下にファイルがなければならないという制約は、ソフトリンクを駆使してもまぁまぁ厳しいかもしれない。それだったらピンポイントに同期フォルダを作ることができるQsyncのほうが良かったりもするのかも。

Qsyncは使える

まぁそんなわけで、NASについての記事なのにひたすらDropboxを褒め称えてしまっているのだが、そうは言ってもNASのほうが長期的にはコストが低いのは確かだし、また何よりも、 「クラウドにデータが上がらない」というのは、実際けっこう精神的な開放感があることに気づいた。最近はどこのプラットフォームもビッグブラザーめいてきているからねぇ……。LAN内で完結させたほうがいいこともある。

まぁLAN内Dropboxだぜー、というわけにはいかないものの、自宅内に複数台のデバイスがあるユーザにとってはQsyncは十分使いどころのあるソフトウェアだと思った。というか、使っている。

ちなみにmyQNAPcloudのサービスを使えば楽にクラウド化できると思うが、まぁまぁ高いし（myQNAPcloud Storage）そもそもそれだったらDropbox使えばええやんと思う（5TBとか10TBやりたいなら価値あるかも）。自宅にVPNサーバとかたてたらいけるのかな。まぁ、外で同期したいと思うことが最近はないので、そこまで頑張る気もないや。

QNAPのNASを使ったバックアップとファイル同期

Sun, 05 Nov 2023 04:55:56 +0900

最近DropboxからNASに移行しようとしている。具体的にはQNAPのTS-233を購入し、あれこれと運用方法を試行錯誤している。

あわせて読みたい

Dropboxから少しずつNASに移行中

/dropbox-nas/

NASに期待する機能

僕のNASに求める機能は以下である。

デバイス間でのフォルダ同期
データのバックアップ
メディアサーバ

デバイス間でのフォルダ同期: Qsync

デバイス間でのフォルダ同期とデータのバックアップを一挙に解決するものとして、Qsyncが期待された。これは同期フォルダを作成して常にNASとクライアントのデータを一致させるものだ。まぁ一言で言うと自分専用のDropboxを作る機能といえる。

しかしこの同期というやつはやはり難しいもののようで、いざ運用してみるとなかなかうまくいかない。特にファイルが消えないようにするためか、移動や削除、ファイル名の変更をしていると、「消えているべきファイル」がゾンビのように復活する。まぁ安全面に倒すとそうなるのはわかるが、Dropboxの静かな有能さが際立つ結果となった。

まぁでも、これはそうなるかなという気はしていた。テラバイトクラスの巨大なデータフォルダを監視するようなものではあるまい。もしこれをやりたいのであれば、これを専業でずっとやってきたDropboxを大人しく使うのが良いと思う。

また、MacだとQsync クライアントがしばしば落ちている。ただこの落ちるというのも中途半端で、たとえば別デバイスで保存されたファイルの同期はされるのだが、Mac側での削除処理などがサーバに伝わっておらず、「あれ？クライアントアプリ落ちてるな」と思って再起動させると、落ちていた間に削除したファイルが次々と復活するなどかなり鬱陶しいことになる。

以上を踏まえたうえで、要所要所「ここは同期する価値がある」というフォルダについて適用するのが良い運用法だろう。Dropboxのように脳死でまるっと全部同期フォルダにしてしまう、などはやらないほうが無難だ。しかし、Dropboxと違って、色々な場所に散在するフォルダを同期フォルダにできるのはQsyncの強みといえよう。

データのバックアップ: rsync最強伝説もう正規化問題はないんだ……

NASの本懐というべきか、データのバックアップもNASに求められる重要な機能だ。Qsyncはバックアップツールに使うのはやめたほうがよさそうということがわかったので、何かいいツールを探す必要があった。真っ先に思うのはrsyncなのだけれど、今更rsyncとか使いたくないなぁと思い、FreeFIleSync（Download the Latest Version - FreeFileSync）というソフトを使ってみたりした。これはWindows用とMac用がそれぞれあり、けっこううまいこと使えた。

うまいこと使えたのだが、毎度起動するのが面倒である。ってかこれだったらrsync使うほうが楽なのでは？WindowsでWSL経由したら面倒だけれど、Macならフツーにターミナルから実行できる。

rsyncなら慣れてるし、何よりも我々を悩ませてきたUnicode正規化問題はAPFSになってから概ね片付いている。というか多分僕がなんとなくrsync使いたくないなぁと思っていたの正規化のトラウマのせいだと思う。傷深すぎんよ。

戦いの歴史貼っとく。

/30878779-2/ 2013-08-21

/46001270-2/ 2015-11-15

/gdrive-mac-win/ 2017-11-28

しかし今記事を読み返すと、SMBでマウントしてるのにssh使ってrsyncしてたりするの謎だなぁ。SMBのマウントが不安定で勝手に切れてたりしたからだろうか。

まぁなんでもいい、すべては終わったこと……。我々を悩ませた悪魔はもういない。存分にrsyncしていいんだ……。

ということで、結局rsyncに落ち着いている。WindowsだったらFreeFileSyncを使うほうが楽かも。

なおTimeMachineについてまったく書いていないが、過去色々と痛い目を見たので、ネットワーク越しでは使わない。NASじゃなくて、ローカルにケーブル接続して使うならいいと思う。でもそれはそれで面倒だし、システムごと復元したいことって実はそうないので、rsyncによるデータバックアップのほうが汎用性も高くて良いと思っている。

あとはまぁ、災害とかで全データ消失しちゃうリスクか。Dropboxだとこれの心配がないんだよなー。しかしそんな災害やら火事やら、データよりもっと心配すべきものがあるだろという話ではある。

メディアサーバ: 検討中

最後にメディアサーバとしての役割だが、これはまだ検討中。

LAN内ではMacがメディアサーバとして役割を担っている。Mac mini常につけっぱなしだからね。コレは別にこのままでもいいかなぁという感じ。Macのほうがスペック的にも高いのだし。

インターネット経由だと、今はDropboxにアップロードしている音楽ファイルをストリーミングとかしているんだが、これをできないかなぁと思っている。QNAPのソフトウェアにこれができそうなのもあるので、もうちょっとちゃんと検討したい。

Dropboxは便利だけれど、自宅NASには自由さがある

色々やっていて思ったのは、Dropbox便利だなぁということだ。専門的な知識がなくても、ここまでにあげた機能はすべてカバーできる。ソースネクストから買える3年契約だったら定期的にセールしていて年間1万くらいだし、それくらいの価値はあるよなと思う。容量が2TBなのがつらいってことくらいか。あと円安で今後はどうなるかわからないな。

まぁでも、やっぱりNASには自由さがある。クラウド業者にデータを覗かれる心配がないし。GoogleとかMicrosoftとかで、家族の風呂写真あげてるだけでアカウントBANされたみたいな話聞くと、おいおい何してくれてんだビッグブラザーって思う。ここらへんは同じように悩んでいる人がたくさんいる（参考: 機能的で検閲のないクラウドストレージ、ゼロ説 | 点と接線。）。

クラウド事業者がユーザのファイルをスキャンして、挙げ句「お前のデータはポリシー違反だ」として削除あまつさえBANするのは、ド直球の検閲だ。そんなビッグブラザーの運営サービス気持ち悪くて選ばれるわけないから、片手間にオンラインストレージサービスやってるGoogleやMicrosoftの傲慢がそうさせているんだろう。経済合理的にはそんな検閲して1ミリの得もないと思うが、GoogleにせよMicrosoftにせよ、なんかアレゲな連中にコア部分を乗っ取られている感あるなぁ。

しかし、専業のDropboxはそんなことでユーザが離れたら死活問題なので、しないんじゃないかな、多分。スキャンはしているらしいけど（クラウド検閲問題について）、実際にBANされたって人は聞かない。少なくとも僕は今まで無事です。調べても、Googleブラザーがバンバンしている検閲問題で一緒に名前が挙げられているという感じで、少なくともエロやらのせいでDropboxから永久追放されたという話は聞かない。サービス内容が地味でキラキラしてないし金も有り余っているわけではないため、アレゲな連中にまだ乗っ取られてないんじゃないか説。まぁこれは勝手な邪推だけど。

まーでも、今後はどうなるかわからんし、僕はこの機にアレなファイルは全部NASに移行した。別にアレなファイルじゃなくても、データがネットに流れないってのは、存外開放感があるものなんだな、と思った。ま、NASも悪くないな。Dropboxの契約2年くらい残ってるけど。

[![QNAP TS-233](https://m.media-amazon.com/images/W/MEDIAX_849526-T1/images/I/51SfanPiqSL._AC_SL1500_.jpg) ### QNAP TS-233](https://www.amazon.co.jp/dp/B09MZBK7C8?&linkCode=ll1&tag=hackle12-22&linkId=b19cb9b8c22a410729bc6a604f03b285&language=ja_JP&ref_=as_li_ss_tl)
<!-- アフィリエイト開示文 -->

このリンクを通じて購入すると、管理人にアフィリエイト収入が入ります。記事が役に立ったらクリックしてもらえると嬉しいです。

Dropboxから少しずつNASに移行中

Sat, 30 Sep 2023 22:45:52 +0900

最近の記事で、DropboxのためにMac mini 2018で外部ストレージを起動ディスクにしたんだみたいなことを書いた。が、実は7月にしれっとNASを買っており、それを使ってDropboxから移行しようと画策している。Dropbox自体は便利で良いサービスなのだけれど、macOSの新仕様のために、やたらと使いづらくなる未来が見えているためだ。Appleの方針は揺るがないだろうし、iCloud並に使いづらくされてしまう可能性もある。また、Dropbox側のものとしては、iPad ProでDropboxのアプリを使うとやたら落ちるという現象も残念であった（とはいえこれはクリティカルではない）。

ということで、Dropboxのライセンスはあと2年半近く残っている状況でなんだかもったいない気もしつつ、NASへの移行を少しずつ進めている。

NASを買った

購入したNASはQNAPのTS-233だ。だいぶ前に、「NASは1ベイで十分」みたいな記事を書いたのに、結局2ベイNASを買った。

あわせて読みたい

家庭用なら1ベイNASで十分だ

/nas-1bay/

なんでかというと、1ベイNASはスペックが低いからだ。NASは気をつけないと、未だにメモリ512MBとか1GBのモデルが平然と売られているのだが、1ベイNASはまさにそんな感じ。しかも別に安くない。まぁ考えてみると、メーカー的には1ベイだろうが2ベイだろうが構成は大して変わらず、別に1ベイだから安くできるということもないのかもしれない。

大きさ的にも2ベイのサイズのほうが何かと余裕があるだろうし、コスト的にも2ベイNASがちょうどよかろうという感じだった。それにまぁ、また趣味的にRAID組みたいと思うことがあるかもしれないし。

で、このTS-233は値段がそれなりに熟れていてかつ、メモリも2GBだったので、Amazonのセールに合わせてポチった。

QSyncの実力

QNAPが出しているソフトウェアの中に、QSyncというものがある。これはNASとPCの間に同期フォルダを作るもので、まぁいってしまえば自前でDropboxを作るようなものである。こういったソフトウェアを使うためにも、メモリは2GBほしかった。

これを使うと、下記のような構成が実現できる。

graph BT
nas(NAS)
mac(Mac mini 2018)
win(Windows Desktop)
win_n(Windows Laptop)
mac nas
win nas
win_n nas

考え方としては、NASは端末間のデータをやりとりするための中継地点であり、バックアップでもある。

情報がそんなにたくさんあるわけではないので、パフォーマンスや安定性は未知数。これはもう使ってみるしかないかな。僕はけっこう激しくファイルの追加・削除を繰り返す作業をすることもあるし、複数のPCで同じファイルを扱うこともあるし、特にMacはファイルシステムのせいで濁音問題がややこしいとかもあるが、大丈夫だろうかと心配がある。

ざっと使ってみた感じだと、ファイルの増減が緩やかならまず問題はなさそう。パフォーマンスも思ったより速い。Dropboxと遜色ないか、ちょっと上かも。また、ドライブをまたいで同期フォルダを設定できるなど、Dropboxにはない柔軟性は嬉しい。

一方で、同期中に大量のファイルの削除や更新をすると（数万ファイル、数十GBくらい）、ちょっと挙動が怪しい感じがする。同期が詰まる感じというか。削除したファイルが復活したり。また、TBクラスのフォルダを同期したときにちゃんと動くかちょっと不安。まーでも、同期の初動はちょっと注視しないといけなかったとしても、運用までいったら基本的には問題ないんじゃないかな？と思っている。

MacからのSMB接続はやっぱり遅い

MacからのSMBによる接続はやっぱり遅い。まぁこれはもう諦めている。一応対応はあるんだけれど、これをしてもやっぱり遅いんだ。

あわせて読みたい

MacとReadyNAS 104の通信速度が遅い時の対処法(SMB)

/rnas104smbup/

だからこそ、基本はローカルで操作する必要がある。そもそも外付けSSDにDropboxのファイルを退避していたのも、データでさえもSMB接続のパフォーマンスが普段使いだとちょっと使い物にならなかったからだし。

なので、QSyncのようなソフトが重要だ。これがちゃんと機能するならNASに移行できる。逆に使えないとけっこう困るんだが。まぁでも、前述したように、今のところは大丈夫そうだ。

Dropboxは良いサービスです

他にも音楽ファイルをDropboxにあげているものからストリーミングしているとか、スマホで撮影した写真の共有手段に使っているとか、色々とやっていることもあるんだが、恐らくこれらもまぁ、問題ない程度に順次移行できるのではないかと思っている。一番の難所はやっぱりLANを超えた共有だろうなぁ。ここの解法は色々考えられるものの、なるべく手間がかからず便利なものを使いたい。自宅VPNはいやだVPNはいやだVPNはいやだ……。

とまぁ、諸般の事情で僕は脱Dropboxっぽい流れになってしまっているのだけれど、Dropbox自体は良いサービスだと思います。Macの濁点問題を地味に解消していることを知った時は軽く感動したよ。あと、Google DriveやOneDriveみたいにアレげなファイルあげたらBANされたみたいな話も聞こえてこないし、本業オンラインストレージサービスとしての本気を感じる。っていうか画像スキャンしたあげくアカウントBANするとかどこのビッグブラザーだよって感じだけど、Big Techはやっちゃうんだよなぁ。

なので、脱Dropbox的な記事で言うのもなんだけれど、Dropbox自体は本当にオススメ。自宅が火事になっても安心（安心か？）。macOSがわけわからんことになってなければ、NASに移行しようなんて思わなかった。2年以上余っているライセンスももったいないし、これはこれで何か活用方法を考えたいところだ。

macOS版Dropboxで勧められるFile Providerの罠っぷりよ

Sun, 24 Sep 2023 07:30:34 +0900

以前、Mac miniで外部SSDを起動ディスクにした時の記事を書いた。

あわせて読みたい

Mac mini 2018に外付けSSDをつけて起動ディスクにした

/mac-mini-2018-nvme-ssd-boot/

この時一番引っかかったのは、起動ディスクにしたこととは直接関係がない、DropboxのFile Provider問題であった。これをオンにすると外部ストレージをDropboxの保存場所にできない。これは有名な問題で、この仕様が発表された時Dropboxのフォーラムは阿鼻叫喚であった。

Solved: Disaster: Dropbox removing external disk support f… - Dropbox Community

ユーザのフィードバックを受けて、Dropboxは当面外部ストレージのサポートを継続することを表明した。とはいえ、いつまで続くかはわからないし、そのうちにFile Provider使わなきゃいけないんだろうなぁ……と思って、外部ストレージを起動ディスクにして容量的な問題がなくなったので、利用を開始したのだが、これがもう最悪で、結局Dropboxをクリーンインストールしなおす羽目になってしまった。

帝王Appleの推し進めるFile Provider

Appleが推進するFile Providerという新機能は、オンラインストレージサービスに多くの影響を与えている。この機能は、ファイルの同期やアクセスを効率化する目的で導入されたが、その影響は一概に良いとは言えない。特に、Dropboxのような多機能オンラインストレージサービスには、いくつかの制約が生じている。これは、Dropboxが提供する多くの便利な機能と相反する場合があり、特に有料プランを利用しているユーザーにとっては深刻な問題となり得る。

公式ページの「File Provider での Dropbox for macOS で予想される変更点 - Dropbox ヘルプ」にその制約がリストアップされている。これを見ればわかるとおり、機能の拡張よりも制約のほうが大きい。

保存場所の制限

一番酷いのは、保存場所を勝手に決められてしまうことだろう。従来、Dropboxは保存場所を自由に選べる柔軟性があり、外部ストレージデバイスを同期の場所としてデータを保存することが可能であった。しかし、File Providerを使用すると、Appleが決めたCloudStorageとかいう場所に固定される。この結果として、保存場所がシステムによって自動的に設定され、外部ストレージデバイスを保存場所として選ぶことができなくなる。これはソフトリンクでは誤魔化せないらしい。

この制約は、大容量のデータを扱っているだろうDropboxの有料プランユーザにとって死活問題だ。世の中、Appleの馬鹿高いCTOに付き合える石油王ばかりではない。だが、Appleが20万取る4TB SSD（しかもNVme SSD)を、最近は3万足らずで買える。これを利用しているユーザは僕だけではないだろう。これが使えないなら、Dropboxを利用する意味もないくらいだ。

ただし、これは回避方法がないわけではない。外部ストレージのほうを起動ディスクとして設定すれば、CloudStorageも外部ストレージ上にできるため、この制約を回避できる。しかし、このリスキーな手法をDropboxのためにやるかというと、だいぶ厳しい。

……まぁ、僕はやったけど。そして、その結果、結局オフにしたけど……保存場所だけじゃないんだよなぁ。

LAN内同期の制限

DropboxのLAN（Local Area Network）内同期機能が使用できなくなるという制約がある。LAN内同期は、同一のローカルネットワーク内にある複数のデバイス間で高速にデータを同期する機能であり、これにより家の中にある複数端末を高速で同期させることができる。

しかし、File Providerを使用すると、このLAN内同期が制限される。データの同期がインターネット経由でしか行えなくなり、ローカルネットワーク内での高速なデータ転送が不可能となる。これは非常に不便だ。

この問題については、公式ページには「LAN 経由での同期は現在サポートされていません。」と書かれている。“現在"という言葉があることから、将来的にはサポートされる可能性がある。LAN内同期は非常に便利な機能なので、サポートを期待したいが、いずれにせよ、現時点では使えない。

オフラインアクセスの問題

Dropboxのオフラインアクセスに関する挙動が変わる。僕が最終的に音を上げたのはこの問題のためだ。

多くのユーザーが期待するのは、すべてのファイルがローカルに保存され、オフラインでもスムーズにアクセスできる状態だと思う。しかし、実際にはこの期待に反して、ファイルはローカルに完全に保存されず、ファイルを開こうとするたびにインターネットからダウンロードが始まる。Finderなどのファイラでのプレビュー機能もこの制約によってうまく働かなくなる。

公式ページの文言を見ると、CloudStorage全体にオフラインアクセスを許可することで機能しそうに見えるが、実際にはうまく動かなかった。

したがって、これが仕様通りなのかどうかはわからないが、少なくとも僕の環境ではうまくオフラインに落とせなかったことは事実だ。もちろん、容量は何の問題もない。なにしろ4TBもある。

そしてこれは、僕の場合には死活問題であった。僕は大量の画像ファイルを扱う場合っており、ファイルのプレビュー機能で画像を確認することも多いので、この制約は非常に不便だった。というか、はっきり言って仕事にならない。

結局Dropboxを入れ直すことになったのだが、一度File Providerの利用を開始する設定をしてしまうと、再インストール時にもその設定が残ってしまうらしく、それを忘れさせるのにもまた手間がかかった……。

一言で言うとiCloudになる

僕が主に問題と感じたのは以上だが、Dropboxの公式ページを見ればより多くの制約がリストアップされているので、ユーザは必ず確認しておいたほうがよい。恐らく、ダウングレードだと感じることになるだろう。少なくとも現時点で、わざわざFile Providerを利用する積極的な理由は僕にはないと思うし、正直今後もないと思う。

この制約はAppleに端を発しているが、端的に言うと、iCloudになることをDropboxに強要していると感じた。Appleは昔からクラウドサービスについてはあまり良いものを提供しておらず、実際iCloudを使っている人を僕はほとんど知らないのだが（確か母が写真のために一番安いプランを使っているが、それだけ）、Appleはその理由について反省することもなく、サードパーティをiCloud並に落とすことで解決を図っているようだ。

これらの変更は、大方のフリープランのユーザにとってはあまり気にならないものかもしれないが、ヘビーに利用している有料プランユーザにとっては許容しがたいものだと思う。そしてそれがDropboxに金を払っている層だ。

片手間でやってるGoogleやMicrosoftと違って、Dropboxは専業のオンラインストレージサービスであり、熾烈な競争を勝ち抜き、ビジネスユースのみならず一般のアマチュアにも支持された、この分野の雄である。フォーラムに届けられた阿鼻叫喚からも、事の深刻さを理解していると思うし、なんとか踏ん張ってAppleに負けないでほしいところだ。

……まぁでもどうなってもいいように、NASの準備を着々と進めているのであった……。

さいごに

ところで、この記事はChatGPTに記事を書かせる実験も兼ねて書いたのだが、結局8割方僕の文章になってしまった。別にそんなに時短になってないな。むしろ中途半端にChatGPTナイズされた文章があることで、違和感が大きくなるだけになってしまったかも。うーん。ChatGPTになかなかの文章を書かせている人もいるので、僕の指示の出し方に改善の余地が大いにあるのだろうと思われる。

まぁ、そもそも今回はトピックが特定のサービスに対する批判であったので、八方美人のChatGPTには難しかった、というのもあるかもしれない。ChatGPTはOpenAI社のリスク回避のため、少しでもリスキーな話題はとにかく避けようとするので。

僕の文章を学習させて、僕が書きたいトピックについて、いらんリスク回避をせずに8割方書いてくれるAIを作れんもんだろうか……。

Mac mini 2018で外付けSSDを起動ディスクにしたい

Sun, 20 Aug 2023 18:18:38 +0900

発端はDropboxのMacにおける外付けドライブサポート終了問題だった。正確には、オンラインストレージのデータはCloudStorageフォルダに置くことが強制されることになり、これが起動ディスク以外だと具合が悪いというものだ。まぁ、帝王Appleが例によってセキュリティの名目でサードパーティを締め上げているんだなと思った。

これはけっこう本当に困る。他のマシンとのデータのやりとりでDropboxは本当に便利なんだ。NASも購入したものの、やはりクラウド経由のDropboxの便利さにはかなわない（NASもメーカー謹製の同期ソフトとかあるけど、データが絡むだけにクオリティが心配……）。こうなったらもうWindowsに寝返ってやると考え、実際そこそこ使っている者の、WindowsマシンはAIをぶん回すのに忙しく、結局日常使いはMacのまま。というかまぁ、やっぱりなんだかんだでMacは使いやすい面もあるもので。

ということで、それなら外付けドライブを起動ディスクにしてしまえばよかろうというわけだ。

できるのはわかってるが、運用はどうか

さて、外付けのSSDを起動ディスクにする、ということが理屈のうえでは可能なことはわかっている。ただ問題は、それで安定して運用ができるのかどうかだ。今使っているSSDも、時々予期せぬアンマウントがまったくないこともないし、果たして安定性はどうなんだろうか。

こういう時、メディア系の解説記事はあてにならない。頼りになるのは、実際にやってみて、それを使い続けている個人のブログである。ということで、色々と見てみる。

Mac mini 2018 外付け起動ディスク化計画 : I rav,Mac!‘23

この方は容量不足を原因として、2022年の1月に外付けSSDの起動ディスク化を果たしている。その後2023年2月の「Mac mini 2018 購入4周年 : I rav,Mac!‘23」の記事でも外付けSSDを起動ディスクにしていると書かれているし、また6月には直接言及していないものの、新しいMac miniの候補について考えていることから、変わらず健康に使い続けられているのだろうと推測される。つまり、1年半以上問題なく運用できているということだろう。

Macmini 2018を外部SSDで起動 - Way2Go

この方は2021年2月に外部化を果たしている。2023年6月にMac Studioに乗り換えられているようだけれど（Mac Studio 注文しました - Way2Go）、2年4ヶ月にわたって外付けで安定的に運用できていたということだろうか。ストレージ不足は理由にあっただろうが、「Thunderbolt3ケースとM.2の組み合わせは、内蔵SSDより高速」ということも理由にあげている。Thunderbolt3ケースは15000〜20000円程度とヤケクソに高いが、それでもMacのCTOに比べれば爆安。Thunderboltケース何使ったんだろう。Yottamasterなのはわかる。

注意ポイントっぽいもの

以下は先人たちが引っかかったところ。

ファイルシステム
- APFSを選択すること
T2チップの罠
- デフォルトで外部起動が許可されていないので、明示的に許可すること

もうちょっと色々あるかなと思ったが、特にそれらしい記事は見当たらず。ということは、環境構築はもちろん、運用においてもさほど支障はなかったのだと見てよいのではないか。

作業自体は億劫ではあるものの、やる価値はありそうだなと思える。

高速大容量ストレージの夢を追ってもいい

今使っているのは最近お騒がせだった（SanDiskのSSDで「データが突然消える」などの症状が報告される - GIGAZINE）SanDiskのエクストリームモデルの2TBのやつで、まぁこいつをそのまま起動ディスクにしてもいいかなと思う一方で、どうせだったら夢を追いかけて、3万もあれば買えるようになった4TB NVMeを繋いでみても面白いかなぁ、とかなんとか思っている（上位モデルはさすがにもっとするが……）。MacのCTOだと4TBは+168000円という馬鹿げた値段設定がされているが、外付けで実現すれば、Thunderbolt3対応のケースが2万したとしても、SSDと合わせて5万程度。このコストメリットは非常に大きい。

ちなみにAmazonだとCrucialブランドのP3が23800円、PCIe Gen4対応のP3 Plusが24500円という驚くべき価格で売られている。Crucialブランドでこれはすごいと思ったが、冷静に考えてみると自分は今まさにCrucialのSATA SSDで悲しい気持ちになっている真っ最中である（着実に健康状態が悪くなるCrucial CT2000BX500SSD1の経過観察 - 或る阿呆の記）。それで気になって調べてみたら、果たして、評判は芳しくなかった（参考: Crucial P3 Plusレビュー：ひどい性能ですが、PS5専用に使うならアリ | ちもろぐ）。この評価を見ると、他の格安SSDと並んで最安なのもさもありなんという感じ。一定以上の容量を使うと速度がめちゃくちゃ遅くなるようだ。うーん、Crucial今こんな感じなのかー……。

評判のよくないブランドものに手を出すくらいなら、謎メーカーではあるけどこういうのに手を出してもよいかもしれない。

29800円だが、こちらはなんとThunderbolt3の転送速度40Gbpsを超える7000MB/s級のR/Wを誇る。恐ろしい。いや、まぁ、Thunderbolt3の転送速度超えたらオーバースペックなんだが。謎とは言ったが、上記のブログによると、少なくともベンチマークはなかなかのものであったようだ（参考: 「HIKSEMI FUTURE NVMe SSDレビュー：コスパの良さは認めざるをえない | ちもろぐ」）。まぁもちろん長期間の信頼性がどうかはわからないのだけれど、少なくともちょっと使っただけで化けの皮を剥がされたCrucialのP3 Plusよりはまだこちらのほうが良い気もする。

ちなみに同じようなものでLexarというのもある。

Lexarは知らなかったが、これもCrucialと同じくMicron傘下のブランドであったらしい。今は中華。「Lexar NM790レビュー：元Micronの傘下ブランドが放つ破壊的コスパSSD | ちもろぐ」によると（このブログほんとすごいね）、こちらもベンチの結果は上々のようだ。Crucialよりよく見えるんですがそれは……。

Crucialがここまで下がったなら、他のブランドも追従するか？と思う一方、「内蔵SSD市場、ようやくGB単価の下落止まる - BCN＋R」という記事もあるので、さすがにそろそろ底を打ったような気もする。

まぁ別に無理に買うことはないのだけれど、ケース含めて5万ほどで内蔵ストレージより早くて大容量の環境が整えられるかもしれないと思うと、中々浪漫があり、やってしまいたくなるねぇ。これがうまくいけば、ネックだったストレージ問題が解決するわけだから、噂のM3以降のMac miniも、場合によってはポチることもあるかもしれない。

脱Macとはなんだったのか。まぁ結局なんだかんだいってMac好きなんだろうねぇ、僕は……。

着実に健康状態が悪くなるCrucial CT2000BX500SSD1の経過観察

Wed, 16 Aug 2023 09:28:57 +0900

半年ほど前、つまり2023年の2月になるが、CrucialのSATA接続な2TB SSDを購入した。当時14100円は破格であった。その後のSSDの価格下落のため、今となっては別に取り立てて安くもないお値段なのだが、その時点においては安かった。今見てみたら13089円と多少の値下がりはあるものの、「早まったー」と後悔するほどでもなく、お値段的には良い買い物であったと思っている。

[itemlink post_id=“14824”]

しかし、その後実際に使っていると、平均ブロック消去回数がどんどん悪化して、CrystalDiskinfoの健康状態の数値がみるみる減っており、とても不安な気持ちになっている。その経過観察。

88% -> 85% -> 84%

まず7/26に書いた前回の記事を貼っておこう。

あわせて読みたい

Crucialの2TB SSDの寿命が減っていく

/crucial-2tb-ssd/

このときは88%であった。が、実はこの記事を書いた直後に87%になっている。デフラグのスケジュールを見直したり、Crucialのソフトウェアを入れたりと色々やってみたが、抵抗も空しく、その後、8/6には85%になったことを確認している。さらにその後、8/14には84%になってしまった。

8/6

8/14

既に総書き込み量との関連性はまったく見受けられない。もしあったらこのSSDは25TBWくらいしかない。

前回の記事にも書いたが、噂によると、連続使用時間が長くなると寿命が短くなるという謎のバグがMX500シリーズではあったらしい。BX500でも同様のことがあるとすれば、使用時間と電源投入回数からもしかすると関連性が見えてくるかもこないかも。気持ち再起動なちょこちょことやっていたら、パーセンテージが減るスピードは少し遅くなった……ような気もする。今のペースだと、寿命が0％になるまであと1年半くらいか。短いなおい。まぁ寿命0％になっても使えたりするらしいのだが、そんなストレージ使いたくない。

とはいえ、怖いもの見たさでこの後どうなるか見てみたい気もしている。まだ時間的猶予もありそうだから、いつデータが消失しても問題ないような体制を築きつつ、せっかくなので最期まで見届けたいと思っている。

CrucialといいSanDiskといい

Crucialはしっかりしたメーカーという印象があったのだが、調べてみると最近はそうでもなさそうな感じ。まぁでも、交換対応とかはちゃんとしてくれるみたい。本国にチャットという面倒くさい作業は必要みたいだが。

このCrucialのSSDはWindowsマシンに増設したもので、Macでは外付けSSDとしてSanDiskのものを使っている。これはもうかれこれ3年以上しっかり働いてくれていることから信頼していたのだが、最近思いっきり不具合報告がされており（「We just lost 3TB of data on a SanDisk Extreme SSD - The Verge」）、その対応が微妙な感じなのも相まって、信用ならんなぁという感じ。僕が使っているのもまさにこの不具合報告がされたExtremeシリーズなのだが、SanDiskのサイトで調べたところ、型番的には大丈夫、らしい。まぁ実際何事もなく動いているからそうなのだろう、と思う。思いたい。

SSDは大正義Samsungということなのだろうか。次は多少高くてもSamsungにしようかなぁ。

Crucialの2TB SSDの寿命が減っていく

Wed, 26 Jul 2023 16:24:56 +0900

ハズレを引いてしまったかもしれない。まぁ最後までわかんないけどね。とりあえずなんか対応する。

CrucialのSSDを買った

2023年2月、SofmapでCrucialの2TB SSDが14,100円で売っていた。最近の値崩れしたSSD市場ではもはや珍しい値段ではないが、その時点においては特化といって差し支えなかった。具体的にはこれだ。

CT2000BX500SSD1JP

値崩れを起こした今でも14,060円なので、当時14,100円が破格だったことはわかるだろう。まぁ、当時といっても半年前でしかないのだが……。

喜びいさんでポチったところ、売り切れになり、どうやら僕がポチったのは最後の一個だったらしかった。いやぁラッキーだったなぁとその時は思ったものだが、まさかそれから急激にSSDが安くなるとはその時は思っていなかったね……。

まぁでも僕としては満足のいく買い物だったわけだが、購入してから半年も立たないうちに、寿命がモリモリと減り始めていて不安になっている。CrystalDiskinfoによると、既に88%だ。

理由としては平均ブロック消去回数で、こいつの減りがやけに早い。このペースだと35TBWなんだが。スペックには720TBWとあったが。

ただ「CrystalDiskInfo」の見方 - PCと解によると、警告になるのは10%以下らしいので、必ずしもこれがやばいとは言い切れないのかもしれない。0%になっても動くらしい。寿命とはいったい。

平均ブロック消去回数で検索すると「SSDの残り寿命がすごい勢いで減ってる気がするのでどなたかご教授願… - Yahoo!知恵袋」「価格.com - 『残り寿命（健康状態）が５９％（８Ｔ）になりました。』 crucial MX500 CT250MX500SSD1 のクチコミ掲示板」という記事も引っかかって）、これも見てみると全部Crucialでかつ、一つはBX500であった。カカクコムのほうの口コミでは、下記のような口コミがあった。

おそらく電源投入回数に比べて使用時間が長い事が原因です。

海外のフォーラムによると、MX500は連続可動時間が長いと内部の最適化が過剰に働くせいか、ユーザーが特に書き込まなくても寿命がみるみる減っていく問題があるようです。 https://forums.tomshardware.com/threads/crucial-mx500-500gb-sata-ssd-remaining-life-decreasing-fast-despite-few-bytes-being-written.3571220/?view=date

ファームウェアの問題じゃないかと思いますが、いつまで経っても改善しようとしないcrucialに不満を感じますね。

— https://bbs.kakaku.com/bbs/K0001024634/SortID=24523849/

PCは24時間電源投入がデフォでは？

これはMX500だが、同じ事象が起きている可能性はある。連続稼働時間はうちのPCも非常に長い。特にここ最近はずっと連続稼働している。これが本当であれば、定期的にシャットダウンをすればよいということになるが……。

古のデフラグ

他にも何か対応策はないものだろうか……と思って色々見たところ、下記のような記事。

SSDの寿命は何年？延命方法は？ - MiniTool Partition Wizard

ここで、デフラグの話題が取り上げられていて、あー、と思った。

ドライブの最適化は、ディスクの長期使用中に生成される断片化や乱雑なファイルを再配置するために使用され、コンピュータの全体的なパフォーマンスと速度を向上させることができます。しかし、この方法はHDDにのみ適用されます。

SSDの場合、SSDはトラックシーク時間を必要としないため、ドライブの最適化は不要です。それに、この種のデータが何の利点もなく移動することによって、SSDの寿命が大幅に損なわれる可能性があります。つまり、無効にする必要があります（通常、Windows 8より前のWindowsバージョンで使用されます）。

— https://www.partitionwizard.jp/clone-disk/ssd-lifespan.html

デフラグとか古過ぎてもはや意識すらしていなかったが、そういえばSSDが出始めの時はよく「SSDはデフラグしちゃいけない！」と注意喚起されていた。

で、そういえば設定どうなっているんだろう？と思ってみてみたところ、定期的にデフラグされている状態であった。お前まだやってたのか……。で、もしかしてこれも影響があるのかなぁと思いつつ、スケジュール実行をオフにした。

まぁ理屈の上ではありそうなことではあるが、今どきこれ意識している人はあんまりいない気がするし、これが原因だったらもっと言われているような気もするんだよなぁ。。。

様子見

ということで、とりあえずデフラグのスケジュールをオフにするのと、気が向いた時に電源をシャットダウンするをしばらく続けて、経過観察をしようと思う。

Crucialも最近は必ずしも評判良くないみたいだね、、、結局SSDは大正義Samsungということなんだろうか。

まぁストレージは消耗品だし、とりあえずメーカー保証の3年持ってくれたらいいんだけどね。。。バックアップはしているので壊れても損失はないようにしているが、それでもやはり面倒ではあるし。頑張ってくれよー。

[itemlink post_id=“14824”]

エンジニアたるもの業務時間外に勉強するのは当たり前だよね論争

Sat, 11 Feb 2023 16:20:47 +0900

技術者の間には、エブリデイ技術やるのは当たり前だよね的な文化が醸成されている（と思う）が、他の多くの職種において、仕事の時間以外に仕事に関わることをやるというのは必ずしも一般的ではないらしい。実際、世界の中でも学ばない人の割合がダントツで多いというのはよく話題になっている。「【46.3％】日本人は本当に「職場でしか学ばない」国民なのだろうか：中村昭典の気ままな数値解析：オルタナティブ・ブログ」まぁこの辺の話は正直深堀りするとそうでもない結論が出るんじゃなかろうかと思っていたりはするんだが。

で、最近は当のエンジニア間でも論争になっているのを見かけることがある。そういえば、大学を出てからというもの、「プライベートは仕事でやらない技術に触れられる時間（真顔）」とか言う奴を鏡の前以外で見つけるのは難しかった。もちろん行くとこに行けば溢れているんだろうが、僕はそういう場にはいなかった（なので探したとも言える）。

実力を上げるには学習が必要

今の会社は比較的勉強する人が多いと思うし、またそれが当然と受容されている文化もあると思う。だが、もちろん全員が全員そうではない。そしてそうでない人は、やはりそうでないなりの力にしからならない。ある程度教えるにしても、モノにしてもらうにはやはり自助努力が絶対に不可欠だ。

こういうと、業務時間外にまで学習を求めるのかみたいなことが言われることもあるようだ。しかし「やればやっただけ実力になり、実力が高ければ良い成果を出せるので、評価もされる」は単なる事実であって、そこに良いも悪いもない。テストで80点取るやつのほうが40点とるやつより評価されるのは当たり前だ。

時間に公私の色はない

実力を上げるためには、時間を使う必要がある。その時間はどこまでも時間であって、公私の区別などという社会的な取り決めは意味をなさない。業務時間にやったことだろうがプライベートの時間にやったことだろうが、同じことをすれば同じように寄与する。

しかし、当然ながら業務時間は業務をやるべきであり、自分の実力を上げることに注力すべきではない。それと同じように、業務を目標としてプライベート時間に業務に関わる勉強をしろ、という強制があると、それは確かに面白くないし、あるべきではない。それは専門家の向上心を利用した搾取である。

この境界線は、けっこう太く曖昧だ。なので、論争になることは理解できる面もある。実際、高い評価を得ようとすると、どうしても微妙なラインを、なんならもうほぼ業務だよね、としかいえないようなラインにも踏み込む必要が出てくる。

一方で、明確に業務ではないと言える時間もある。たとえば僕にとってのサービス開発は、直接業務に関係しない。しかし、要素技術を見ていけば必ずしもそうではない。そしてソフトウェアという領域は汎用的な技術の領域が非常に大きい（というより、そうなるように先人たちによって発展されてきた）。また、表面的な要素技術は違っていても、通底しているものは確かにある。

したがって、技術的に関心のあることを日々やるだけで、それは直接的ではないにせよ、業務に生きてくる。そしてそういう下地があることを前提とした者が専門家であり、その中の技術領域の人間が技術者である。

ということで表題のアンサーだが、エンジニアたるもの業務時間外の勉強も当たり前だが、それは業務とは関係なく、自由で楽しいものでなくてはならない、と考えている。逆にいうと、その「自由で楽しい」自分だけの課題が見つからないなら、エンジニアとして評価を得るのは難しいと思う。

エロ画像を整理したくてプログラミングを始めた

そんなわけで、冒頭に戻るが「プライベートは仕事でやらない技術に触れるチャンス」なのであるし、そしてそれが楽しいのである。それが楽しいから、この道を選んだ。こういうと大層な感じがするが、別にそんな大それたものではない。

実際、僕がホビーでプログラミングを始めたのは、「溜まったエロ画像の整理をしたい」というものすごくしょうもない動機だったように思う。当時はC言語とbashしか知らなかったので、たしか最初はbashで書き始めた。まさかCではやってないはず。少なくとも現存するCのコードはない。で、そのうちに大流行のrubyがめっちゃ便利だと知ってrubyをやり始めた。今はやっていない。ごめんよ。

当時作ったスクリプトの中には今でも使っているものがある。ファイル整理はエロ画像以外でも使えるからね。それは「フォルダ内の画像ファイルをすべて連番にして振り直す」とかいうしょうもないものだったりするが、僕の日常の使い方と密接にリンクしているため、非常に勝手がよい。特にbash製スクリプトは一度ちゃんと動いたらほぼずっと使える。ruby製はいくつか死んだ。メンテの気力なし。ごめんよ。

エロ画像はどこに消えた？

これだけ見ても、bash製ファイル整理スクリプトは僕に多くのことを教えてくれたことがわかる。「専用の用途に向けた一品ものは、拙いコードでも役に立つ」「ただし、メンテナがいる限り」。もう少し具体化して、「bashのコードは腐りづらく、移植もしやすい」「機能は小さいほうが応用がきく」「パイプ最強伝説」なんてのも、良い学びだったと思う。これらは業務と連動して「学びだった」と気づけたことでもある。エロ画像ファイル整理スクリプトと僕の業務は、深いところで繋がっているのだ。

何よりも、エロ画像ファイル整理スクリプトはシンプルかつ超大切なことを僕に教えてくれた。それはバックアップの大切さだ。あの日見たエロ画像がどこに消えたのか僕達はまだ知らない。

バックアップ on 或る阿呆の記

脱Dropbox再考: そもそも同期は必要か

DropboxでアカウントBANされた人がいるらしい

Dropbox、お前もか

一発BANが企業の合理

対策: クラウド最小権限

データの保存は基本に忠実に

ルールの源を考える：我々は力を行使できない

Homebrew環境におけるGiteaのエクスポート：brew services start giteaとgitea webの違いがわかる男

環境

giteaが分裂した。

パスの違いがわかる男

所感

劣化の早いCrucial CT2000BX500SSD1のそのまた後

前回記事

あれから一年、あるいは数年

まぁまだ逝ってないので

FreeFileSync + FTP on Mac -> QNAP NASで文字コードも問題なくバックアップできている

環境

NFCとNFD

MacはSMBつらいつらい

そうだ、FTP、しよう

所感

脱Dropbox：NASの音楽ファイルをストリーミングで再生する試み

ちょっとマニアックな構成

世界線の修正作業

Dropboxに恨みはない

自分のデータは自分で守れ、雲の上で守ってもらえると思うな

狂気の沙汰を正気の沙汰に

クラウドサービスもまた本質は狂気

手元の運用が楽になった

地震雷火事よりも親父（プラットフォーマー）のリスクが大きい

雲の上の頑固親父にデータを預けられない

複数ブラウザやChromeマルチユーザはEverSyncでブックマーク同期が便利

ブックマークの一元管理したいはやくしたい

EverSyncで同期できる

数ヶ月これで運用

MacとWindowsのバックアップはNAS + FreeFileSyncを使っている

バックアップ遍歴

GUIがよかった

DockerのボリュームをCLIでバックアップ・復元する

ボリュームのバックアップは何をやるのか

CLIで無料でやりたい

vackupを使ったバックアップと復元

テスト用コンテナのセットアップ

データの投入

バックアップの実行

コンテナとボリュームの削除

コンテナを再作成

復元

異常に劣化が早かったCrucial CT2000BX500SSD1のその後

前回からの変化

Dropbox経由で激しくファイル操作をしていた

大容量の書き込みで速度が突然遅くなる現象もあり

よろしくなかった

LAN内DropboxとはいかないQsyncの使いどころ

Qsyncを使っていて起きたこと

Qsyncの使いどころ

rsyncじゃダメなんですか

Dropboxは有能だが

Qsyncは使える

QNAPのNASを使ったバックアップとファイル同期

NASに期待する機能

デバイス間でのフォルダ同期: Qsync

データのバックアップ: rsync最強伝説 もう正規化問題はないんだ……

メディアサーバ: 検討中

Dropboxは便利だけれど、自宅NASには自由さがある

Dropboxから少しずつNASに移行中

NASを買った

QSyncの実力

MacからのSMB接続はやっぱり遅い

Dropboxは良いサービスです

macOS版Dropboxで勧められるFile Providerの罠っぷりよ

帝王Appleの推し進めるFile Provider

保存場所の制限

LAN内同期の制限

オフラインアクセスの問題

一言で言うとiCloudになる

さいごに

Mac mini 2018で外付けSSDを起動ディスクにしたい

データのバックアップ: rsync最強伝説もう正規化問題はないんだ……