쫓겨난 하루
비밀번호 하나를 잊었을 뿐인데, 데이터베이스를 지우고 백업을 되살리고서야 겨우 문을 다시 열었다.
잃을 뻔한 건 글이 아니라, 내 사이트를 관리할 권한이었다.
내 사이트인데, 내가 들어갈 수 없었다. 사용자명은 알지만 가입할 때 쓴 이메일도, 비밀번호도 기억나지 않았다. 비밀번호 재설정 메일을 보내봤지만 어디에도 도착하지 않았다. 서버에 메일 발송이 설정돼 있지 않았던 것이다. 문 앞에 서서, 열쇠가 어디 있는지조차 모르는 기분이었다.
호스팅 계정으로 들어가 보니, 예전에 만들어둔 서버가 여러 개 남아 있었다. 어느 것이 지금 사이트를 돌리는 진짜인지부터 가려야 했다. 도메인이 가리키는 서버 하나를 특정하고 나서야, 찾던 계정 이메일이 거기 등록돼 있다는 걸 확인했다. 잊었다고 생각한 정보는, 사실 내가 만든 시스템 어딘가에 처음부터 적혀 있었다.
그리고 사고가 났다. 비밀번호를 바꾸려고 데이터베이스를 열었다가, 그 데이터베이스를 통째로 지워버렸다. 글도 설정도 댓글도, 사이트의 모든 내용물이 거기 들어 있었다. 겉의 파일은 남았지만 내용을 담은 창고가 사라진 셈이다. 순간 아찔했다. 복구하려다 더 큰 걸 잃을 뻔했다.
다행히 백업이 하나 남아 있었다. 그 안에 데이터베이스가 들어 있는 걸 확인하고, 거기서 되살렸다. 복원이 끝난 뒤 서버에 직접 들어가 내용물을 하나하나 확인했다. 글도, 사용자도, 설정도 그대로였다. 무손실. 백업 파일 하나가 하루를, 그리고 그동안 쌓아온 기록을 구했다.
데이터는 지워도 되살릴 수 있다. 단, 백업이 있을 때만.
데이터는 돌아왔는데 로그인은 여전히 거부됐다. 데이터베이스에서 비밀번호를 바꿔도 “유효하지 않은 로그인 정보”만 떴다. 원인은 워드프레스 자신이었다. 최신 버전이 비밀번호 저장 방식을 더 안전한 쪽으로 바꾸면서, 예전부터 쓰던 임시 방법이 더는 통하지 않았던 것이다. 문제를 풀려면, 도구가 바뀌었다는 사실부터 인정해야 했다.
결국 워드프레스 자체의 비밀번호 설정 기능을 직접 불러 다시 정했다. 버전이 무엇이든 그 사이트에 맞는 형식으로 저장되는 방식이었다. 시크릿 창을 열고 주소를 입력하자, 익숙한 대시보드가 떴다. 한참을 헤맨 끝에, 다시 내 사이트의 주인이 되었다.
진짜 문제는 잊은 비밀번호가 아니었다. 백업이 하나뿐이었고, 서버의 자동 백업은 꺼져 있었고, 알림 메일조차 설정돼 있지 않았다. 구조가 약했던 것이다. 비밀번호는 다시 만들면 그만이지만, 백업이 없었다면 글들은 영영 사라졌을 것이다.
그래서 세 가지를 바꾼다. 서버 차원의 자동 백업을 켜고, 콘텐츠 백업을 정기적으로 외부에 보내고, 모든 접속 정보를 한곳에 모아 관리한다. 가장 느린 순간, 가장 나쁜 순간을 대비하는 것이 시스템이 할 일이다.
아카이브는 글을 쌓는 일이 아니라, 잃지 않도록 설계하는 일이다.
My Own Site
I had only forgotten one password — yet I had to delete a database and restore from backup before I could open the door again.
What I almost lost wasn’t the writing, but the right to manage my own site.
It was my own site, yet I couldn’t get in. I knew the username, but I couldn’t recall the email I’d signed up with, or the password. I tried sending a reset email, but it never arrived anywhere — the server had no mail sending configured. I stood at the door, not even knowing where the key was.
When I logged into the hosting account, several servers I’d built long ago were still there. I first had to figure out which one was actually running the site. Only after pinning down the server the domain pointed to did I find that the account email I was looking for had been registered there all along. The information I thought I’d forgotten had been written, from the start, in the system I’d built myself.
Then the accident happened. Trying to change the password, I opened the database — and deleted it entirely. Posts, settings, comments — all the contents of the site lived there. The outer files remained, but the warehouse holding the contents was gone. For a moment my stomach dropped. Trying to recover, I nearly lost something far bigger.
Fortunately, one backup remained. I confirmed the database was inside it and restored from there. Afterward I went into the server directly and checked the contents one by one. Posts, users, settings — all intact. No loss. A single backup file saved that day, and the record I’d built over time.
Data can be erased and still recovered — but only if a backup exists.
The data was back, but login was still refused. Even after changing the password in the database, all I got was “invalid login information.” The cause was WordPress itself. The latest version had moved password storage to a more secure method, and the old stopgap no longer worked. To solve it, I first had to accept that the tool had changed.
In the end, I called WordPress’s own password-setting function directly and reset it. Whatever the version, it saves in the format that site expects. I opened a private window, typed the address, and the familiar dashboard appeared. After a long detour, I was the owner of my site again.
The real problem was never the forgotten password. There was only one backup, the server’s automatic backups were off, and not even notification mail was set up. The structure was weak. A password can be remade, but without the backup the posts would have vanished forever.
So I’m changing three things. Turn on automatic backups at the server level, send content backups offsite on a schedule, and keep all access credentials in one place. Preparing for the slowest, worst moment is the system’s job.
An archive isn’t about piling up writing; it’s about designing so nothing is lost.
締め出された一日
パスワードをひとつ忘れただけなのに、データベースを消し、バックアップから戻して、ようやく扉を開け直した。
失いかけたのは記事ではなく、自分のサイトを管理する権限だった。
自分のサイトなのに、自分が入れなかった。ユーザー名は分かるが、登録時のメールもパスワードも思い出せない。再設定メールを送ってみたが、どこにも届かない。サーバーにメール送信が設定されていなかったのだ。扉の前に立ち、鍵がどこにあるのかさえ分からない気分だった。
ホスティングのアカウントに入ると、以前作ったサーバーがいくつも残っていた。どれが今サイトを動かす本物かをまず見分けねばならなかった。ドメインが指すサーバーを一つ特定して初めて、探していたアカウントのメールがそこに登録されていると分かった。忘れたと思った情報は、実は自分が作ったシステムのどこかに最初から記されていた。
そして事故が起きた。パスワードを変えようとデータベースを開き、それをまるごと消してしまった。記事も設定もコメントも、サイトの中身すべてがそこにあった。外側のファイルは残ったが、中身を収めた倉庫が消えたのだ。一瞬ぞっとした。復旧しようとして、もっと大きなものを失いかけた。
幸い、バックアップが一つ残っていた。その中にデータベースがあるのを確認し、そこから復元した。復元後、サーバーに直接入って中身を一つひとつ確認した。記事も、ユーザーも、設定もそのまま。損失なし。バックアップ一つが、その日と積み上げた記録を救った。
データは消しても取り戻せる。ただし、バックアップがあるときだけ。
データは戻ったのに、ログインはなお拒まれた。データベースでパスワードを変えても「無効なログイン情報」とだけ出る。原因はWordPress自身だった。最新版がパスワードの保存方式をより安全な方へ変え、これまでの仮の方法がもう通じなかったのだ。問題を解くには、道具が変わった事実をまず認めねばならなかった。
結局、WordPress自身のパスワード設定機能を直接呼んで決め直した。バージョンが何であれ、そのサイトに合う形式で保存される方式だった。シークレットウィンドウを開いてアドレスを入力すると、見慣れたダッシュボードが現れた。長く迷った末に、再び自分のサイトの主になった。
本当の問題は、忘れたパスワードではなかった。バックアップが一つしかなく、サーバーの自動バックアップは切れ、通知メールすら設定されていなかった。構造が弱かったのだ。パスワードは作り直せるが、バックアップがなければ記事は永遠に消えていた。
だから三つを変える。サーバー側の自動バックアップを有効にし、コンテンツのバックアップを定期的に外部へ送り、すべてのアクセス情報を一箇所にまとめて管理する。最も遅く、最も悪い瞬間に備えるのがシステムの仕事だ。
アーカイブとは記事を積むことではなく、失わないよう設計することだ。
忘一密語耳,竟刪其庫,復自備份而還,門乃再啟。
所幾失者,非文也,乃主吾站之權也。
己之站也,而己不得入。知其名,而不憶所註之郵與密語。試發重設之郵,終無所至 — 機未設發郵故也。立於門前,竟不知鑰之所在。
入主機之籍,昔所建之機尚存數臺。先須辨孰為今運站者。定域名所指之機,乃知所求之郵,初已註於其中。所謂忘者,實自始載於己所造之系也。
俄而禍作。欲易密語,開其庫,竟全刪之。文也、設也、評也,一站之實皆在焉。外殼雖存,而藏實之庫已亡。一時悚然,欲復而幾失其大者。
幸存一備份。驗其中有庫,乃自彼而復。復畢,親入機中,逐一驗之。文、戶、設皆如舊,無所失。一備份之檔,救是日,亦救積年之錄。
數據雖刪猶可復,惟備份在時。
庫已還,而登錄猶拒。雖於庫中易密語,惟見「登錄之訊無效」。其因在WordPress自身。新版易其藏密之法,趨於更固,而舊時權宜之法不復通矣。欲解之,先須認器已變。
終乃直召WordPress自設密語之能而重定之。無論何版,皆存以合其站之式。啟私密之窗,入其址,熟識之臺乃現。久迷之後,復為己站之主。
其真患非忘密語也。備份唯一,機之自動備份已閉,連通報之郵亦未設,其構弱矣。密語可再造,然無備份,則文永逝。
故易三事:啟機之自動備份,定期送內容之備份於外,聚諸登錄之資於一處而理之。備至遲至惡之時,系之職也。
藏錄者,非積文也,乃謀其不失也。