Live data from Hacker News

Fire destroys S. Korean government's cloud storage system, no backups available

koreajoongangdaily.joins.com

11–20 of 987 posts

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#13
post #2

> However, due to the system’s large-capacity, low-performance storage structure, no external backups were maintained — meaning all data has been permanently lost. Yikes. You'd think they would at least have one redundant copy of it all. > erasing work files saved individually by some 750,000 civil servants > 30 gigabytes of storage per person That's 22,500 terabytes, about 50 Backblaze storage pods. Or even just mir…

It's even worse. According to other articles [1], the total data of "G drive" was 858 TB.

It's almost farcical to calculate, but AWS S3 has pricing of about $0.023/GB/month, which means the South Korean government could have reliable multi-storage backup of the whole data at about $20k/month. Or about $900/month if they opted for "Glacier deep archive" tier ($0.00099/GB/month).

They did have backup of the data ... in the same server room that burned down [2].

[1] https://www.hankyung.com/article/2025100115651

[2] https://www.hani.co.kr/arti/area/area_general/1221873.html

(both in Korean)

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#15
post #10

I'm sure they had dozens of process heavy cybersecurity committees producing hundreds if not thousands of powerpoints and word documents outlining procedures and best practices over the last decade. There is this weird divide between the certified class of non-technical consultants and actual overworked and pushed to corner cut techs.

Ironically many of those documents for procedures probably lived on that drive...

I dont know why but cant stop laughing. And the great thing is that they will get paid again to write the same thing.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#16
post #2

> However, due to the system’s large-capacity, low-performance storage structure, no external backups were maintained — meaning all data has been permanently lost. Yikes. You'd think they would at least have one redundant copy of it all. > erasing work files saved individually by some 750,000 civil servants > 30 gigabytes of storage per person That's 22,500 terabytes, about 50 Backblaze storage pods. Or even just mir…

[deleted]

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#17
post #13
post #2

> However, due to the system’s large-capacity, low-performance storage structure, no external backups were maintained — meaning all data has been permanently lost. Yikes. You'd think they would at least have one redundant copy of it all. > erasing work files saved individually by some 750,000 civil servants > 30 gigabytes of storage per person That's 22,500 terabytes, about 50 Backblaze storage pods. Or even just mir…

It's even worse. According to other articles [1], the total data of "G drive" was 858 TB. It's almost farcical to calculate, but AWS S3 has pricing of about $0.023/GB/month, which means the South Korean government could have reliable multi-storage backup of the whole data at about $20k/month. Or about $900/month if they opted for "Glacier deep archive" tier ($0.00099/GB/month). They did have backup of the data ... in…

That's unfortunate.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#19
> all documents be stored exclusively on G-Drive

Does G-Drive mean Google Drive, or "the drive you see as G:"?

If this is Google Drive, what they had locally were just pointers (for native Google Drive docs), or synchronized documents.

If this means the letter a network disk storage system was mapped to, this is a weird way of presenting the problem (I am typing on the black keyboard and the wooden table, so that you know)

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#20
post #14
post #12

Earlier quoted context omitted.

Technically the data is still in the cloud

I've been putting off a cloud to cloud migration, but apparently it can be done in hours?

You can use accelerants to speed up migration
Post reply on HN