Trage dataoverdacht op interne netwerk

[Rik.]

Goedenavond,

Ik gebruik sinds vandaag een Zyxel NSA310S om mijn lokale backups op op te slaan (Verder heb ik nog een Backup in de cloud en eentje af en toe op een externe HDD)

De eerste backup die gemaakt wordt is natuurlijk een volledige backup, waardoor het logisch is dat dit lang kan duren. Maar zo lang als de backup er vandaag over deed, lijkt mij niet normaal, vandaar ook dit topic.

De bestanden die in de backup meegenomen worden zijn totaal 86GB groot, waardoor je zou zeggen dat dit in een aantal uur klaar kan zijn op een intern netwerk met apparaten die allemaal 1Gbps aansluitingen hebben... helaas deed hij over zo'n 50GB al ruim 6 uur. Mijn backup naar de cloud ging zelfs een stuk sneller terwijl dit over een 100Mbps glasvezel lijn gaat...

De backup deelt alles op in blocks van 50MB, tenzij de bestanden kleiner zijn, dan worden de blocks natuurlijk gewoon de file size..

Weet iemand waardoor het kan dat de backup zo extreem lang duurt?

Sorry voor het misschien wat onduidelijke topic, deze is vanaf mijn mobiel gepost..

[unezra]

Interessante vraag maar er mist nogal wat informatie waardoor hier zo goed als niets over te zeggen is.

- Hoe ziet je interne netwerk er precies uit
- Wat voor software gebruik je voor backups
- Van waar naar waar backup je
- Gaan normale filetransfers wel snel
- Etc.

86G zou er niet heel lang over mogen doen. Aan de andere kant, backups kunnen traag zijn. Wij backuppen op kantoor rond de 10T. Daar doen we rond de 4 dagen over inclusief verify. (Backup naar tape, bottleneck daar is de U320 SCSI interface.)

[Rik.]

unezra schreef op woensdag 8 november 2017 @ 23:19:
Interessante vraag maar er mist nogal wat informatie waardoor hier zo goed als niets over te zeggen is.

- Hoe ziet je interne netwerk er precies uit
- Wat voor software gebruik je voor backups
- Van waar naar waar backup je
- Gaan normale filetransfers wel snel
- Etc.

86G zou er niet heel lang over mogen doen. Aan de andere kant, backups kunnen traag zijn. Wij backuppen op kantoor rond de 10T. Daar doen we rond de 4 dagen over inclusief verify. (Backup naar tape, bottleneck daar is de U320 SCSI interface.)

Bedankt voor je reactie Unezra.

Ik kan eventueel morgen wel een netwerk tekening maken, maar verwacht dat het zo ook wel duidelijk kan worden:

Internet komt binnen met glasvezel op een Draytek Vigor Modem/Router, daar staat DHCP en Wireless uit, en gaat een kabel naar een Asus RT-AC66U, deze verzorgt de wifi en DHCP. Op de een of andere manier doet deze ook nog dienst als router... dat kreeg ik niet opgelost maargoed dat is niet iets voor nu. (Draait Advanced Tomato)

Op de Asus router zit in de meterkast de Zyxel NSA310S aangesloten. Ook zit daar een kabel op aangesloten die naar boven loopt naar een switch, daarop zit de NAS aangesloten die de backups moet maken.
Natuurlijk zitten er nog wat laptops en smartphones etc... aangesloten, maar is volgens mij niet van belang bij deze issue.

Op de NAS draait Windows Server 2012 met daarop Duplicati voor de backups (ben zeer tevreden over deze software en naar de cloud - stack - gaat dat zeer snel).

Ik maak de backups vanaf de NAS (windows server 2012 bak) naar de Zyxel NSA310S.

Normale filetransfers gaan gewoon snel, dat heb ik al geprobeerd door een ingepakt bestand van ongeveer 15GB over te zetten naar de Zyxel.

Backups worden gedaan via FTP, ik weet dat dit gewoon in plain text over het netwerk gaat maar aangezien het alleen over het lokale netwerk gaat vind ik dit geen probleem. Backups naar stack gaan via Webdav, dus daar is verder niks mee aan de hand.

De files worden met AES geëncrypt, met een ander wachtwoord dan degene die nodig is voor het verbinden met de FTP server, dus decrypten is sowieso al vermoeilijkt..

Hopelijk is het zo wat duidelijker voor jullie .

---

Edit:
Misschien handig om te weten, ik kan bij het aanmaken van de backup kiezen voor FTP of FTP (Alternatief). Als ik kies voor FTP moet ik een poort invullen waarbij ik kies voor de manier zonder SSL. Als ik kies voor FTP (Alternatief), is de keuze van SSL er niet..

Kan het er iets mee te maken hebben dat de data door een router moet i.p.v. een switch? En maakt dat dan echt zoveel verschil? Het gaat nu via deze poorten: LAN1 naar LAN3..

[ Voor 45% gewijzigd door Rik. op 09-11-2017 20:08 ]

[Rik.]

Niemand die hier iets voor weet?

[GioStyle]

Ik maak de backups vanaf de NAS (windows server 2012 bak) naar de Zyxel NSA310S.

Grote kans dat het aan je Zyxel ligt, die kan niet sneller wegschrijven.

[ Voor 4% gewijzigd door GioStyle op 09-11-2017 20:55 ]

[Rik.]

GioStyle schreef op donderdag 9 november 2017 @ 20:54:
[...]


Grote kans dat het aan je Zyxel ligt, die kan niet sneller wegschrijven.

Lijkt mij vreemd en uitgesloten, aangezien handmatige upload wel snel gaat...

[GioStyle]

Rik. schreef op donderdag 9 november 2017 @ 20:56:
[...]

Lijkt mij vreemd en uitgesloten, aangezien handmatige upload wel snel gaat...

Via dezelfde protocol?

[Rik.]

GioStyle schreef op donderdag 9 november 2017 @ 20:58:
[...]


Via dezelfde protocol?

Beide gaan via FTP, natuurlijk gaat het dan niet om 86GB, maar een bestand van zo'n 15GB gaat gewoon zeer snel. Ik denk persoonlijk dat het aan de block size ligt, die is bij Duplicati standaard 50MByte en dus upload hij bestanden die groter zijn in blokken van 50MByte. Bestanden kleiner dan 50MByte gaan volgens mij wel als gehele file.

Inmiddels staat zip compression uit, waardoor het al wat sneller zou moeten gaan.

Sinds dat zip compression uit staat, heeft hij ongeveer 20GB geupload in een uur... het is iets sneller maar nog lang niet zoals gewenst..

---

Edit: Hoogstwaarschijnlijk is het gewoon de CPU die niet sneller is.. Het gaat hier om een Intel Celeron J3160. Als ik in taakbeheer kijk haalt hij telkens als hij een bestand upload naar de Zyxel zo'n 300Mbps waardoor hij dus helaas niet het volledige netwerk kan benutten. Dit is jammer maar voor nu niks aan te doen, en is eigenlijk ook maar eenmalig dat er zoveel data overzet moet worden, aangezien dit de eerste backup is..

Iedereen bedankt voor de hulp!

[ Voor 35% gewijzigd door Rik. op 09-11-2017 22:27 ]

[unezra]

@Rik. Sorry dat ik wat laat reageer. (Druk druk druk en ik had even de tijd niet me echt in je vraag te verdiepen.) Anyway, als je CPU de bottleneck is, zou je dat ook aan de CPU load moeten zien. Schiet die niet omhoog tijdens die transfer?

Misschien tijd om die Zyxel NAS de prullenbak in te gooien en te vervangen door een fatsoenlijk apparaat.:)

[Rik.]

unezra schreef op vrijdag 10 november 2017 @ 18:56:
@Rik. Sorry dat ik wat laat reageer. (Druk druk druk en ik had even de tijd niet me echt in je vraag te verdiepen.) Anyway, als je CPU de bottleneck is, zou je dat ook aan de CPU load moeten zien. Schiet die niet omhoog tijdens die transfer?

Misschien tijd om die Zyxel NAS de prullenbak in te gooien en te vervangen door een fatsoenlijk apparaat.:)

Maakt niet uit hoor @unezra .

Het gaat niet om de CPU load op de Zyxel maar die op de main NAS (Windows machine). Helaas heb ik die machine nog niet zo lang, en is CPU vervangen geen optie, omdat deze vast zit op het moederboard... Deze is uitgekozen aangezien hij zuinig is, en voor de doeleinden waarvoor ik hem gebruik gewoon prima geschikt is, maar blijkbaar niet om een gigabit backup met Duplicati dicht te trekken, maarja...

De CPU load schiet tijdens de transfer op de Windows Machine zeker wel omhoog, maar ook op de Zyxel. Dus het kan denk ik alsnog aan de Zyxel NAS liggen maar ik verwacht persoonlijk van niet omdat hij op de Windows Machine ook richting de 99% schiet... (Heel af en toe)

[ Voor 13% gewijzigd door Rik. op 10-11-2017 19:00 ]

[Ben(V)]

Het ligt aan je backup software.
Die 50 MB blokken nekken je snelheid.

Hetzelfde gebeurt met gewone file transfers, kopieer maar eens een folder met veel kleine bestanden dan zakt de snelheid ook dramatisch in elkaar

[Rik.]

Ben(V) schreef op vrijdag 10 november 2017 @ 22:14:
Het ligt aan je backup software.
Die 50 MB blokken nekken je snelheid.

Hetzelfde gebeurt met gewone file transfers, kopieer maar eens een folder met veel kleine bestanden dan zakt de snelheid ook dramatisch in elkaar

Wat is volgens jou dan de ideale block size?

[The Eagle]

En knal die encryptie eens uit. Dat kost ook een hoop CPU.

[Rik.]

The Eagle schreef op vrijdag 10 november 2017 @ 22:39:
En knal die encryptie eens uit. Dat kost ook een hoop CPU.

Dat is een goede inderdaad! Ik dacht dat duplicati encryptie verplicht had gesteld, maar blijkbaar niet.. dat ga ik eens snel proberen

[Ben(V)]

Blokgrootte zo groot mogelijk.
Op een lan isdat het efficients

[Rik.]

Ben(V) schreef op vrijdag 10 november 2017 @ 22:42:
Blokgrootte zo groot mogelijk.
Op een lan isdat het efficients

Stel, dat ik deze block size instel op 2GB. Dan maakt hij van bestanden die 2GB of groter zijn, natuurlijk blocks van 2GB. Maar bestanden van 1MB worden die dan allemaal samengevoegd tot er uiteindelijk blocks zijn van 2GB? Ik dacht altijd dat hij alles wat zo groot is als de block size, of groter, wordt zo groot als de block size, maar kleiner behoud gewoon originele size...

[Ben(V)]

Is natuurlijk afhankelijk van je backup software, maar een beetje backup software voegt gewoon bestanden samen, stuurt de data als een blok over en pas aan de andere kant worden er weer files van gemaakt.

[Rik.]

Ben(V) schreef op vrijdag 10 november 2017 @ 23:16:
Is natuurlijk afhankelijk van je backup software, maar een beetje backup software voegt gewoon bestanden samen, stuurt de data als een blok over en pas aan de andere kant worden er weer files van gemaakt.

Dat er aan de andere kant weer files van worden gemaakt is bij Duplicati niet.. Hij stuurt ze als .zip (of .zip.aes, maar dat is enkel als encryptie aan staat) en dat blijven ze ook aan de andere kant.

Maar welke block size zou jij aanraden dan in dit geval?

[Ben(V)]

Zo groot mogelijk zoals ik al zei
Kleine blok size zijn handig bij onbetrouwbare verbindingen, maar op een lan die niet overbelast wordt is het alleen overhead.

[ Voor 65% gewijzigd door Ben(V) op 10-11-2017 23:27 ]

[Rik.]

Ben(V) schreef op vrijdag 10 november 2017 @ 23:25:
Zo groot mogelijk zoals ik al zei

Ik ben het nu aan het proberen met 5GB blocks, eens kijken of dat wat sneller gaat. Ik begrijp eigenlijk dus dat jij het zelfs nog groter zou doen?

Wat gebeurd er als er op een dag maar 1 bestand van ongeveer 500MB gewijzigd is, dan zet hij neem ik aan wel alleen die file over, en stopt dat dus niet in 5GB blocks, omdat er gewoon niet meer data is om te kopiëren?

Offtopic: Iedereen maar eens even thumbs up gegeven, hulp is altijd fijn dus verdiend thumbs up

---

Edit:
Bij de 5GB blocks trekt hij alsnog maar ongeveer 380Mbps, en de CPU van de Zyxel draait dan op ongeveer 95%.. Het probleem zal dus 100% zeker in de Zyxel zitten, of in de disk die daarin zit (WD Blue).

De Zyxel ga ik hiervoor niet vervangen (Tenzij iemand nog een simpele 1 Bay nas heeft staan die weg moet? ), aangezien het puur om backups gaat en ik dat ding nog had staan. Het is ook niet het enige backup medium dus dan is het al iets minder belangrijk dan dat het alleen naar de Zyxel zou gaan...

[ Voor 39% gewijzigd door Rik. op 10-11-2017 23:49 . Reden: Toevoeging na testen 5GB blocks ]

[Ben(V)]

Voor een backup is 380Mbps helemaal niet zo slecht hoor.
800 Mbps is ongeveer het maximale dat je uit een 1Gb netwerk zou kunnen halen met alles geoptimaliseerd en alleen het netwerk als beperkende factor.

Dus zit daar zo'n beetje op de helft van, je moeten reken dat een backup nog behoorlijk wat overhead met zich meebrengt.

[Rik.]

Ben(V) schreef op zaterdag 11 november 2017 @ 09:06:
Voor een backup is 380Mbps helemaal niet zo slecht hoor.
800 Mbps is ongeveer het maximale dat je uit een 1Gb netwerk zou kunnen halen met alles geoptimaliseerd en alleen het netwerk als beperkende factor.

Dus zit daar zo'n beetje op de helft van, je moeten reken dat een backup nog behoorlijk wat overhead met zich meebrengt.

Aah, top! Bedankt voor de uitleg Ben . Kan dus redelijk tevreden zijn met de snelheid

[The Eagle]

Qua tijden zijn bij backups twee zaken echt belangrijk:
- hoe lang kun je backuppen zonder impact op business (performance, apps down, etc)
- hoe snel moet iets bij een restore weer up zijn, en binnen hoeveel tijd moet je dus terug kunnen zetten.
Uiteraard weegt die tweede zwaarder.

Als er een backup is maar terugzetten kost twee dagen en moet dan gecontroleerd worden, ben je dus 3 dagen plat met je bedrijf. Das nie leuk nie, zelfs niet voor MKB

[Rik.]

The Eagle schreef op zaterdag 11 november 2017 @ 13:45:
Qua tijden zijn bij backups twee zaken echt belangrijk:
- hoe lang kun je backuppen zonder impact op business (performance, apps down, etc)
- hoe snel moet iets bij een restore weer up zijn, en binnen hoeveel tijd moet je dus terug kunnen zetten.
Uiteraard weegt die tweede zwaarder.

Als er een backup is maar terugzetten kost twee dagen en moet dan gecontroleerd worden, ben je dus 3 dagen plat met je bedrijf. Das nie leuk nie, zelfs niet voor MKB

Gelukkig gaat het om een thuis situatie en is downtime eigenlijk vrijwel niet van toepassing. Minder van belang iig dan bij bedrijven..

[The Eagle]

Dat had ik even gemist. Maar dan fraag ik me af of je niet veel beter een andere setup kunt hanteren:
- alle werkbestanden op de NAS (homedrives)
- sync van bestanden naar de cloud

[MrPompidom]

De Celeron cpu ondersteund geen AES encryptie vanuit de cpu zelf. Dat is de vertragende factor naar mijn idee. I3 of hoger hebben die instructieset ingebakken zitten.

[Rik.]

The Eagle schreef op zaterdag 11 november 2017 @ 15:19:
Dat had ik even gemist. Maar dan fraag ik me af of je niet veel beter een andere setup kunt hanteren:
- alle werkbestanden op de NAS (homedrives)
- sync van bestanden naar de cloud

Bestanden worden gebackupt naar stack en naar de zyxel NAS. Prima voor deze situatie..

MrPompidom schreef op zaterdag 11 november 2017 @ 15:24:
De Celeron cpu ondersteund geen AES encryptie vanuit de cpu zelf. Dat is de vertragende factor naar mijn idee. I3 of hoger hebben die instructieset ingebakken zitten.

Aah, vandaar. Gelukkig staat encryptie nu dan uit, is toch maar lokaal dus maakt niks uit..