•  

    pokaż komentarz

    Kwestie licencyjne są priorytetowe moim zdaniem jeśli chcemy zachować 100% pewność że używamy wolnego oprogramowania i tutaj nie ma dyskusji - Linus ma absolutnie racje. Co do samego ZFS ma on swoje wady i zalety to nie jest system plików, który rozwiązuje wszystkie problemy, źle skonfigurowany lub źle użytkowany może doprowadzić do niezłej katastrofy. Podobne funkcjonalności co ZFS ma również BtrFS jednak co do niego nie wątpliwości licencyjnych więc z perspektywy dołączania czegokolwiek do kernela wybór jest raczej oczywisty.

    •  

      pokaż komentarz

      @supermegazord: pełna zgoda, chociaż nie wiem co możesz mieć na myśli pod pojęciem katastrofa, wydajnościowa, tak? wtedy zgoda, czy coś innego?
      a co do btrfs, to jest to bardzo ubogi krewny zfs i brakuje mu wielu istotnych funkcjonalności.

    •  

      pokaż komentarz

      @ksawery2001: zła konfiguracją ZIL lub podłączenie nie bezpośrednie bez przekazania SMART to jest pewna katastrofa odroczona w czasie co do wydajności to pułapek jest jeszcze więcej

    •  

      pokaż komentarz

      @supermegazord: jeszcze raz, problemy wydajnościowe - zgoda. skonfigurowanie zfs aby działał wystarczająco wydajnie nie jest proste ani tym bardziej automatyczne. debilna konfiguracja - nie. to nie jest problem, bo taką samą debilną konfigurację można zrobić dla każdego komponentu i katastrofa gotowa. sorki, ale już wielokrotnie widziałem debili stawiających bazy danych na tmpfs bo szybciej i późniejsze zdziwienie że po restarcie bazy danych nie ma. to także jest przykład odroczonej katastrofy.

    •  

      pokaż komentarz

      stawiających bazy danych na tmpfs

      @ksawery2001: cooo xdd

    •  

      pokaż komentarz

      tmpfs
      @Noniusz, @ksawery2001: Wberw pozorom, nie jest do taki głupi pomysł i nie wcale nowy. To bardzo stary trik. Robi się to w przypadku rozproszonych baz danych gdzie:
      a) najważniejszy jest szybki dostęp do danych
      +b) nie jest ważne uszkodznie pojedynczego noda
      +c) nie ma innej alternatywy (brak SSD / mongo "In-Memory Storage Engine" jest płatny w Enterprise etc.)
      +d) uszkodzenie wszystkich danych nie jest katastrofą ( sesje -> się przeluguje; lub dane, ktore mozna łatwo odzyskac z prawilnej bazy lub noda co rzeźbi po dysku etc.)

      Ten "trik" widzę coraz czesciej we wszelakich cloudach.
      Ale trzeba dobrze rozpoznać usecase.

      "Jeśli coś wygląda na głupie, a działa, to nie jest głupie"
      (zaraz bedą minusy, ojej tmpfs, prynd wyłączą i nie ma danych)

    •  

      pokaż komentarz

      @ksawery2001: @supermegazord: co gorsza według jednych btrfs jest już wystarczająco stabilny na produkcję, a według innych nie. RHEL8 nie ma obsługi na ten przykład. To o czymś świadczy.

    •  

      pokaż komentarz

      @NoComments: @Noniusz: to ogólnie to od bardzo dawna trzyma się dane na tmpfsach, do których ma być szybki dostęp, przykładem enterprise class takiej bazy może być SAP Hana i robi co parę sekund zapis na dysk w postaci snapa z tego co pamiętam. Takich rozwiązań jest więcej, niektóre z nich są bezpłatne jak memcached czy Redis: https://en.m.wikipedia.org/wiki/List_of_in-memory_databases. ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @Init0: No tak, ale tu dane przechowywane są w pamięci niejako pomocniczo, więc nadal nie nazwałbym tego "stawianiem bazy danych na tmpfs". ;)

    •  

      pokaż komentarz

      Wberw pozorom, nie jest do taki głupi pomysł i nie wcale nowy. To bardzo stary trik.

      @Aaandrzej: absolutnie się z toba nie zgadzam, to najgorszy trick jaki można zastosować, bo:

      Robi się to w przypadku rozproszonych baz danych gdzie:
      a) najważniejszy jest szybki dostęp do danych


      @Aaandrzej: wtedy buduje się bazy oparte całkowicie na buforach w pamięci, bo to jest zwyczajnie szybsze niż przechodzenie przez dodatkowe warstwy vfs w kernelu.

      +b) nie jest ważne uszkodznie pojedynczego noda

      @Aaandrzej: wtedy stawia się klastry a nie pojedyncze instancje PGSQL na takim filesystemie. :)

      +c) nie ma innej alternatywy (brak SSD / mongo "In-Memory Storage Engine" jest płatny w Enterprise etc.)

      @Aaandrzej: full resync instancji po prostym restarcie węzła jest sensowny tylko jak baza danych jest mała, do tego musisz dbać aby w żadnym wypadku nie zdażył się black-out, bo wtedy tracisz całe dane i odtwarzasz się z backupu - by design.

      +d) uszkodzenie wszystkich danych nie jest katastrofą ( sesje -> się przeluguje; lub dane, ktore mozna łatwo odzyskac z prawilnej bazy lub noda co rzeźbi po dysku etc.)

      @Aaandrzej: czekaj, ale to już lepiej w takim wypadku stosować warstwę cache a nie bazę danych typu PGSQL. i uwierz mi jak w dużych firmach przyjdziesz z pomysłem aby bazy danych stawiać na tmpfs, bo w razie czego sobie odtworzysz z backupu to w najlepszym wypadku wszyscy parskną śmiechem.

      Ten "trik" widzę coraz czesciej we wszelakich cloudach.
      Ale trzeba dobrze rozpoznać usecase.


      @Aaandrzej: ale chyba widzisz trochę inne mechanizmy. warstwy pośrednie cache, bazy danych w pamięci, itp. ale nie stawianie klasycznych baz danych w tmpfs.

      "Jeśli coś wygląda na głupie, a działa, to nie jest głupie"
      (zaraz bedą minusy, ojej tmpfs, prynd wyłączą i nie ma danych)


      @Aaandrzej: takie coś działa do pierwszego restartu i tak, w moim przypadku, to nie było głupie do czasu restartu serwera, gdzie baz danych zniknęła i był duży ból dupy administratora i "olaboga" co ja teraz zrobię.

      tak więc, wiesz że gdzieś dzwonią ale nie do końca wiesz w jakim kościele i w ogólności masz rację, ale w szczegółach się ostro mylisz.

    •  

      pokaż komentarz

      @Init0: korzystanie z in-memory nie pociąga za sobą korzystanie z tempfs, tam masz interfejs plikowy, co za tym idzie obstawiam też pagecache, a alokując dane normalnie masz bajtowy dostęp do pamięci. In-memory storage engine służył mi za wzór tworząc engine do MongoDB dla pamięci nieulotnych Intel Optane DC Persistent Memory: http://GitHub.com/pmem/pmse

    •  

      pokaż komentarz

      Jeszcze jedna rzecz, Redis jest in-memory, też go portowałem i nigdzie nie używa tmpfs, nawet do robienia replikacji, wszystko leci normalnie przez alokacje

    •  

      pokaż komentarz

      @vries: kiedyś śledziłem rozwój btrfs na bieżąco i za każdym razem był z nim problem. potem śledziłem raz od wielkiego dzwonu i może było lepiej ale też jakoś tak nie do końca. teraz zakładam że jest już wystarczająco stabilnie ale funkcjonalnie dalej jest problem. właśnie przeczytałem sekcję warnings na wiki debian i jednak z niestabilnością dalej jest grubo. do tego jak widzę permanentny brak albo wykastrowane wsparcie dla tego filesystemu w popularnych dystrybucjach także daje do myślenia.

    •  

      pokaż komentarz

      RHEL8 nie ma obsługi na ten przykład. To o czymś świadczy.

      @vries: zamiast siania fudu warto sprawdzić co skłoniło ich do tej decyzji

    •  

      pokaż komentarz

      @m132: "We discovered through feedback that Btrfs was not considered stable enough by many customers and the decision was to focus on better options for our clients." - Taymour Elerian, Senior Solutions Architect at Red Hat and Open Source evangelist
      ¯\_(ツ)_/¯

    •  

      pokaż komentarz

      @vries: @m132: RHEL8 nie ma wspacia dla BtrFS bo RH nie miał kim tego cholerstwa wspierać, a roboty przy tym jest sporo. Wciągając BtrFS do RHEL8 wydaliby na siebie wyrok wspierania go przez cały cykl życia RHEL8 - racjonalna decyzja biznesowa. Ludzie, którzy coś przy tym dłubią siedzą w Facebooku, SUSE i Oracle przy czym w Oracle ostatnio się opieprzają. FB ma chyba jedną z największych produkcyjną implementację BtrFS i to tylko dlatego, że mają kim naprawiać to raz, a dwa wiedzą, że da się go używać tylko w ograniczonym zakresie nie dotykając sporej części funkcjonalności jeżeli nie chcesz odstrzelić sobie kolana razem z jajami.

    •  

      pokaż komentarz

      @ksawery2001: Źle zaadresowałeś swoją odpowiedź, chyba powinno być do @NoComments:

  •  

    pokaż komentarz

    według mnie zfs jest obecnie najlepszym systemem na nas_y

    •  

      pokaż komentarz

      @d0k0p: U mnie stoi NAS na JBOD (ext4) i ma się normalnie. Niczego mu więcej nie trzeba.

    •  

      pokaż komentarz

      @aldente: lubisz jazdę bez trzymanki ;)

    •  

      pokaż komentarz

      @d0k0p: Jako domowy serwer multimediów bez przechowywania wrażliwych danych, nic więcej nie potrzeba.

    •  

      pokaż komentarz

      @aldente: ja wole przynajmniej mirror zapewnic

    •  

      pokaż komentarz

      Jako domowy serwer multimediów bez przechowywania wrażliwych danych, nic więcej nie potrzeba.

      @aldente: Jeżeli trzymasz na nim "tmp" z bittorenta to nie ma sprawy, jeżeli trzymasz na nim swoje zdjęcia to już inna sprawa. Zdjęcia i filmy z komórki to są najcenniejsze dane które obecnie typowy użytkownik produkuje. Najcenniejsze ze względów sentymentalnych.

      Powiedz rano żonie, że ręka Ci się omsknęła na klawiaturze i skasowałeś całe archiwum ze zdjęciami, w tym wszystkie fotki i filmy z dzieciństwa Waszych dzieci. Pomyśl, że nigdy już nie zobaczysz tych wszystkich fajnych (sfotografowanych/sfilmowanych) chwili z przeszłości... Oczywiście możesz być młodymi singlem więc pewno to nie są Twoje klimaty ale zapytaj kogokolwiek ze znajomych jakie mieli by odczucia w takiej sytuacji.

      Dawniej było prosto, zdjęcia były wydrukowane i posortowane. Teraz w większości mamy "kupę" fotek w cyfrowym worku, który może nagle zniknąć... Trzymanie tych fotek w chmurze jest o wiele bezpieczniejszym rozwiązaniem ale... nie wszyscy chcą tam trzymać swoje fotki no i 100% pewności że tam będą nie mamy. Może się okazać, że Google/Apple zostanie zablokowane (np. firewallem jak w Chinach), albo zmieni się zarząd i zażąda wysokiej opłaty za ściągnięcie tych fotek (w już obniżonej rozdzielczości bo w oryginale już teraz ich nie przechowują).

      Na domowy NASie tylko ZFS na softwarowym RAIDZ. Genialne rozwiązanie. Dysk padnie to wymienisz na nowy i nie ma sprawy. Snapshot sobie zrobisz raz na miesiąc i nawet nie będzie zajmował miejsca na dysku (przechowywane są tylko różnice, snapshot jest robiony on-line, trwa to sekundę - usuwanie też szybko i też on-line). Coś sobie skasujesz? nie ma sprawy, klik, klik i masz przywrócony stan sprzed tygodnia. Chcesz paranoiczne bezpieczeństwo? Ok, RAIDZ2 (dwa dyski z sumą kontrolną, mogą równocześnie paść dwa dowolne i dalej masz dane całe)+hotspare+replikacja w chmurze na S3/Google. Znajdź sobie tylko jakiś stary serwerek i postaw FreeNasa z ZFSem.

    •  

      pokaż komentarz

      @kwanty: Kopie zapasowe z wersjonowaniem rozwiązują wszystko.

    •  

      pokaż komentarz

      Powiedz rano żonie, że ręka Ci się omsknęła na klawiaturze i skasowałeś całe archiwum ze zdjęciami,

      @kwanty: Dlatego nie trzymam tam wrażliwych danych, gdyż już wielokrotnie mojej drugiej połowicy ręka się "omsknęła". Wrażliwe dane trzymam w chmurze i to na 2 różnych serwerach. Jak jeden wysiądzie, to na drugim będzie.

    •  

      pokaż komentarz

      Komentarz usunięty przez autora

    •  

      pokaż komentarz

      @kwanty W ZFS można przywracać to co było powiedzmy sprzed tygodnia nie robiąc snapshotów?

    •  

      pokaż komentarz

      W ZFS można przywracać to co było powiedzmy sprzed tygodnia nie robiąc snapshotów?

      @s3ba11: Nie wiem ale zawsze możesz zrobić automatyczny scheduler snapshotów. Codziennie wieczorem cyk nowy i usuwasz ten sprzed miesiąca. Jeżeli dobrze myślę to system został pomyślany właśnie tak, żeby duża ilość snapshotów nie zmniejszała wydajności systemu.

      Generalnie ZFS nie nadpisuje danych tylko zapisuje je w nowym wolnym miejscu. Więc potencjalnie narzędzia do odzyskiwania danych bezpośrednio z dysku powinny działać i powinieneś móc przywrócić skasowany plik.

      Ale jakbyś chciał większą granularność - śledzenie zmian per każda zmiana to są do tego bardziej specjalizowane systemy. Np. Time Machine na applu, podobną funkcjonalność w win10 (nie pamiętam jak się nazywa) i pod linuxa też znajdziesz odpowiednie rozwiązanie. Jak jesteś programistą to najpewniej będziesz używał jakiegoś Gita, etc...

    •  

      pokaż komentarz

      @kwanty
      @d0k0p
      @d0k0p

      RAID i pochodne czy to hardware'owy czy software'owy to nie backup. Sam trzymam niecałe 20TB danych w raid0, odpuściłem sobie raid 1 i 5/6. Po prostu mam kopię danych na oddzielnym kompie, a właściwie to rpi 4 z zew. obudową na usb3 z 5 miejscami na dyski.

      Raid służy obecnie jako rozwiązanie do HA i nic więcej. (bo jeśli chodzi o transfery/szybkość już lepiej zainwestować w duże SSDki QLC, niż bawić się w półki dyskowe i dodatkowe kontrolery.

    •  

      pokaż komentarz

      @d0k0p: Wszystko jest zależne ile potrzebujesz miejsca, wg mnie lepiej mieć 2x4TB i puszczone w raid bo bezpieczniej niż bawienie się w coś czego 99% użytkowników nie rozumie.

    •  

      pokaż komentarz

      @foxbond: a gdzie ja napisałem ze raidX to ... backup?

    •  

      pokaż komentarz

      Raid służy obecnie jako rozwiązanie do HA i nic więcej.

      @foxbond: ciekawie, ciekawie ;)

    •  

      pokaż komentarz

      @kwanty: jeśli zdjęć jest 200 gb to gdzie to trzymać?

    •  

      pokaż komentarz

      @d0k0p: nie tylko nas'y
      W cludzie - gdzie kazdy host jest traktowany jak "cuttle"
      zfs send + zfs recv jest jednym z najłatwieszych sposobow na automatyczne przywracanie danych noda

    •  

      pokaż komentarz

      jeśli zdjęć jest 200 gb to gdzie to trzymać?

      @neuromancer80: No właśnie to jest problem...

      1) Jeżeli nie zależy Ci na za bardzo na jakości i prywatności to trzymasz wszystko w chmurze googla (photos.google.com). Nie ma tam chyba limitu GB, ładnie się sychnronizuje z komórki ale to Google wybiera rozdzielczość - innymi słowy rekompresuje filmy i fotki. No i oczywiście je przeglądają, analizuje profiluje, etc... Jest mała szansa że je zgubią ale akcjonariusze za kilka lat mogą zmienić zdanie...

      2) Jak chcesz trzymać w chmurze bez kompresji to na Google drive masz: 15GB za free, 100 GB za 9zł/miesiąc, 200GB 15zł/miesiąc, 2TB za 50zł/miesiąc. I obecnie taniej nie znajdziesz. Znajdziesz jakieś promocje, jakieś szemrane firemki, etc... ale od rozsądnej firmy której w miarę możesz "zaufać" to będzie mniej więcej tyle co napisałem.

      3) @aldente: napisał, że trzyma w chmurze, no to niech się pochwali ile płaci? i za jak dużo GB? @jedyny_wolny_login: też jest ciekawy... Jak się popatrzy na ceny profesjonalnego storagu w chmurze to 3S/GoogleCloud/Azure mają ceny około 1-2 centy /GB/miesiąc, chyba da się zejść w okolic 0.5 centa za backup w lodowcu - niech mnie ktoś poprawi bo ja nie stosuję więc nie mam praktyki, nie wiem ile to realnie kosztuje. No i trzeba mieć do tego soft bo te rozwiązania nie integrują się z Androidem/iOS czy przeglądarką internetową.

      4) Jakiś domowy NAS, coś porządnego (np.: HP Microserver gen8, 4 dyski sata, FreeNAS@ZFS).

      Ostatecznie ja się zdecydowałem na 4 rozwiązanie bo chciałem mieć "na własność" i dodatkowo postawić jeszcze jakieś inne usługi. Za 1500zł kupiłem (wszystko używane) microserver, 16 GB RAM (ECC), 4 dyski 3TB + mały SSD. Kilka godzin konfiguracji i mam własną chmurę, znacznie bezpieczniejszą niż zwykły dysk w komputerze.

      Załóżmy, że serwer przeżyje 5 lat więc będzie mnie miesięcznie kosztował 25zł za sprzęt i 20-30 zł za prąd (!!! około 40W 24/7 tyle kosztuje miesięcznie). Czyli ostatecznie mam 50zł/miesiąc więc mógłbym 2TB mieć od Googla albo lodowca na Amazonie o podobnej wielkości. Za 5 lat pewno kupię nowy, bardziej energooszczędny żeby ograniczyć rachunki za prąd.

    •  

      pokaż komentarz

      Na domowy NASie tylko ZFS na softwarowym RAIDZ. Genialne rozwiązanie.

      @kwanty: Kiedyś byłem wielkim zwolennikiem ZFS i nie mogłem się doczekać, aż go jakoś oficjalnie dołożą. Ale dawno już się z tego wyleczyłem, jak również z wiary w RAIDZ(2). Mniej więcej po tym, jak go zacząłem używać na sprzęcie klasy SOHO - budując platformę TaniBackup.pl (nie, finalnie TB chodził już na czym innym).

      Po kolei jednak. Jakieś 11 lat temu byłem w takiej sytuacji, że miałem jakieś 8.5 TB danych istotnych + kolejne kilkanaście TB danych multimedialnych - no i był problem z backupem tego wszystkiego. W międzyczasie nastąpił ciąg różnych zdarzeń, które naprowadziły mnie na stworzenie własnego biznesu backupu online - ale to temat na osobną dyskusję.

      W każdym razie robiąc podejście do budowy platformy backupu online, wziąłem się za testy ZFS. System ten bardzo fajnie sprawdza się na sprzęcie klasy Enterprise, gdzie:
      - dyski są tego samego typu (wszystkie, albo przynajmniej jakieś pule)
      - inny sprzęt również jest bardzo powtarzalny
      - ciągle trwa ruch do danych, a więc dyski ciągle pracują i ew. problemy z dyskami szybko wychodzą

      Dokładnie odwrotnie jest w rozwiązaniu do backupu klasy SOHO:
      - mnóstwo różnych dysków - różne pojemności, modele, marki
      - maksymalnie chyba 7 sztuk tego samego modelu pracujących w tej samej lokalizacji
      - różny sprzęt: część dysków chodziła w HP Microserverach G7, w tym 4 normalnie i piąty w górnej szufladzie podłączony nieco inaczej, część w obudowach Lian Li podłączanych przez eSATA, część w obudowach USB itd.
      - zminimalizowane testowanie danych oraz minimalny ruch - dyski się tylko kręcą i zużywają, ale ruchu na nich nie ma, a więc leżą sobie na nich zimne dane, które mogą być od dawna uszkodzone, a dowiemy się o tym dopiero np. za kilka tygodni/miesięcy

      RAIDZ(2) sobie można postawić, ale na sprzęcie o porównywalnych parametrach i do którego mamy zapasowe dyski - natomiast:

      1. Mając Lian Li EX-50 z 5 dyskami np. ST2000DL003, w największej lokalizacji miałem tylko 2 zapasowe dyski tego typu - jasne, mogłem inwestować w starsze dyski, no ale właśnie, ZFS by wymuszał inwestycje w mniej efektywny sprzęt

      2. ZFS jest wrażliwy na rozłączanie urządzeń, oraz błędy UDMA CRC na magistrali SATA - a więc o ile jeszcze dało jakoś ogarnąć obudowy USB z pojedynczymi dyskami, o tyle obudowy Lian Li podłączane przez eSATA i często się rozłączające, były masakrą.

      3. eSATA to grube, masywne kable i c##$#wej jakości wtyczki/gniazda, co razem prowadzi do stopniowej degradacji sygnału - po kilku miesiącach na niektórych kablach zaczynają się masowo pojawiać błędy UDMA CRC, od czego ZFS wariuje.

      4. Oczywiście RAIDZ pomiędzy dyskami w HP Microserverze, a tymi na eSATA, odpada. Podobnie z piątym dyskiem w HP M. G7, montowanym w zatoce po DVD - on jest trochę inaczej widoczny w BIOS i trochę wolniejszy, przez co znowu ZFS ma problemy.

      5. Oczywiście jak się pojawiają coraz większe dyski, to nie rozepniemy na nich ZFS - znaczy rozepniemy, ale na każdym wykorzystamy tylko tyle przestrzeni, ile ma najmniejszy z dysków, czyli 2TB. Oczywiście są na to sposoby, np. pociąć te dyski na kawałki po 1TB, albo pewnie parę innych - no ale na skalę setek dysków i wielu lokalizacji, robi się straszny problem.

      6. Nie ma też możliwości migracji dysków i urządzeń między lokalizacjami, bo wszystkie są częścią większej całości w obecnej lokalizacji.

      Jakie więc były moje wnioski i działania?

      1. Pozbycie się ZFS (a także MooseFS, który też długo testowałem).
      2. Pozostanie przy gołym ext4 - nawet bez żadnych RAID-ów.
      3. Dokładne przypisanie typu zawartości, jaka jest lub może się pojawić na każdym konkretnym egzemplarzu dysku.
      4. Zamiast RAID - wielowarstwowy rsync - przy czym ja jestem programisto-adminem, więc u mnie zupełnie nie było problemem, aby sobie skutecznie ogarnąć kwestie bezpieczeństwa, co u innych osób może być problemem.
      5. Stworzenie kilku bardzo prostych, prymitywnych wręcz narzędzi analizujących zajętość poszczególnych dysków/udziałów, aby z dużym wyprzedzeniem wiedzieć, że coś się zaczyna zapełniać.
      6. Całość uzupełniona monitoringiem SMART (odczytywanym co 2 minuty) - początkowo w NewRelic, dzisiaj w Uptimerobot.

      Dzięki temu jestem bardziej odporny na błędy ludzkie, niż przy dowolnym RAID - bo nawet jak coś np. omyłkowo skasuję, to mogę to sobie odtworzyć z którejś tam warstwy. I mogę też wyjąć dowolny dysk, ręcznie podmienić, przenieść gdzieś itp. - pełna kontrola, co gdzie fizycznie jest. Także nigdy więcej ZFS w systemach klasy SOHO.

    •  

      pokaż komentarz

      @kwanty: Google ma limit i za każdym razem schodzi z jakości. Inna bajka że powoli uciekam od Google. Tak zaczynając od poczty na chmurze kończąc. Dropbox pod tym kontem lepszy, ale też zbyt mały. Mam qnap w domu ale szukam dodatkowej opcji w razie w. 50 zł co miesiąc to pół roku i mam dysk 3 Tb. Sęk w tym że qnap ma tylko dwa sloty a dysków 2tb mam już 5.

    •  

      pokaż komentarz

      @asperger15k: Ty żeś do tego źle podszedł...

      Oczywiście że dyski muszą być tego samego rodzaju bo inaczej wydajność będzie tragiczna. Albo kupujesz drogie nowe albo na Allegro są tanie (z tych samych serii), które przepracowały 200-500 godzin. Prawdopodobnie były to spare z dużych serwerowni.

      Sprzęt klasy enterprise kupujesz (używany - bo cały czas mówimy o tanich rozwiazaniach). Jest teraz tego mnóstwo po aukcjach bo sprzęt niestety żre prąd więc wymienia się na nowszy, bardziej energooszczędny no i przede wszystkim serwerownie robią często rotację.

      Ruch na dyskach nie musi być. ZFS ma coś takiego jak "scrub", to jest procedura przeczytania (w tle) całego dysku i poprawieniu ewentualnych błędów. Procedura jest właśnie po to, żeby sobie poradzić z błędami sprzętowymi (przekłamania transmisji, losowe błędy nośnika, etc...).

      W ZFS możesz jak najbardziej wymienić dyski na większe. Procedura wygląda tak, że wymieniasz jeden, czekasz aż się macierz odbuduje, wymieniasz kolejny, etc... Jak już wymienisz wszystkie to możesz powiększyć macierz zachowując prawidłową geometrię. Poszukaj w Googlach to jest dość dobrze opisane.

      Oczywiście, że na SOHO się nie robi takich rozwiązań. No ale popatrz: https://allegro.pl/oferta/dl380e-g8-gen8-2x-e5-2450l-32gb-14x-sas-sata-ssd-7844933385 za 1100zł masz serwer 32 wątki, 32 GB RAM (ECC!), miejsce na 14x3.5'' SAS/SATA. Jak chcesz coś mniejszego to za 500-800 zł kupisz gen8 w obudowie tower z 4 zatokami ale też serwerowym prockiem i pamięciami ECC.

      Stawiasz na tym FreeNASa (FreeBSD@ZFS) i nie wmówisz mi, że będzie to gorsze rozwiązanie niż goły ext4 z rsyncami...

    •  

      pokaż komentarz

      @aldente: Wrażliwe dane w chmurze... jedno powinno wykluczać drugie

    •  

      pokaż komentarz

      @neuromancer80: No to tak jak pisałem, HP Microserver (albo coś podobnego), na tym stawiasz FreeNas (to jest bardzo proste) i masz rozwiązanie sprzętowe o dużych możliwościach, bardzo solidne (procki serwerowe i pamięć ECC), sprzęt jest bardzo cichy i pobiera mało prądu.

      Jeżeli chcesz się tak bawić to kup gen8 albo gen7. FreeNAS potrzebuje 16 GB pamięci RAM żeby ZFS działał optymalnie (ale jak nie będziesz szalał, nie będziesz potrzbował deduplikacji, mocnej kompresji w locie, szyfrowania to 8GB też styknie). Tylko musisz od razu kupić 4 takie same dyski bo później nie przemigrujesz tego bezboleśnie.

    •  

      pokaż komentarz

      @kwanty: Od czego by zacząć... może od tego, że pisałem o latach 2008-2011, gdzie DL380 G6 (co dopiero G8) był rozwiązaniem za grube tysiące...

      Sprzęt klasy enterprise kupujesz (używany - bo cały czas mówimy o tanich rozwiazaniach).

      @kwanty: Nie, to nadal drogie rozwiązania (albo w zakupie, albo w zużyciu prądu), a do tego głośne i duże. Mój TaniBackup od początku był planowany jako platforma do postawienia konkretnych nodów w różnych mieszkaniach prywatnych i lokalach biurowych, oraz żerowania na łączach kablowych typu INEA, Multimedia itp.

      btw. INEA była zresztą główną inspiracją - kiedyś wracałem sobie z pracy i zobaczyłem z okna tramwaju wielki banner INEI, że wprowadzają łącza bodajże 25/50 albo 50/100 Mbps, gdy ja miałem wówczas w domu 8 Mbps. Wtedy właśnie zacząłem myśleć, do czego by takie łącze można wykorzystać...

      I to się świetnie sprawdziło w praktyce - miałem nawet opracowany autorski projekt eleganckiej zabudowy nad kibel, do montażu 3 lub 4 nodów z UPS-em i routerem w zabudowie kibla w typowych blokach gierkowskich - takich z osobnym kiblem i osobną łazienką. 3 lub 4 nody, bo występowały wersje o różnej szerokości i różnym układzie rur w pionie wodnym. Tak aby można było komuś zasadzić cały taki komplet do mieszkania, wynająć łącze od INEI i zapłacić ~50 zł/mc za fatygę (+zwrot kosztów łącza i prądu).

      kupujesz drogie nowe albo na Allegro są tanie (z tych samych serii), które przepracowały 200-500 godzin. Prawdopodobnie były to spare z dużych serwerowni

      To wtedy ich nie było.

      Ruch na dyskach nie musi być. ZFS ma coś takiego jak "scrub", to jest procedura przeczytania (w tle) całego dysku i poprawieniu ewentualnych błędów.

      Tak, i to zamulało sprzęt - w końcu całe Lian Li chodziło na kontrolerach SI3132, które były tanie i popularne, ale miały łączną przepustowość bodajże 110 MB/s na wszystkich 10 zapiętych dyskach. A potem konsekwencje j/w.

      W ZFS możesz jak najbardziej wymienić dyski na większe. Procedura wygląda tak, że wymieniasz jeden, czekasz aż się macierz odbuduje, wymieniasz kolejny, etc... Jak już wymienisz wszystkie to możesz powiększyć macierz

      O ile jeszcze pamiętam, to trzeba całe vdev-y wymieniać. Jasne, da się, ale to właśnie wymaga pójścia w standaryzację sprzętu i większe instalacje per lokal, zamiast w efektywność finansową.

      Oczywiście, że na SOHO się nie robi takich rozwiązań.

      Czyli w sumie jesteśmy zgodni :)

    •  

      pokaż komentarz

      @SNAKE_83: No przecież nie trzymam ich w postaci jawnej. Wszystko jest w skompresowanych, zaszyfrowanych archiwach.

    •  

      pokaż komentarz

      napisał, że trzyma w chmurze, no to niech się pochwali ile płaci

      @kwanty: Nic nie płaci, bo nie ma dużo tych danych. Wszystkiego mam może z 10 GB. Ale ja, zanim cokolwiek wyśle w chmurę, to to obrabiam na komputerze w domu. I tak moje zdjęcia nie muszą ważyć po 10 MB każde, gdyż nie zamierzam ich drukować na wielkim formacie. Ja jeszcze jestem z epoki klisz fotograficznych i nie pstrykam wszystkiego, jak leci.( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @aldente: no git ale czy są bezpiecznie przechowywane, ja nie ufam chmurom z ważnymi danymi. Jak nie wiem co jest zrobione dla zabezpieczenia... a i tak, sam zrobić muszę tylko takie rozwiązanie się sprawdza :)

    •  

      pokaż komentarz

      @SNAKE_83: Ja poszedłem na kompromis. Ze swojej strony zrobiłem co mogłem w sprawie zabezpieczeń. Nawet jak się trafi wyciek, to raczej nikt nie będzie się bawił w łamanie moich archiwów.

    •  

      pokaż komentarz

      @aldente: chodzilo mi raczej, że backup się robi ale może go nie być, jak będziesz chciał odzyskać, wiadomo SLA itp. (nie wiem czy masz płatny i jczy tam jest taki zapis) ale zawsze są tam jacyś hindusi ;) i może być sorry, bo "awaria", bardzo nam przykro.

    •  

      pokaż komentarz

      @SNAKE_83: Mi natomiast zdarzyło się pracować dla dużych i poważnych firm - w zasadzie przepracowałem dla takowych ponad 10 lat jako admin/programista/architekt - i o ile mam, delikatnie mówiąc, bardzo mieszane uczucia co do kwestii socjalno-motywacyjno-okolicznych, o tyle jestem pewien, że bezpieczeństwo trzymania danych w dużej i poważnej firmie jest nieporównywalnie wyższe od bezpieczeństwa trzymania ich w "swoim zaufanym środowisku", czyli najczęściej w raptem 1-3 kopiach pod swoją fizyczną kontrolą.

      Od tej zasady są tylko 2 wyjątki:

      1. Trzeba oczywiście czytać regulaminy i być świadomym, z jakiej klasy usługą ma się do czynienia - wiadomo, usługi darmowe często są mocno ograniczone, także pod względem bezpieczeństwa, podobnie usługi typu alpha/beta/test, czy wreszcie usługi typowo zasięgowe. Wybieramy zawsze usługi płatne i będące core'owym biznesem danej firmy.

      2. Bezpieczeństwo względem służb (np. gdy jesteśmy o coś podejrzewani i wchodzą do nas z nakazem rewizji, oraz kierują zapytania do różnych firm), oraz automatyczne skanowanie pod kątem "niewłaściwych treści" (np. była parę lat temu afera, że Microsoft wykrył klientowi na OneDrive pedo-fotki i zablokował dostęp chyba do całego konta). Dlatego zawsze wrzucamy dane w postaci zaszyfrowanej, choćby stałym kluczem symetrycznym czy prostym hasłem. No chyba że mowa o danych, które wprost chcemy upublicznić.

    •  

      pokaż komentarz

      @kwanty: od tego mam LTO żeby nie przepadło. przy mojej obecnej produkcji zdjęć żaden nas tego nie pomieści na dyskach, chyba że przepakuję w jpg i zredukuję rozdziałkę.

  •  

    pokaż komentarz

    Czemu tapeta Ubuntu w miniaturce ;)

    Linus ma rację co do licencji ale o ZFS to chyba nie wie zbyt dużo ;)

    Mam nadzieję, że chociaż wireguard wskoczy do jądra...

  •  

    pokaż komentarz

    Zdecydowanie to będzie kolejny rok Linuxa od 20 lat ( ͡º ͜ʖ͡º)

  •  

    pokaż komentarz

    Linus ma racje i przedstawil rozsadne warunki kiedy moze na to sie zgodzic. Tylko debil wiedza na mi za to psy..