Server/NAS/backup voor grafische studio

[Jojakim]

Laatste jaren heb vooral zelfstandig gewerkt met een enkele workstation en een NAS als archief/backup. Het laatste jaar heb ik die situatie omgebouwd voor m'n studio, voor het samenwerken met 3 werkstations en een administratieve medewerker. Het betreft een grafische studio met vooral Adobe-materiaal, af en toe video/animatie.

De huidige setup is als volgt:
- 3 x Windows werkstation
- 1 x Windows PC
- Synology 210j met 2 x 2TB WD red
- Gigabit switch (HP Procurve managed 16 poorts)
- Ziggo zakelijk met Cisco router op studio
- Ziggo home (router weet ik even niet, thomson?) thuis

Drie Windows werkstations met een SSD en een HDD, zitten via gigabit met elkaar verbonden en synchroniseren de actieve data (+-400 GB) met elkaar via Synology Cloud Station. Op de Synology staat dus die data ook op een RAID1, die weer wordt gesynchroniseerd over internet met mijn huiscomputer als ik die 's avonds aanzet. Op de NAS staat tevens nog iets van 400GB aan materiaal van oude projecten. De 4de PC heeft directe toegang tot de NAS dus heeft geen lokale kopie.



Dit werk redelijk ok, zeker gezien het budget! Maarrr.. het systeem kent ook z'n beperkingen. Synology Cloud werk soms beetje buggy: soms wil een bestand niet synchroniseren door een vaag permissie-probleem, en als iemand bijvoorbeeld een Wordpress-installatie (m.a.w.duizenden kleine bestandjes) opslaat, kan er een hinderlijke wachtrij ontstaan in de cloud synchronisatie.

Ik ben me nu dus aan het oriënteren op een meer solide oplossing. Ik zit te denken aan een nieuwe, snellere Synology, bv DS214+ of DS414 (beide met 2 ethernetaansluitingen) waar de workstations dan wellicht direct vanaf kunnen werken ipv met een synchro-kopie op de lokale HD. De oude NAS zou ik dan wellicht thuis neerzetten voor synchronisatie met cloudstation client of rsync. Het synchroniseren heeft als voordeel dat ieder rap kan werken zonder bottleneck van netwerk, maar met voldoende SSD power voor swap files is de vraag in hoeverre je daar in de praktijk last van hebt. Actieve videobewerking zullen we toch op de lokale SSD blijven doen.

Ik verwacht in de komende jaren met ongeveer 4TB effectieve ruimte wel uit de voeten te kunnen, en qua budget hoop ik beetje onder 800,- te kunnen blijven.

Wat ik me afvraag: zou een snellere NAS toereikend zijn om van te werken met 3 werkstations (met eventuele groei naar 5). Is dit een elegante oplossing of heeft iemand wellicht een betere suggestie? Ben benieuwd naar jullie mening!

[ik222]

Het direct werken van de NAS lijkt me inderdaad een prima oplossing, veel beter dan de huidige sync oplossing. Met een degelijke NAS zoals die Synology modellen zijn moet dat ook perfect werken met 5 personen en het gebruik dat je omschrijft.

Waar ik wel even naar zou kijken is naar de backup. Nu doe je puur live synchronisatie zoals ik het begrijp. Maar wat doe je als iemand per ongeluk een map met 3 maanden werk verwijderd? En wat als een van de werkstations een crypto virus oploopt en alles op de NAS versleuteld raakte?

Kortom je hebt een backupoplossing nodig die versies bijhoudt volgens een bepaald schema en retentietijd. Bewaar bijvoorbeeld een dagellijkse backup 7 dagen en een wekelijkse backup 5 weken, eventueel werken met incrementals. Als backup enkel vertrouwen op een realtime sync is niet verstandig.

[Jojakim]

Goed punt! Ik heb voorheen met het freeware-programmaatje Cobian incrementele backups gemaakt en in de huidige situatie maakt m'n huiscomputer pas backups als ik de computer 's avonds aanzet. Maar goed punt op mee te nemen in volgende opzet.

Ik heb me nog niet verdiept in backup features van Synology naar Synology maar daar zal dat ook vast mee kunnen.

[Gomez12]

Jojakim schreef op donderdag 30 juli 2015 @ 21:46:
Goed punt! Ik heb voorheen met het freeware-programmaatje Cobian incrementele backups gemaakt en in de huidige situatie maakt m'n huiscomputer pas backups als ik de computer 's avonds aanzet. Maar goed punt op mee te nemen in volgende opzet.

Ik heb me nog niet verdiept in backup features van Synology naar Synology maar daar zal dat ook vast mee kunnen.

Het probleem met backups en virussen is dat je die standaard gewoon meebackupt...

Als je nu in de huidige situatie een cryptolocker virus krijgt dan kan jij 's avonds je pc niet aanzetten en dan is dat je nog niet getroffen backup.

Zou je het enkel op 1 andere synology zetten die constant backupped (of beter gezegd waar niemand het kan onderbreken) dan heb je het crypto-virus op je live-data en een half uurtje daarna is je backup ook waardeloos.

En dan kan je wel zeggen : Ik sync alleen 's avonds bijv zodat je het kan stoppen, maar wie stopt het dan als jij bijv op vakantie bent.

De huidige oplossing is zeker niet perfect, maar qua klein bedrijfje en crypto-virussen (maar ook incidenteel verwijderen door medewerkers etc) vind ik het wel een deels elegante oplossing omdat jijzelf het proces in gang moet zetten en je maar 1 backup hebt.
Oftewel als jij op vakantie gaat heb je 3 weken geen verse backup, maar mocht er iemand alles leeggooien dan ben je enkel 3 weken werk kwijt en niet jaren en jaren (omdat de backup het verwijderen ook meegesynched heeft)

Idealiter zou ik zeggen : Maak meerdere backups (over meerdere dagen) zodat je niet hangt op 1 dag, alleen dat kost je wat meer.
Of je kan het doen zoals ik vrij veel kleine bedrijfjes zie doen : Schaf 10 externe USB-3 -hdd's aan, laat je bestaande plan gewoon doorgaan en maak een scriptje wat op een vast tijdstip per dag alle data van de synology naar een externe disk stouwt, per dag de disk verwisselen en je hebt je historie op de plank liggen.

[SpamLame]

Om je eigen vraag te herhalen,wie wisselt dan die schijven tijdens vakantie?
Toegegeven iets is beter dan niets, maar als het afhangt van een manuele actie dan maakt het ansich niet uit of dat het wisselen van een schijf is of de sync stoppen.

Dat gezegd hebbende Synology Back-up is inderdaad 1 kopie van je data elders wegzetten.
Niets houd je echter tegen meerdere destinations te definiëren op de zelfde Synology en dan meerdere schedules aan te maken die de verschillende destinations vullen.
Bv maandag schedule op maandag draaien die wegschrijft naar destinations maandag op de andere Synology.
Overigens zelf nooit geprobeerd, maar iets wat ik me zo nu bedenk.

En anders heb je ook nog "time Back-up" van Synology. Dit is een apart package die je moet installeren en stelt je in staat meerdere versies bij te houden. Ik weet niet of time Back-up ook remote/offsite destinations kent.

[Jojakim]

Ja, het liefst zou ik het allemaal automatiseren. Wellicht dan met thuis een Synology backup, die ik nog eens per week overzet op de computer.

[hans_lenze]

SpamLame schreef op vrijdag 31 juli 2015 @ 09:50:
En anders heb je ook nog "time Back-up" van Synology. Dit is een apart package die je moet installeren en stelt je in staat meerdere versies bij te houden. Ik weet niet of time Back-up ook remote/offsite destinations kent.

Ja, Time Backup doet precies wat je wilt: meerdere versies naar een lokale schijf of een externe Synology kopieren.

[Gomez12]

SpamLame schreef op vrijdag 31 juli 2015 @ 09:50:
Om je eigen vraag te herhalen,wie wisselt dan die schijven tijdens vakantie?

1 van de mensen die niet op vakantie is?

Toegegeven iets is beter dan niets, maar als het afhangt van een manuele actie dan maakt het ansich niet uit of dat het wisselen van een schijf is of de sync stoppen.

Hier ga je heel zwaar de fout in qua menselijke handelen... Mensen zijn extreem slecht in uitzonderingen (wat een sync stoppen is) maar redelijk goed in "standaard" handelingen (wat dagelijks een schijf wisselen is)

Er zit in de praktijk een heel groot verschil tussen of je probleemsituaties niets moet doen (geen schijf wisselen) of dat je niet-standaard handelingen moet verrichten

Dat gezegd hebbende Synology Back-up is inderdaad 1 kopie van je data elders wegzetten.
Niets houd je echter tegen meerdere destinations te definiëren op de zelfde Synology en dan meerdere schedules aan te maken die de verschillende destinations vullen.
Bv maandag schedule op maandag draaien die wegschrijft naar destinations maandag op de andere Synology.
Overigens zelf nooit geprobeerd, maar iets wat ik me zo nu bedenk.

Hij wil doorgroeien naar 4TB en dan ga je in de knoei komen met blinde kopieen per dag binnen 1 NAS, even ervanuit gaande dat die time Back-up het per file/block bekijkt (dus alleen kopie opslaan als bestand gewijzigd is) lijkt me dat de beste optie. Op het moment dat je zoveel wijzigingen hebt dat je NAS volzit dan heb je of genoeg werk gehad voor aanschaf nieuwe NAS of je werknemers doen iets verkeerd

[defusion]

Ik zeg, eigen server bouwen.
Met een dergelijk budget moet dat makkelijk kunnen.

degelijk mobo+cpu+16gb ram = zeg 250 euro
kast+voeding = nog eens 100?
de rest van het budget is voor de schijven, zoveel je nodig denkt te hebben.

Gooi er freenas op en een paar disks, en het werkt mega snel.
Die 16gb is handig voor freenas, die gebruikt alle beschikbare ram als cache, dus maakt het allemaal heel snel.
Verder ook makkelijk via web interface te configureren.
Freenas heeft ook ingebouwde functionaliteit om versies van documenten bij te houden, sort-of incremental backup. Maar een offsite backup is zeker ook verstandig!
Kunt verder nog kijken naar bestaande mogelijkheden als crashplan(geen ervaring mee).

[bvk]

Of gewoon een HP Proliant Microserver (met misschien meer RAM en/of andere CPU) met Windows Server 2012. En die de back-up weg laten schrijven naar MS Azure via hun back-up tool.

Dan heb je meer power voor de clients dan met een NAS lijkt me en de Azure back-up werkt prima en is niet al te duur. Dat valt denk ik allemaal wel binnen het kosten plaatje?

[Koffie]

Move PNS > NT

[Ben(V)]

De beste oplossing heb je zelf al bedacht.
Vervang de NAS door een DS414, sluit de twee netwerkpoorten aan op je switch en zet ze in een bond.
Het mooiste zou een kleine managed switch zijn zoals een HP 1820-G8v2, zodat je een LACP van die twee poorten kunt maken.

Een vier bay NAS heeft als voordeel dat je Raid5 kunt gebruiken en niet beperkt bent to Raid1.
Raid5 heeft maar 25% overhead terwijl Raid1 50% overhead heeft plus je bent veel toekomstvaster wat betref schijfruimte.

Zet je oude NAS thuis neer en gebruikt time-backup om incremental backups te maken waardoor je terug in de tijd kunt.
Dat voorkomt problemen met per ongeluk weggegooide files en/of virussen zoals een cryptolocker.

[JT]

Wat eventueel ook nog een overweging is (maar daar gaat handmatig werkt mbt instellen in zitten) is om niet je werk Synology te laten schrijven naar je thuissyno. Als je op je werk dan een cryptovirus ofzo hebt dan kan deze niks doen op je thuissyno. Wat je dan wel moet doen is op je werksyno de te backuppen directories sharen met je thuissyno die hier alleen leesrechten op heeft (genoeg om te backuppen). Zo hebben beide Syno's geen schrijftoegang bij elkaar en kunnen ze elkaar niet zo makkelijk besmetten.

[Ben(V)]

Een crypto locker versleuteld je bestanden op file niveau en kan helemaal je andere NAS niet bereiken als je die alleen configureerd voor backup.

Het risico met een sync oplossing is dat op de werk Nas de files geencrypt worden en een op een overgezet worden naar je thuis Nas en alles dus encrypt wordt.
Dus het alleen laten ophalen van je data vanaf je thuis Nas is daar dus geen oplossing voor, je hebt een backup nodig die vorige versies (van voor het encrypten) terug kan zetten.

Je gaat uiteraard niet moeilijk doen met lees en schrijfrechten tussen die twee Nassen op bestands niveau.
Je maakt alleen portforwarding mogelijke voor de juiste poort die de backup software gebruikt en dan kan alleen time-backup praten met z'n counterpart aan de andere kant en verder niets.

[ Voor 13% gewijzigd door Ben(V) op 06-08-2015 09:25 ]

[JT]

Ben(V) schreef op donderdag 06 augustus 2015 @ 09:22:
Een crypto locker versleuteld je bestanden op file niveau en kan helemaal je andere NAS niet bereiken als je die alleen configureerd voor backup.

Maar daarvoor heeft de NAS die iets wegschrijft toch echt file-access nodig om het weg te schrijven op de andere NAS

[Ben(V)]

Ja maar dat doet de de backup software aan de locale kant.
Het zijn twee apps die met elkaar communiceren, daar komt die synolocker niet tussen.
Die synolocker kan alleen op bestands niveau werken.
Die zou alleen als je een share maakt op de thuis Nas die op de werk Nas bereikbaar is daar iets kunnen doen.

[ Voor 15% gewijzigd door Ben(V) op 06-08-2015 10:38 ]

[JT]

Ben(V) schreef op donderdag 06 augustus 2015 @ 10:37:
Ja maar dat doet de de backup software aan de locale kant.
Het zijn twee apps die met elkaar communiceren, daar komt die synolocker niet tussen.
Die synolocker kan alleen op bestands niveau werken.
Die zou alleen als je een share maakt op de thuis Nas die op de werk Nas bereikbaar is daar iets kunnen doen.

Als ik 5 jaar geleden had gezegd dat een virus alles op je Synology zou encrypten had je me wellicht ook uitgelachen Time Backup heeft ergens de credentials opgeslagen waarmee er toegang wordt verkregen tot de andere NAS. Vervolgens kunnen reeds gemaakt backups via die credentials aangesproken worden, misschien met niet al teveel moeite nog wel meer dan dat op de remote NAS. Ik zou niet willen uitsluiten dat een virus in de toekomst deze gegevens te pakken kan krijgen en zich daarmee toegang verschaft tot de andere NAS.

[Ben(V)]

Jammer dat je niet begrijp hoe dingen werken.
Het heeft niets met credentials te maken. Het is de locale kant van time-backup die iets wegschrijft, dus die zou dan eerst gehacked moeten worden en dat doet zo'n crypto locker nu eenmaal niet.

Uiteraard is in theorie ook dat mogelijk, maar alleen geen enkel verbinding sluit alles uit.

Je kunt via een backup poort helemaal niets op een Nas alleen maar praten tegen een ander backup programma.

[JT]

Jammer dat je mij direct probeert te diskwalificeren met een argumentum ad hominem

Ik snap prima hoe het werkt. Een cryptolocker werkte 5 jaar geleden helemaal niet voor een Syno, moest toen ook nog gehackt worden. Wat niet is kan nog komen. En nee je kunt niks uitsluiten maar door ervoor te zorgen dat apparaten niet naar elkaar kunnen schrijven neem je in ieder geval op laag niveau een fundamenteel risico voor het grootste deel weg. Het is altijd beter (security wise) dat alleen lokale toepassingen kunnen schrijven naar de eigen opslag.

[ Voor 10% gewijzigd door JT op 06-08-2015 11:27 ]

[Gomez12]

JT schreef op donderdag 06 augustus 2015 @ 11:23:
Jammer dat je mij direct probeert te diskwalificeren met een argumentum ad hominem

Ik snap prima hoe het werkt. Een cryptolocker werkte 5 jaar geleden helemaal niet voor een Syno, moest toen ook nog gehackt worden.

Cryptolockers op synology novo zijn er wel, maar in wezen is dat geen iets waar je je zorgen om moet maken (mits je je infrastructuur netjes op orde hebt).

Dat is ook niet wat hier genoemd wordt, wat hier genoemd wordt is dat het werk besmet raakt en dat je backup vrolijk alle versleutelde bestanden ziet alszijnde gewijzigd en ze dus gaat overnemen.

Een backup-programma kan geen onderscheid maken of er nu tekst aan een word-bestand is toegevoegd of dat een cryptolocker het bestand ge-encrypt heeft. Maar het 1e wil je wel backuppen en het 2e idealiter niet. Echter is er daar geen onderscheid tussen. En je hebt er ook geen schrijftoegang of wat dan ook voor nodig.

Het gevaar met backups is niet dat je backuplocatie zelf verder gaat zitten verspreiden (dan heb je een heel verkeerd backup-protocol), het gevaar is dat je niets aan je backups hebt met een cryptolocker omdat die enkel bestandswijzigingen doet en bestandswijzigingen wil je normaliter gebackupped hebben.

Wat niet is kan nog komen. En nee je kunt niks uitsluiten maar door ervoor te zorgen dat apparaten niet naar elkaar kunnen schrijven neem je in ieder geval op laag niveau een fundamenteel risico voor het grootste deel weg. Het is altijd beter (security wise) dat alleen lokale toepassingen kunnen schrijven naar de eigen opslag.

Het lijkt mij extreem vreemd als een standaard synologie backup of time-machine dit niet gewoon zo geregeld heeft. Time-machine (of welk backup programma dan ook) heeft nooit schrijfrechten nodig.
Ik ga er eigenlijk gewoon vanuit dat de hele standaard backup nog niet eens schrijfrechten kan krijgen.

Aangezien in het concept backup (wat al decennia bestaat) er nooit schrijfrechten nodig zijn geweest (bijv ponskaarten werden al gebackupped, alleen tja, met schrijfrechten werd dat zeg maar iets moeilijker, je kan niet de originele ponskaart wat extra gaten geven vanwege schrijfrechten) komt bij mij nog niet eens het idee op dat een backup schrijfrechten kan hebben, het is nergens voor nodig en het zou extreem onlogisch zijn en het zou extreem gevaarlijk zijn.

[JT]

Gomez12 schreef op donderdag 06 augustus 2015 @ 20:08:
[...]

Cryptolockers op synology novo zijn er wel, maar in wezen is dat geen iets waar je je zorgen om moet maken (mits je je infrastructuur netjes op orde hebt).

Dat is ook niet wat hier genoemd wordt, wat hier genoemd wordt is dat het werk besmet raakt en dat je backup vrolijk alle versleutelde bestanden ziet alszijnde gewijzigd en ze dus gaat overnemen.

Een backup-programma kan geen onderscheid maken of er nu tekst aan een word-bestand is toegevoegd of dat een cryptolocker het bestand ge-encrypt heeft. Maar het 1e wil je wel backuppen en het 2e idealiter niet. Echter is er daar geen onderscheid tussen. En je hebt er ook geen schrijftoegang of wat dan ook voor nodig.

Het gevaar met backups is niet dat je backuplocatie zelf verder gaat zitten verspreiden (dan heb je een heel verkeerd backup-protocol), het gevaar is dat je niets aan je backups hebt met een cryptolocker omdat die enkel bestandswijzigingen doet en bestandswijzigingen wil je normaliter gebackupped hebben.

Helemaal mee eens hoor, van mij was slechts algemeen aanvullend

[...]

Het lijkt mij extreem vreemd als een standaard synologie backup of time-machine dit niet gewoon zo geregeld heeft. Time-machine (of welk backup programma dan ook) heeft nooit schrijfrechten nodig.
Ik ga er eigenlijk gewoon vanuit dat de hele standaard backup nog niet eens schrijfrechten kan krijgen.

Aangezien in het concept backup (wat al decennia bestaat) er nooit schrijfrechten nodig zijn geweest (bijv ponskaarten werden al gebackupped, alleen tja, met schrijfrechten werd dat zeg maar iets moeilijker, je kan niet de originele ponskaart wat extra gaten geven vanwege schrijfrechten) komt bij mij nog niet eens het idee op dat een backup schrijfrechten kan hebben, het is nergens voor nodig en het zou extreem onlogisch zijn en het zou extreem gevaarlijk zijn.

Ik bedoel meer dat een eventueel virus op NAS A, waar backup richting NAS B geconfigureerd staat dan niet zomaar binnen kan komen via het protocol dat A gebruikt om bij B binnen te komen. Waarbij er ergens een vertaalslag plaats vindt om data van A op B te krijgen. Ergens wordt er een schrijfproces aangestuurd vanaf een derde apparaat en dat kun je voorkomen. Dan kan er ook niet een virus ofzo misbruik van maken.

[ Voor 3% gewijzigd door JT op 06-08-2015 20:39 ]

[Ben(V)]

Uiteraard heeft backup wel schrijfrechten nodig, want geen rechten dan wordt er echt niets geschreven.

Wat blijkbaar een niet begrepen wordt is dat bij een remote backup je twee verschillende applicaties hebt die met elkaar praten.
Een op de werk Nas die praat tegen die op de thuis Nas.
Die laatste moet natuurlijk schrijfrechten hebben om de data daar weg te kunnen schrijven.

Dit is een heel andere situatie dan wanneer je een remote share aanbied op de thuis Nas aan de werk Nas, waarbij het backupprogramma dus rechtstreeks op die share wegschrijft.
In dat geval zou namelijk die synolocker ook gewoon op die share aan het encrypten kunnen gaan.

[JT]

Nee, dan snap je niet helemaal wat ik bedoel (wellicht dat ik het niet duidelijk genoeg heb uitgelegd) Je zorgt dat je een share van NAS A leesbaar maar niet schrijftbaar deelt met NAS B, dan kan NAS B er een backup van maken.

En NAS B moet inderdaad schrijfrechten op zichzelf hebben. In dit geval is er alleen wel een proces op een derde apparaat (NAS A) die dit aanstuurt. En dat wil ik voorkomen als dat kan. En dat kan

[Ben(V)]

Ja en ik zeg dat dat allemaal overbodig is.

Niks shares beschikbaar stellen, gewoon de backup software dat laten doen, veel veiliger.
De rsync servers praten met elkaar en daar kan niets tussen komen.

Een smb (of nfs) share over het internet is zo wie zo niet handig.
Dat zijn lan protocollen.