Új hozzászólás Aktív témák
-
- Jó megoldás, itt egy gyorstalpaló a szerver beállításához. Esetleg a publikus portot meg lehet változtatni, hogy a kíváncsiskodóknak ne legyen egyértelmű a dolog.
- Nem igazán jó ötlet ez a Windows-os beidegződés, hogy majd én jól partícionálom. Minek? Csak feleslegesen csökkentenéd a Snapshot(ha használod), és a tárolható adatok méretét.
- Több Pool és Volume? Minek? Ráadásul egyetlen lemezzel hogyan hozol létre több Storage Pool-t? Tisztázni kellene a fogalmakat, és a felépítését: [link]
- Esetedben mindegy hogy thick vagy thin, hiszen bőven elég neked egy Volume. A thick esetén lefoglalja magának a teljes megadott méretet, míg a thin esetén csak elméletileg lesz akkor méretű, a gyakorlatban csak annyi helyet foglal amennyi adatot rátöltesz.
- Érdemes a rendszerre bízni a snapshot kezelést, a 20% általában megfelelő. Ugyanakkor ez nem helyettesíti a rendszeres mentést. Igaz írtad, hogy a GDrive-ra is szinkronizálni szeretnél, de ez csak 1 mentés. A saját snapshotja, mondjuk 0.5 mentés, de még kéne egy rendszeres (napi,heti,havi, attól függően milyen gyakran változnak rajt az adatok)mentés mondjuk egy 4TB-os USB-s lemezre. Ami nincs folyamatosan rádugva, hanem fizikailag elkülönítve másik épületben tárolsz. (lopás, és tűzvédelem)
A megosztások felépítését, és felhasználók jogosultság kiosztását neked kell kigondolni, hiszen csak te tudod milyen struktúrában érdemes tárolni az adatokat, kinek mihez lehet hozzáférést adni. Mondjuk a távoli videó vágás nem kicsit bátor dolog, de Ti tudjátok.
[ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
A thin esetén csak a különbséget tárolja, thick esetén pedig már az új fájl is különbségnek számít ezzel jelentősen növelve a Snapshot méretét. Pl. ha rámásolok 10 gigát, akkor a Snapshot kapásból 10 giga lesz.
Tuti Mert a Snapshot leírásában sehol nem látom azt, hogy másképp működne a thin ill. thick esetén. Thin esetén csak azért említik meg, mert a Snapshot működéséből adódóan is növeli (minimálisan) a Volume által lefoglalt fizikai területet, vagyis a "mentések" is azon a Volume-on tárolódnak a szabad hely rovására.Értelemszerűen csak akkor tapasztalható (minimális) lassulás, ha új adatot mentesz rá hiszen a mentéskor meg kell növelni a Volume méretét is, hogy ráférjen az új fájl, vagy a régi módosítása.
Továbbra sem értem miért gondolkodol thin megoldásban, hiszen nem fogsz rá új Volume-ot létrehozni. Miért kellene parlagon hagyni a lemez nagy részét, hogy idővel, az adatok növekedésével arányosan bekebelezze a szabad területet?Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
Szerintem ez csak annyi, hogy a vékony kötet dinamikusan foglal magának az üres helyből. Ezért amíg tart az üres diskpool terület, addig dinamikusan tudja növelni a méretét. Ezért kell figyelni a snapshot-okat, és időnként törölni 1-1 régebbi pillanatképet, hogy ne kebelezze be az összes üres területet, hiszen valamiért fenntartod az üres területet, pl. egy vagy több másik Voume-nak. A vastag kötet esetén nincs hova növekedni, statikus a méret és a kiosztás.
Persze én is tévedhetek.
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
sub71
aktív tag
Nálam is hasonló a helyzet, plussz én még a Container Staion alatt futtatom a Transmissiont, az még 4-5 perc hozzá ! Ez nagyon gáz, soha életemben nem találkoztam ilyen lassan felálló rendszerrel, pedig 30 éve egy 386DX40 pécével kezdtem, ami 40Mhz sebességgel "száguldott" 2 mb ram társaságában... Az előző Nas-nak 2 percbe telt kb mire minden működött rajta, 8 éve szolgált gyári merevlemezekkel, csak sajnos Flash Player alapú volt a felülete és már untam, hogy minden alkalommal, amikor be akartam lépni a setup menüjében, fel kellett telepítenem egy 2 évvel ezelőtti Chrome böngészőt, mert azzal még ment...
-
Szerintem normális. Ez nem egy PC hogy 5 percenként elaltasd/kikapcsold/újraindítsd.
Pont ma próbáltam ki az automata bekapcsolást 07:50-re időzítve:
7:57:16-kor volt az utolsó bejegyzése az indulással kapcsolatban, utána már csak a tűzfal bejegyzéseket mutatja. Ugyanakkor semmi "service exception occurred. (500)" hibát nem látok. Biztos minden rendben van a lemezzel, vagy a NAS-al? A HW ugyanaz, csak a lemezfiókok számossága eltérő. Az nem derül ki melyik program panaszkodik?Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
-
bogabi
senior tag
Miért nem a routerben állítasz be DDNS-t? Akkor tuti minden ilyen esetben befrissítené magát. A NAS-ban lévő megoldásnak gondolom van egy schedule, amit tart (pl. naponta egyszer, mittudomén), és nem érzi, hogy el lett dobva a WAN cím, honnan is tudná, hiszen ő belső hálón van, a DDNS schedule meg naponta egyszer fut pl. Esetleg lehet túrni a NAS-ban hol van ütemezve (ha így van megoldva egyáltalán) a DDNS IP update job, és annak szorosabbra venni az ütemezését mondjuk 1 órásra. De inkább a routerben állítanék be ilyesmit, az a biztos. Vagy ha van állandóan futó PC (akár RPi, vagy hasonló is), arra is lehet tenni DDNS update jobot és arra bízni ezt.
A tévedés joga fenntartva. A meccs áll egyenlőre, egyelőre ez a helyes.
-
bogabi
senior tag
Új hozzászólás Aktív témák
- DIGI kábel TV
- 5G-vel és hőkamerával strapálja magát az Ulefone
- Energiaital topic
- Kerékpárosok, bringások ide!
- Tippmix
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- PlayStation 5
- USB to S/PDif konverter a modern RIAA, elektroncsövekkel
- Google Pixel 6/7/8 topik
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen