Там главное поколение пленки найти подходящее :) но кстати надо как нить попробовать. А есть здесь вообще кто-нибудь кто работал с такими девайсами? Как впечатление? Есть ли подводные камни?

Bitblaze - это типа схд?

Не, это лоукост облако для хранения

Можно еще Amazon Glacier использовать, кст
1-2 тб за год закачать выйдет не дорого
Главное, чтобы потом оно тебе не понадобилось, забирать уже дорого)

Backblaze

Ауч, точно

:)

В контексте стриммеров кст
Имхо, это энтерпрайзная технология и довольно долгоживущая, поэтому есть шанс, что через дцать лет с ней какие-нибудь девайсы будут уметь работать
С блюрей таких гарантий уже меньше

Блюрей и не найти толком, хотя вроде пишут что выпускают какие-то долгоживущие (100 лет и более диски)

Ухты, если 100 лет - тогда уже интереснее))

все зависит от того, какого качества носитель и в каких условиях хранить. у меня есть cd-rw 20ти летней давности, до сих пор полностью рабочие. а есть cd-r, которые уже давно осыпались.

Ну то понятно, но все равно рулетка

а у меня вот CD-ROM тупо сдох в старом компе =)

У меня тоже дохли, я их потом вручную регулировал, и они заводились, пока совсем не сдыхали :)

вот типичный пример за что я ненавижу kubernetes
в ИЗОЛИРОВАННОЙ блять среде (отдельная virtualbox виртуалка)
без ВНУТРЕННЕГО вмешательства (то есть комп даже в sleep не уходит)
кластер разъебывается просто в сопли на ходу

причем именно в том месте, где казалось бы ломаться нечему =(

народ всем привет, есть тестовый кластер Ubuntu 18.04 для разработки под minikube —driver=none
kubelet как systemd сервис, все остальное как контейнеры в docker которые ставятся через kubeadm

работает какое то время несколько часов, потом перестает
100% CPU жрет apiserver, kubelet и load average под 1000

и все остальные компоненты тоже жрать начинают
памяти хватает, диска тоже

kubectl сокет apiserver не видит
docker logs
тоже тормозит
помогает только minikube stop
где бы посмотреть логи kubernetes после того как кластер выключили?

journalctl -xen --no-pager -u kubelet
показывает

k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://control-plane.minikube.internal:8443/apis/storage.k8s.io/v1beta1/csidrivers?limit=500&resourceVersion=0: dial tcp 10.0.2.15:8443: i/o timeout

failed to ensure node lease exists, will retry in 1.6s, error: Get https://control-plane.minikube.internal:8443/apis/coordination.k8s.io/v1beta1/namespaces/kube-node-lease/leases/local-altinity-clickhouse-operator?timeout=10s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

что понятно, потому что apiserver сходит с ума...
вопрос, какого фига? кто его начинает так ддосить...

пытаюсь смотреть логи через
docker ps -a | grep apiserver

вижу два контейнера, один вышел час назад
второй вышел 40 минут назад
смотрю тот что постарше
вижу в логах apiserver какую то странную ерунду

E0521 02:51:54.616872       1 repair.go:74] unable to refresh the port block: Get https://[::1]:8443/api/v1/services: dial tcp [::1]:8443: connect: connection refused
````
это как?
рядом вот такое

I0521 02:51:54.590518       1 trace.go:81] Trace[1160183169]: "Reflector storage/cacher.go:/apiregistration.k8s.io/apiservices ListAndWatch" (started: 2020-05-21 02:51:26.034765863 +0000 UTC m=+1495.259645577) (total time: 28.555691294s):
Trace[1160183169]: [28.553834444s] [28.553834444s] Objects listed

I0521 02:51:55.068425       1 trace.go:81] Trace[239533413]: "GuaranteedUpdate etcd3: *v1.Endpoints" (started: 2020-05-21 02:50:07.433524314 +0000 UTC m=+1416.658404162) (total time: 1m47.634833453s):
Trace[239533413]: [1m45.055787461s] [1m45.053639801s] Transaction prepared
Trace[239533413]: [1m47.633499606s] [2.577712145s] Transaction committed
E0521 02:51:55.096912       1 controller.go:218] unable to sync kubernetes service: Get https://[::1]:8443/api/v1/namespaces/default/endpoints/kubernetes: dial tcp [::1]:8443: connect: connection refused
E0521 02:51:55.106869       1 controller.go:179] Get https://[::1]:8443/api/v1/namespaces/default/endpoints/kubernetes: dial tcp [::1]:8443: connect: connection refused
```

как запущенный apiserver может не мочь коннектиться сам на себя?

Да, станноватый лог, конечно. В моей практике 99% проблем с apiserver - это проблемы с etcd. В apiserver большая часть - это restful доступ к данным в etcd, и если etcd поломался - ничего не будет работать

а куда пост Саши пропал?

Посмотри в истории