Příspěvky

1

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 27. 06. 2025, 23:26:41 »

Obavam se, ze tohle je ti uplne nanic. I ve zdejsim propadlisti bys nasel ze pokud neco chcipne, tak tenhle pseudologer jde dolu jako prvni, takze zadny logy neuvidis. Musis jit niz abys mel sanci. dmesg je to co hledas. Samo ani to ti nemusi dat odpoved. A v idealnim pripade ten vypis nepoustecj pres ssh ale lokalne.

Ten tip byl ode mě původně v trochu jiném kontextu. Pokud má úplně headless systém a třeba to vytuhne tak, že už to vůbec nic nezapíše do persistentního logu na disku (vypadá to, že ne) a musí to natvrdo vypnout, tak přes ssh je alespoň nějaká šance zkusit přes druhý počítač odchytit, co se tam předtím stalo, jestliže ještě pojede síť (zatím opravdu nevíme, jestli je opravdu problém ta síťovka, jediné co tazatel popsal, je že počítač přestane reagovat).
A na tohle je ve výsledku už trochu jedno, jestli ve vzdáleném terminálu pustíš journalctl --dmesg --follow, jak jsem psal, nebo dmesg -w (byť dmesg je asi přímočařejší volba, co to netahá přes další buffer a sahá si rovnou na /dev/kmsg).
Samozřejmě je i pár dalších možností třeba forwardování na syslog server (což samozřejmě vyžaduje zas funkční síť), nebo na nižší úrovni přesměrovat konzoli na sériák a připojit se tam z jiného počítače terminálovým emulátorem.

2

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 27. 06. 2025, 13:42:09 »

Tak i po vypnutí rx, tx a tso problém přetrvává. Byl jsem tam připojen přes ssh a měl výpis journalctl --follow, ale tam nic vidět nebylo. Zaměřím se ještě na tu diagnostiku hw přes live distro.

Ještě jak jsem předtím zmínil ten stress-ng (měl by být na tom System Rescue live cd), mimo ten prime95.
Jeho výhoda je, že se ty jeho testy (stressory) nechají spustit najednou, když chcete vytížit celý systém.

Např. tohle (jen jsem to teď rychle splácal dohromady)

Kód: [Vybrat]

stress-ng -v --verify --metrics-brief --tz --hdd 4 --hdd-bytes 1G --hdd-opts wr-rnd,direct --temp-path /mnt/datavm/temp/ --matrix 0 --vm 2 --vm-bytes 50% --vm-populate --timeout 5m
První parametr nastaví verifikaci (pokud ji stressor podporuje), --tz ukáže statistiku teploty CPU, pak se tím --hdd zapne paralelní náhodný zápis (4 procesy, každý 1G), pak vytížení CPU s použitím matic (FPU, velký odběr) a automatickým počtem procesů podle počtu jader, pak vytížení pamětí přes --vm a nakonec celková doba trvání testu přes --timeout (jinak se zastavuje ručně přes ctrl+c).
Akorát až bych byl v živé distribuci, tak bych si někam ručně připojil ten Btrfs oddíl a upravil cestu v --temp-path, aby to zapisovalo na ta SSD.
Ale jinak je tam těch testů mraky, včetně třeba velké zátěže s obsluhou přerušení, tohle je jen rychlý výkop.

Uvidíte, jak se to bude případně chovat.

3

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 27. 06. 2025, 10:55:18 »

Myslel jsem přesně toto co již zde bylo poslané: ethtool -K ethX rx off tx off

Toto me vyřešilo můj problém.

Díky za upřesnění, pokud to vyřešilo problém, tak bezva a byla by to pro tazatele relativně jednoduchá úprava (třeba přes NetworkManager pro persistentní nastavení v SUSE Micro např. - nmcli con modify <spojeni> ethtool.feature-rx off ethtool.feature-tx off a následně nmcli con up <spojeni>).

Mám ještě pro zajímavost stejnou otázku jako teď redustin.
Jevilo se to u vás s Brixem podobně, tzn. zmrznul vám celý počítač bez jediné hlášky a musel jste ho vypnout natvrdo? Nebo "jen" ztratil konektivitu po nějaké době?

4

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 27. 06. 2025, 10:02:54 »

Nezdá se mi, že by s tím měl mít cokoliv společného RX, TX offload. Ale nevím, co myslel Peterekcze zmínkou o e1000 nebo e1000e (PCIe) ovladači.
1GbE síťovky od Intelu jedou s těmi zapnutými offloady naprosto běžně ve výchozí konfiguraci a jsou přítomné skoro na všech základních deskách s Intel CPU. V určitých specifických situacích offloady dává smysl vypnout (DPI firewally, zachytávání raw paketů..), nebo pokud to opravdu prokazatelně způsobí problémy (např. bude špatně fungovat škálování TCP okna). Nicméně to rozhodně není tak, že Intel síťovka => vypnu rovnou veškerý offload, to je blbost.
Další věc je, a zas se vrátím k tomu, co už jsem psal. Pokud by tohle nastalo, nejspíš by nevytuhl celý systém tak, že bude třeba vzít natvrdo tlačítkem a nikde nebude ani hláška. I pokud by systém např. po půl dni ztratil jen síťovou konektivitu, tak se krátkým stisknutím spustí normálně shutdown a systém se regulérně vypne, zapíše logy.
Což je i důvod, proč jsem navrhoval, ať se nejdřív zkusí vytížit a otestovat HW, a případně nasimulovat to vymrznutí, aby se tohle vyloučilo a neztrácel čas nějakými softwarovými tweaky naslepo (docker on/off, offload on/off..), zvlášť jestli to předtím fungovalo (předpokládám).

Ale třeba ještě Peterekcze vysvětlí, co měl konkrétně s tím Brixem a e1000.

5

O serveru Root.cz / Re:Antispam - co je špatně v postu?

« kdy: 25. 06. 2025, 13:43:29 »

Bezva, díky. Ten první nick mě nenapadl

6

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 25. 06. 2025, 13:42:37 »

Tak ne, tím dockerem to taky není, už to zase spadlo.

Opravdu nikde nebylo nic vidět? Žádná chybová hláška z jádra nebo kernel panic s backtrace? Co ten kontinuální monitoring, jak jsem psal?

Jinak jestli to opravdu zmrzne bez jakékoliv další informace, čehokoliv zalogovaného, tak to samozřejmě může být závažnější problém s hardwarem. Od zdroje, přes desku až po přehřívání CPU.

Na tu diagnostiku HW se to Micro moc nehodí, systémový repozitář má úplné minimum balíčků. Asi bych stáhl a spustil nějakou živou distribuci (např. SystemRescue).
Pak bych z https://www.mersenne.org/download/ stáhl linuxový balíček s cli verzí prime95 a rozbalil. Když pusíte příkaz mprime, je tam torture test (to je relativně spolehlivá klasika) a třeba hodinka v blend režimu ukáže dost problémů. Podobně je v tom SystemRescue také stress-ng, který má některé podobné testy.
Ideálně tohle pustit v tmuxu s druhým rozděleným terminálem, abyste to viděl najednou, a dívat se na výstup z příkazu 'watch -n1 sensors'. Ten by vám měl průběžně ukazovat teploty (pokud to podporuje desku a CPU).
Případně tomu ještě dát trochu zahulit najednou a např. dělat u toho nějakou diskovou aktivitu (fio a kontinuální přepisování souborů v random režimu na připojeném oddílu), pokud by tam byl fakt zdroj nějak na hraně, tak by to mohlo vyvolat vymrznutí nebo pád.

U vadných RAM modulů to mívá typicky trochu jiný průběh a fakt tam vidíte pády, adresy chyb atp. - není to úplně blackout. Nicméně cvičný memtest (aspoň do 5. kroku) samozřejmě neuškodí a je taky na přímo jako položka v GRUBu u těch živých distribucí.

A co problém na úrovni distribuce. Nekde nevím kde , možná i na rootu,nebo blogu se během posledního roku mohlo psát o immutable Linuxu.

Má nějaké neduhy. Immutable distr.? Co třeba mount varú,runú do tmpfs, dojde místo někde?

To se mi nezdá, fakticky to není nic jiného než kombinace r/o a r/w subvolumů se snapshoty na Btrfs spojených přes overlay. To volné místo je sdílené napříč celým fs a samozřejmě detailně vidět např. přes btrfs device usage. Navíc tyhle chyby jsou opravdu "vidět", bývá tam spousta chybových hlášek.

7

O serveru Root.cz / Antispam - co je špatně v postu?

« kdy: 25. 06. 2025, 13:32:51 »

Dobrý den, nevíte, co blokuje odeslání této odpovědi?
https://pastebin.com/raw/rHsULUcP
do vlákna
https://forum.root.cz/index.php?topic=30732.0

Zkoušel jsem různé úpravy textů, vyhození odkazů na jiné stránky. Úpravy citací, změnu původního autora citovaného postu z Ħαℓ₸℮ℵ ␏⫢ ⦚.

Díky

8

Software / Re:Stažené soubory s nesedícím md5

« kdy: 24. 06. 2025, 21:01:15 »

Tak zas s vadnou RAM by se ten výskyt chyby pravděpodobně neměnil podle toho kolik je tam zapojených disků, jak tazatel píše.

9

Software / Re:Stažené soubory s nesedícím md5

« kdy: 24. 06. 2025, 20:47:53 »

Za me je k dalsimu hledani chyby (tj. vetveni - je to sitovka nebo je to disk) by pomohlo kdyby jste data na obou koncich spoje (jestli je mate tedy ve vlastni rezii) ukladal/stahoval/sdilel pouze z ramdisku (tj /dev/shm ). To pak rekne zda to je disk nebo sitovka. (za me sit/sitovka je pravdepodobnejsi, protoze chybnej disk by se taky projevil segfaultama aplikaci).

Síťovka mi přijde jako fakt nepravděpodobná, jak už jsem tu jednou psal. SSH, které mu předtím při přenosech blblo taky, má MAC. Stačí jediný bitflip ve zprávě po cestě a rozpadne se ti spojení. Na TCP hlavičkách máš taky CRC.
Tzn. pokud bez viditelné chyby a zastavení přenosu projde přes SCP/SFTP soubor, tak už je porušená integrita souboru,  co se načítá z disku (resp. zapisuje při obráceném směru přenosu).

@DrFreeze

Takže můj tip je disk nebo něco souvisejícího. Na stranu druhou mi přijde že, pokud by to četlo a zapisovalo s chybami všechno (tzn. i / resp. /var oddíl), nejspíš by začaly také náhodně padat programy a systém.
Další věc, co mě trochu zaráží, že by opravdu nikde nebyla ani jedna hláška nebo indicie (dmesg, žurnál, filesystém, vzrůstající SMART countery u disků s CRC chybami...).

Opravdu bych zkusil to fio (mělo by to být v balíčcích)
Dá se to ozkoušet na různé disky, případně i do /tmp, který bývá tmpfs (ramdisk, můžete ověřit v /proc/mounts).

Nejdřív s jednoduchým patternem, kde se dobře hledá. Jakmile to nepřečte správně, skončí to chybou. Když pak odeberete verify_fatal=1 v prvním kroku, zapíše vždy celou velikost, což se hodí třeba na následnou analýzu.

# zapis+verifikace
fio --name=write --filename=testfile --rw=write --size=1G --bs=4k \
    --direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1

# samostatna verifikace
fio --name=verify --filename=testfile --rw=read --bs=4k \
    --direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1

# kontrola zapsaneho souboru hexdumpem (skipuje vsechny opakujici se radky, takze je hned videt chyba)
hexdump -C testfile 
00000000  de ad be ef de ad be ef  de ad be ef de ad be ef  |................|
*
40000000

Případně ve stejném duchu zápis náhodných dat plus crc verifikace.

# zapis s vlozenym crc kodem a verifikace
fio --name=crcwrite --filename=testfile2 --rw=write --size=1G --bs=4k \
   --direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1

# samostatna verifikace crc
fio --name=crcverify --filename=testfile2 --rw=read --bs=4k \
   --direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1

Tohle se dá vesele opakovat s různými disky, oddíly po změnách konfigurace atp. Také s tím patternem můžete snadno zjistit, co se tam případně rozbíjí, jestli je to náhodné atp.

10

Hardware / Re:Internetové rádio/Linux?

« kdy: 22. 06. 2025, 15:53:36 »

Tak ještě omluva, kecal jsem, protože si už nic nepamatuju
mopidy je samo o sobě jen DLNA renderer, ne server.
Ale v rychlosti jsem to ozkoušel, a funguje to třeba s Gerbera DLNA serverem (předtím se to jmenovalo MediaTomb).

Vytvořil jsem jen jednoduchý playlist .m3u

Kód: [Vybrat]

#EXTM3U
#EXTINF:-1, HitRadio Faktor
https://playerservices.streamtheworld.com/api/livestream-redirect/HITRADIO_FAKTOR_128.mp3
#EXTINF:-1, Evropa 2
https://ice.actve.net/fm-evropa2-128
Dal ho do adresáře, kde je nastavené skenování. Normálně se to zobrazí jako playlist k výběru na DLNA klientech, hraje to.

Určitě bude ještě pár dalších možností, např. používá Rygel a vypadá, že je to přesně na tohle použití.
https://github.com/duracell80/DLNA-Radio

11

Hardware / Re:Internetové rádio/Linux?

« kdy: 22. 06. 2025, 14:41:28 »

Teoreticky ještě, pokud by to s tím existujícím rádiem bylo úplně neprůchozí, tak by mu možná šel udělat nějaký bridge, pokud podporuje přehrávání z DLNA.
Tzn. na serveru, počítači, RPi kdekoliv na síti rozjet třeba mopidy+nějaké rozšíření na DLNA server (už jsem ten projekt chvíli neviděl). Vytvoříte m3u playlist, kam nasypete url, co se vám líbí nebo použijete hotový tune-in klient a zkusíte je pak přehrávat na rádiu (na přelaďování pak jen skáčete v playlistu).

12

Hardware / Re:Internetové rádio/Linux?

« kdy: 22. 06. 2025, 14:20:06 »

Asi vám úplně neporadím nějaký DIY projekt.. v příbuzenstvu se buď vyskytují hotová rádia/TV, nebo RPi, kde se to ovládá přes mobil (web rozhraní).

Nevím přesně, co má nebo nemá ten Roadstar uvnitř a jakou platformu používá. Ale pokud vám některá rádia hrají, jiná vypadávají, tak to nejspíš znamená, že ty servery, z kterých to streamuje, můžou být přetížené.
Mnoho stanic má k dispozici víc streamů i od různých poskytovatelů.
Doporučuji mrknout na: https://fmstream.org/
To je celosvětová databáze, kde jsou i česká rádia se svými streamy. Zkuste si dohledat rádio a na stejném int. připojení pustit chvíli třeba v prohlížeči a případně si vykopírujte url na funkční stream. Podobně se url dá třeba získat na webových stránkách rádia, kde to můžete typicky zkusit extrahovat z přehrávače tam pomocí developerské konzole v prohlížeči.

No a spousta int. rádií má pak možnost přidat stream z uživatelem zadané adresy a pojmenovat. Bývá to třeba přes portály jako je třeba https://airable.fm (to funguje např. na některá rádia Hama) Musíte to přes jednorázový kód z rádia nejdřív propojit s účtem na Airable, pak už se to dá editovat, vybírat a seskupovat oblíbené atp.).

13

Server / Re:Nedostupný server, zamrznutí, brute force ssh

« kdy: 20. 06. 2025, 12:17:00 »

Nepřijde mi moc pravděpodobné, že by to bylo tím ssh nebo že by někdo složil server tímhle způsobem.
Tyhle pokusy o ověření a hádání hesel jsou bohužel úplně standardní pro jakoukoliv veřejnou adresu, kde běží ssh server.
Ale ještě jsem se nesetkal s tím, že by to vedlo k nedostupnosti serveru. Ten interval mezi pokusy bývá poměrně dlouhý, aby to způsobilo nějaký problém.
SSH port nechávám standardní, jen to rovnou přenastavím, aby se nedalo ověřit heslem, ale jen přes pubkey. Případně tam přesně jak jste udělal vy, nastavím fail2ban.

Tady např. namátková statistika z jednoho ne příliš navštěvovaného virtuálu s veřejnou IP. Aktuálně běží 20 dní po posledním rebootu, 27654 pokusů (standard).

Status for the jail: sshd
|- Filter
|  |- Currently failed:   5
|  |- Total failed:   27654
|  `- Journal matches:   _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned:   1
   |- Total banned:   1906
   `- Banned IP list:   45.135.232.177

Takže myslím, že to bude něco jiného a je tam jen časová shoda.
Je zvláštní, že tam nemáte nic zalogované dál. Protože pokud se k tomu nemůžete dostat a bylo to sítí jak myslíte, přijdete fyzicky k serveru, zmáčkete krátce tlačítko napájení (nepodržíte), tak by se měl server začít regulérně vypínat a měly by se zapsat nějaké další hlášky do žurnálu.
Pokud je to úplně tuhé a opravdu to musíte natvrdo vypnout, tak tam s největší pravděpodobností bude něco na fyzické konzoli (monitoru). Buď nějaký backtrace, nebo třeba hromada hlášek z nějakého modulu, blokového zařízení (pokud nejde zapsat a souborový systém se přepnul do R/O režimu).

Jinak to může být spousta věcí, od nějakého hardwarového problému, potíž na filesystému (zkoušel jste po těch pádech kontrolu btrfs a scrub?), přes problémy s nějakou aktualizovanou verzí jádra na konkrétním HW (OpenSUSE Micro na rozdíl od Leap Micro je založené na Tumbleweedu, tzn. je to rolling a je tam vždycky poslední stable jádro. Ale i v tom případě by mělo jít naběhnout z nějakého staršího snapshotu).

Ta chyba/varování s irqbalance se některým lidem (s určitým hw, např. od HP) začala objevovat od jádra 6.12 a dál.. ale zas nemělo by to být smrtící, v určité chvíli to prostě přestane šoupat to konkrétní IRQ mezi jádry, ale nezmrzne celý systém.
https://github.com/Irqbalance/irqbalance/issues/336

Takže já bych zkusil - zkontrolovat fyzickou konzoli, případně pokud bych měl podezření na problémy s tím ukládáním, tak si otevřít SSH konzoli na server s nějakým puštěným tmuxem, screenem, kde bych rozjel journalctl --dmesg --follow. Na SSH klientu bych nastavil keepalive (např. ServerAliveInterval 60, ServerAliveCountMax 10) a logoval výstup někam do souboru na klientu. Tzn. kdyby tam byl problém, tak odchytíte ty dmesg hlášky i když se to nepodaří zapsat na disk.

14

Server / Re:Levné úložiště pro zálohování jednotek TB dat

« kdy: 19. 06. 2025, 13:35:23 »

Když už v těch cloudech všechno šifrujete, jak zálohujete samotné šifrovací klíče? Provádíte nějaké pravidelné testy obnovitelnosti dat?

Vyloženě zálohování klíčů, tím že jsou malé, není problém. Může být x různých způsobů od všemožných lokálních šifrovaných klíčenek, centrálních šifrovaných úložišť (vault store) až po různé USB disky atp. Záleží také kolik lidí k tomu má mít přístup a jak jsou nastavená pravidla, pokud je to někde ve firmě atp.

Co může být větší výzva, je jejich zabezpečení na samotném serveru při automatizovaném použití. Tam už záleží, co všechno člověk potřebuje řešit a jak moc to může být komplexní.
Od základního a nejjednoduššího se může začít tím, aby se někde neválely v plaintextu přístupné pro každého, neposílaly se rovnou přes parametry příkazů atp. Pokud zálohování běží přímo na tom serveru, kde jsou data, tak udělat speciálního lokálního uživatele na zálohování, který nemá přihlášení zvenku přes standardní protokoly a zajistit, že ty soubory s citlivými daty jsou čitelné jen pro něj (a roota).

V dalším kroku jde udělat to, že citlivé věci nejsou uložené nikde v konfiguračních souborech/profilech, ale volá se jiný příkaz, co to předá přes stdout. Hodně nástrojů s tím počítá a má ve volbách možnost nadefinovat místo xxx_password="heslo" něco jako xxx_password_command="$HOME/bin/gimme-password.sh".
Obecně se to tímhle způsobem pak přímo nebo přes wrappery nechá propojit s externími nástroji, které ta hesla/klíče získávají z nějaké šifrované podoby. A zas to může být od jednodušších věcí typu lokální gpg (i třeba s běžícím agentem, co to otevře po startu serveru interaktivním zadání hesla), systémových klíčenek až přes ty sofistikované vault servery. U nich pak můžou být také speciální agenty, co můžou autentikovat aplikaci, řešit platnosti tokenů atp.

U těch testů pak zas hodně záleží na konkrétním používání/technologii, důležitosti těch dat a také samozřejmě celkové velikosti. V implementační fázi samozřejmě testuji, pak to fakt záleží na kontextu. Někdy jen namátkové selektivní restory, u menších repozitářů i komplet jednou za čas. Mnoho zálohovacích nástrojů má i vestavěné kontroly. Třeba Restic umí otestovat buď jen strukturu repozitáře nebo i integritu dat proti checksumům, tam dokonce i možnost ověřit jejich část, aby se nemusela přenášet všechna data - např. otestuje si náhodných 10% dat.
Někdy to může být problém, viz. třeba ten zmíněný Deep Archive (nebo obecně u disaster recovery služeb), kdy se za každý restore platí extra a příp. tam ještě ověřitelné checksumy jen pro celé soubory (takže třeba u 100G dumpů, videí, blokových image souborů je to fakt nadlouho).

15

Server / Re:Levné úložiště pro zálohování jednotek TB dat

« kdy: 18. 06. 2025, 23:00:45 »

Pochopil jsem to blbě, nebo vám to fakt vychází na 0.97 Kč za 250 GB na měsíc?

Hele tak jsem kecal, za to se omlouvám. Když jsem to psal, tak jsem dohledával starou fakturu v emailu na mobilu a tam jsem měl nějakou slevu první rok (+ jsem tam měl 250G, část jsem potom smazal). Faktura z minulého měsíce je na 5.41 kč za 204 GB dat (ještě jsem to kontroloval v bankovnictví a potvrzeno). Datacentrum mam Stockholm.

Super a díky za objasnění. Právě že mi to pořád nevycházelo. Tohle už víceméně ano s cenou pro ta levnější datacentra. Při té příležitosti jsem zjistil, že ten původně vybraný Frankfurt je nejdražší, většina ostatních včetně Stockholmu a Irska má cenu jako ve US - tzn. půlka. Nenapadlo mě to předtím proklikat.
Při té mé ukázkové velikosti 20 TB by to tedy vycházelo 18 USD měsíčně bez requestů.
Což už pro určitá použití zajímavé určitě je. Akorát to vypadá, že si ty charakteristiky Glacier Deep Archive musí sednout s konkrétním použitím, což jste vlastně i zmiňoval. Poměrně dost zálohovacích/archivačních nástrojů, co podporuje S3, dokáže fungovat přímo s dražším Glacier Flex-Retrieval, ale ne s Deep Archive.
Takže bude opravdu záležet na co to konkrétně má člověk vymyšlené, protože to logicky není tak univerzální jako obecná on-line S3 storage, ale fakt spíš další tier a ještě si musí dát bacha na requesty, počty souborů atp. (a třeba si ty transfery opravdu ošetří sám).

Kdybych pak chtěl nutně nejlevnější on-line úložiště (s okamžitým přístupem k souborům), bude to asi ulož.to (byť samozřejmě s určitými omezeními). To u 25TB varianty vychází dokonce na 16 USD za měsíc.

Ehm. Nevím jak moc si pouštět veřejně hubu na špacír. V uložto jsem skoro rok pracoval v CDN. Už tam nedělám dlouho, ale když jsem byl před rokem naposledy na srazu s bývalými kolegy, tak říkali že všichni dostali výpověď, že majitele přestalo bavit nechat se pořád tahat po soudech, takže to balí. Chvíli ještě nechají běžet servery, aby se vrátily náklady a až klekne HW tak pak asi půjdou dál. Když teď koukám na linkedin, tak někteří kolegové to tam pořád mají psané (i když většina je už pryč), tak to asi nezabalili tak úplně jak to tenkrát vypadalo, ale jako dlouhodobé (rok+) úložiště na zálohy bych to asi nepoužíval. Samozřejmě tohle jsou takové drby a rozhodně neříkám že něco nějak je, jen co jsem slyšel.

Díky, já samozřejmě nemám insider informace, ale tak jsem si to víceméně také myslel. Že je teď cílem hlavně amortizovat HW, který byl pořízený ještě v době, kdy to bylo převážně veřejné úložiště na sdílení a spousta lidí si kupovala kredity. Takže nasadili poměrně agresivní ceny na osobní bulk storage, aby nalákali uživatele a po nějaké době třeba zhodnotí, jak se to vyvíjí.
Já jsem někde používal právě zmíněný Hetzner, protože mi to přišlo jako rozumné řešení pro danou situaci s relativně velkou flexibilitou a dobrými referencemi (+ tam mám i virtuály). O ulož.to jsem chvíli uvažoval, ale trochu jsem se bál, že to bude trochu punk (ne úplně transparentní rate limiting, jediná automatizovatelná aplikace na server byl Rclone s komunitním modulem, případně si napsat něco svého s jejich API). Ale naprosto beru, že pokud si to někdo vyzkouší jako funkční, rozchodí co potřebuje (např. nezálohuje napřímo, ale jen tam synchronizuje existující zálohu v další kopii) a chce co nejnižší cenu v rámci těch tarifů, tak to může dávat smysl.