Te lage back-up snelheid in Veeam Agent for Windows.

[Fr0ns]

Voor kennissen maak ik een back-up van een lokale schijf (SATA HHD) vol foto's naar een NAS toe op het lokale netwerk. Dit doe ik via Veeam Agent for Windows zodat ik incrementele back-ups kan maken. Dit deed ik ooit via de back-up optie van Windows maar dit gaf elke keer problemen zonder duidelijke oorzaak dus daar ben ik mee gestopt.

Nu merk ik dat Veeam er meer dan 24 uur over doet om een back-up te maken. De schijf in kwestie is nogal luid en de PC moet constant aan staan. Van wat ik van Veeam forums begrijp loop ik tegen de read speed aan van de lokale disk. Benchmarks laten me echter niets geks zien. Van de disk in kwestie maakt hij een volume-level back-up.

De snelheid begint rond de 100MB/s read en kakt daarna rustig in naar zo'n constante 40MB/s. Het betreft een 8TB schijf met ongeveer 4,5TB aan data. Los van welke back-up oplossing ik gebruik, zijn dit normale snelheden om 4,5TB aan kleinere files in een back-up te krijgen? Zijn er betere alternatieven voor te verzinnen of is dit wel een beetje te verwachten?

Het zijn een beetje open vragen voor een vrij specifiek probleem maar ik vind ook geen andere back-up pakketten die de zelfde functionaliteit leveren. Bovendien weet ik dan niet of het probleem daar ook mee opgelost is. Ik sta best open voor iets anders maar ik zie even geen reden waarom dit zo loopt.

Het betreft:
- Een Windows 10 client met Veaam Agent for Windows 6.02 en een ST8000VN004-2M2101
- Gigabit netwerk
- Synology DS416j met 4xWD40EFRX in SHR

[nelizmastr]

Is het wel incrementeel als je per keer 4,5TB moet overpompen? Lijkt me niet dat-ie elke keer een full backup moet gaan maken en dat er per keer 4,5TB aan nieuwe data is.

Verder, tja, je verliest op twee plekken snelheid door overhead (1. schijf naar USB controller naar PC, 2. PC naar NAS over netwerk) en daarnaast is de 100MB/s (tevens maximum van gigabit ethernet) waarschijnlijk alleen zolang de data in de cache van de schijf staat, waarna de rest ongecachet over moet, wanneer je bestanden dan <50MB per stuk zijn zul je al snel merken dat de snelheid inkakt. Kan ook nog een beperking aan de NAS zijde zijn, met een 7 jaar oude budget NAS en een RAID5 met write penalty.

Al met al klinkt het mij niet onlogisch.

[Fr0ns]

Volgens Veeam is dit incrementeel en zit ik puur naar de read speed van mijn lokale disk te kijken als ik de support forums moet geloven. Kan me voorstellen dat hij beide bulten data moet gaan vergelijken. Kan me ook voorstellen dat ik in de ietwat beperkte versie van Veeam niet veel duidelijkheid krijg.

Dit is overigens geen USB disk maar een interne SATA HDD.

Wat zou een alternatief zijn hiervoor? Mijn insteek is om het automatisch te laten draaien dus USB schijven gaan wisselen valt al af. De files alleen op de NAS zetten en een tweede NAS als back-up regelen wordt wellicht ook wat te gek qua kosten. Daarbij zitten we dan nog steeds vast aan de doorvoersnelheid van de huidige NAS.

[Xanthine]

Kan je dan niet beter de Synology Drive Client gebruiken op de computer? Dan loopt er in realtime een sync naar de NAS.

Als je dan alsnog een backup wil maken kan dat op de NAS zelf via DSM.

[Oon]

Als ze toch een Synology hebben staan zou ik zoals @Xanthine aangeeft lekker de software van Synology gebruiken, die werkt goed.

Maar als de snelheid inkakt lijkt het me dat eerder de schijven in de NAS tegen schrijfsnelheid aanlopen dan dat het aan de leessnelheid ligt. Schrijfsnelheid begint altijd redelijk hoog door caching, maar zo gauw de cache vol zit zakt die.

[The_Doman]

Ook al eens getest met een ander , meer efficiënt, file copy tool naar je nas om te zien waar de bottleneck nu precies zit?
Met TotalCommander bijvoorbeeld.
Antivirus tijdelijk uitzetten of mappen excluden?

[Fr0ns]

Xanthine schreef op donderdag 10 augustus 2023 @ 16:38:
Kan je dan niet beter de Synology Drive Client gebruiken op de computer? Dan loopt er in realtime een sync naar de NAS.

Als je dan alsnog een backup wil maken kan dat op de NAS zelf via DSM.

Hoewel ik de tool super handig vind ben ik huiverig voor realtime sync i.v.m. ransomware aanvallen. De NAS staat dan nu ook niet gemount op de client en enkel Veeam heeft de credentials om er naar te verbinden.

Oon schreef op donderdag 10 augustus 2023 @ 16:41:
Als ze toch een Synology hebben staan zou ik zoals @Xanthine aangeeft lekker de software van Synology gebruiken, die werkt goed.

Maar als de snelheid inkakt lijkt het me dat eerder de schijven in de NAS tegen schrijfsnelheid aanlopen dan dat het aan de leessnelheid ligt. Schrijfsnelheid begint altijd redelijk hoog door caching, maar zo gauw de cache vol zit zakt die.

Wat betreft de snelheid geloof ik dat graag alleen zou hij bij een incrementele back-up natuurlijk ook niet veel weg moeten schrijven. Echter loopt de back-up nu al zo lang slecht dat het ook gewoon kan zijn dat hij wel incrementeel is maar nu geen goede originele data heeft.

Zo lees ik dat tenminste hier: https://helpcenter.veeam..../backup_chain.html?ver=60

[Fr0ns]

The_Doman schreef op donderdag 10 augustus 2023 @ 18:33:
Ook al eens getest met een ander , meer efficiënt, file copy tool naar je nas om te zien waar de bottleneck nu precies zit?
Met TotalCommander bijvoorbeeld.
Antivirus tijdelijk uitzetten of mappen excluden?

Dit lijkt me zeker interessant om te gaan testen, kan ik dan beter testen met een bult losse / kleine files of juist met één groot bestand?

[boers706]

Je kunt ook rsync op de pc installeren en daarmee je foto's synchroniseren met de diskstation. Dan kopieert hij alleen de nieuwere bestanden of gewijzigde bestanden (is een instelling). Mocht je dan een ransom aanval krijgen dan staan de originele bestanden nog steeds veilig.

Dan duurt de backup nog maar een fractie van de tijd die het je nu kost.

[Ben(V)]

Hoe denk je dat een incremental backup werkt?
Hij moet eerst de meta data van alle files op de bron lezen, dan moet hij kijken of die files op de target aanwezig zijn en dan besluiten al of niet een backup van die file te maken.

Als dat video bestanden zijn gaat dat redelijk effectief maar grote aantallen kleine bestanden zoals foto's levert dan ontzettend veel overhead op.

Niet alleen bij een backup, maar als je een folder met veel foto's lokaal kopieert tussen bijvoorbeeld twee disken dan gaat dat al ontzettend veel langzamer dan een groot bestaan van in totaal dezelfde hoeveelheid diskruimte.

Heel veel kleine bestanden is funest voor een backup.
Synchen is hier inderdaad veel effectiever, want dat gebeurd enkel als je een bestand wijzigt of toevoegt.

En het ransomeware verhaal geld in dezelfde mate voor Veenam, die verbinding kan ook gehacked worden.
Synology drive is waarschijnlijk beter beveiligt dan de simpele username/password die Veenam gebruikt.

[Fr0ns]

Ben(V) schreef op vrijdag 11 augustus 2023 @ 08:56:
Hoe denk je dat een incremental backup werkt?
Hij moet eerst de meta data van alle files op de bron lezen, dan moet hij kijken of die files op de target aanwezig zijn en dan besluiten al of niet een backup van die file te maken.

Als dat video bestanden zijn gaat dat redelijk effectief maar grote aantallen kleine bestanden zoals foto's levert dan ontzettend veel overhead op.

Niet alleen bij een backup, maar als je een folder met veel foto's lokaal kopieert tussen bijvoorbeeld twee disken dan gaat dat al ontzettend veel langzamer dan een groot bestaan van in totaal dezelfde hoeveelheid diskruimte.

Heel veel kleine bestanden is funest voor een backup.
Synchen is hier inderdaad veel effectiever, want dat gebeurd enkel als je een bestand wijzigt of toevoegt.

En het ransomeware verhaal geld in dezelfde mate voor Veenam, die verbinding kan ook gehacked worden.
Synology drive is waarschijnlijk beter beveiligt dan de simpele username/password die Veenam gebruikt.

Ik zeg ook absoluut niet dat ik het raar vind dat het lang duurt maar ik probeer een inschatting te maken of ik iets aan de opstelling moet veranderen of dat deze snelheid moet accepteren. Ik ben me bekend dat vele losse files meer werk is alleen is de vraag of (geschat) 30 uren een normale tijd is.

Hij is er nu in ieder geval doorheen aan het ploeteren, zodra de back-up gelukt is zet ik hem nog wel een keer aan, dan weten we of het gewoon een gebrek was aan een goede kopie en hij dus een volledige back-up heeft gedaan of dat het altijd zo lang gaat duren.

Mijn ransomware punt ging overigens niet over het achterhalen van credentials of iets dergelijks maar over een infectie op het lokale werkstation die de boel versleutelt waarna de sync client die verleutelde bestanden naar de NAS synchroniseert.

[Rensjuh]

Word me even niet duidelijk uit je OP, maar is dit je eerste backup die je nu gaat maken sinds je Veeam gaat gebruiken?

Dan gaat ie eerst alles backup en daarna enkel de bestanden die gewijzigd zijn / erbij zijn gekomen.
Dus ja, in het begin gaat het wel even duren als ie alles moet doen.
Daarna enkel de wijzigingen dus dan zou het sneller moeten gaan.

[pistole]

^^ wat @Rensjuh zegt. Als het niet de eerste is, maar wel een incrementele: controleer de logs! Als het op basis is van VSS en de snapshot lukt (om welke reden dan ook) niet, dan zal hij terugvallen naar volledige backup/alle data doorploeteren op zoek naar verschillen.

Een initiele backup kan lang duren door throughput, maar kan ook beïnvloed worden door de aard van de data (index opbouwen als veel kleine bestanden zijn duurt lang).

[Fr0ns]

Rensjuh schreef op vrijdag 11 augustus 2023 @ 13:47:
Word me even niet duidelijk uit je OP, maar is dit je eerste backup die je nu gaat maken sinds je Veeam gaat gebruiken?

Dan gaat ie eerst alles backup en daarna enkel de bestanden die gewijzigd zijn / erbij zijn gekomen.
Dus ja, in het begin gaat het wel even duren als ie alles moet doen.
Daarna enkel de wijzigingen dus dan zou het sneller moeten gaan.

Sorry, het is nogal een verhaal dus ik hoop dat het wat duidelijk wordt.

De back-up zoals hij ingericht is loopt al een paar jaar maar duurde naar zeggen van de kennis in kwestie nooit zo lang. Dit kan ik echter niet controleren. Schijnbaar heeft dit in het verleden steeds maar een avondje geduurd. De hoeveelheid data is op geen enkel moment gekrompen maar verder ook niet explosief gestegen.

Recent is de back-up een paar keer misgegaan door een gebrek aan schijfruimte op de NAS wat weer verholpen is. Er zou dus uit het verleden een werkende kopie moeten zijn en verwacht ik enkel een incrementele back-up. Echter kan ik me ook voorstellen dat Veeam bedenkt dat het weer tijd is voor een volledige back-up. Dat krijg ik uit de beperkte logging moeilijk los.

[pistole]

Fr0ns schreef op vrijdag 11 augustus 2023 @ 13:51:
[...]
Echter kan ik me ook voorstellen dat Veeam bedenkt dat het weer tijd is voor een volledige back-up. Dat krijg ik uit de beperkte logging moeilijk los.

Dat doet Veeam alleen als er een reden voor is, en dat zou in de logs moeten zijn terug te vinden. Check ook eventlogs, en zoek naar VSS / Volume Snapshot.

[Fr0ns]

Zojuist even gehoord hoe het gelopen is, de back-up was na ongeveer 48 uur nog niet op de helft, de PC is daarna uitgezet. Niet heel handig maar het geeft wel aan hoe lang het duurt.

In de restore optie vond ik wel gewoon een full back-up en een paar incrementals. Het zij van ongeveer 3 maanden oud maar ze zijn er wel. In de logs zie ik niet per sé heel veel spannends behalve de volgende meldingen:

code:

[02.08.2023 11:52:11] <01> Error       bij Veeam.Backup.AgentProvider.CBackupClient.OnInvokeError(Exception e, String command, CVCPCommandArgs inArgs)
[02.08.2023 11:52:11] <01> Error       bij Veeam.Backup.AgentProvider.CBackupClient.Invoke(String command, CVCPCommandArgs inArgs, Boolean noLog)
[02.08.2023 11:52:11] <01> Error       bij Veeam.Backup.AgentProvider.CBackupClient.DataTransferSyncDisk(ISourceDiskSpec source, ITargetDiskSpec target, Boolean serverHandlesSource, String operationId, Boolean treatProcessedLikeReaded)
[02.08.2023 11:52:11] <01> Error       bij Veeam.Backup.Core.CAgentSyncDiskTransport.<>c__DisplayClass25_0.<SyncDisk>b__0()
[02.08.2023 11:52:11] <01> Error       bij Veeam.Backup.Core.CAgentSyncDiskTransport.ProcessDisk(IDiskTaskSource diskTaskSource, IDiskTaskTarget diskTaskTarget, CPreloadedDiskDigests digestses)
[02.08.2023 11:52:11] <01> Error    Shared memory connection was closed. (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error       in c++: Failed to write data into shared memory IO device.
[02.08.2023 11:52:11] <01> Error       in c++: Failed to send block ( offset: '816375324848', data size: '1048552', index: '778574')
[02.08.2023 11:52:11] <01> Error       in c++: Failed to join send retry thread. Transmission was not correctly finalized.
[02.08.2023 11:52:11] <01> Error       in c++: Failed to process conveyored task.
[02.08.2023 11:52:11] <01> Error    Failed to upload disk. (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error       in c++: Disk upload failed.
[02.08.2023 11:52:11] <01> Error    Agent failed to process method {DataTransfer.SyncDisk}. (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error    Exception from server: Er is een onverwachte netwerkfout opgetreden (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error    Failed to write data to the file [\\Synology\VEEAM2\Backup\Backup2023-07-30T200059.vbk]. (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error       in c++: Error code: 0x0000003b
[02.08.2023 11:52:11] <01> Error       in c++: Failed to process de-duplicated block
[02.08.2023 11:52:11] <01> Error       in c++: Failed to write block to blocks store.
[02.08.2023 11:52:11] <01> Error       in c++: Failed to append block. FIB index: [783711]. FIB: [ff595b2d-a89e-409b-b6ea-b4a6b25a0c86].
[02.08.2023 11:52:11] <01> Error       in c++: Failed to process area [Data block. Start offset: [821780545536], Length: [1048576], Area ID: [783502].] (Backup of the FIB ff595b2d-a89e-409b-b6ea-b4a6b25a0c86).
[02.08.2023 11:52:11] <01> Error       in c++: Failed to wait for recorder invoke.
[02.08.2023 11:52:11] <01> Error       in c++: Failed to check queue and pending invoke status. Wait flag 'true'.
[02.08.2023 11:52:11] <01> Error       in c++: FIB proxy was unable to process write operation, recorder '0x000001AE57C0BE60', area offset '821937831936', FIB 'Backup of the FIB ff595b2d-a89e-409b-b6ea-b4a6b25a0c86'.
[02.08.2023 11:52:11] <01> Error       in c++: Unable to asynchronously write data block. Block identity: [Data block. Start offset: [821937831936], Length: [1048576], Area ID: [783652].].
[02.08.2023 11:52:11] <01> Error       in c++: Processing of asynchronous write requests has failed. Output file: [Backup of the FIB ff595b2d-a89e-409b-b6ea-b4a6b25a0c86].
[02.08.2023 11:52:11] <01> Error       in c++: Failed to process conveyored task.
[02.08.2023 11:52:11] <01> Error    Failed to download disk. (Veeam.Backup.Common.CCppComponentException)
[02.08.2023 11:52:11] <01> Error       in c++: Disk download failed.
[02.08.2023 11:52:11] <01> Error       in c++: Unable to run ProtoEx server session.
[02.08.2023 11:52:11] <01> Error       in c++: Failed to handle ProtoEx session.
[02.08.2023 11:52:11] <01> Error       in c++ event: ClientErrorEvt

Hij lijkt daarna echter wel door te gaan waardoor ik niet helemaal weet of dit erg is of niet. Dit zie ik in meerdere sessies voorbij komen.

[The_Doman]

Dat lijken mij toch wel serieus te nemen foutmeldingen.
Afgaande op de foutmeldingen is er een verbindingsprobleem met de Synology NAS?
De log files van de Synology eens opvragen?
Misschien staat daar ook wat meer info in.

[Fr0ns]

The_Doman schreef op woensdag 16 augustus 2023 @ 15:16:
Dat lijken mij toch wel serieus te nemen foutmeldingen.
Afgaande op de foutmeldingen is er een verbindingsprobleem met de Synology NAS?
De log files van de Synology eens opvragen?
Misschien staat daar ook wat meer info in.

Sorry voor het late antwoord, de vakantieperiode is altijd wat lastig. In de logs van de Synology kom ik naar mijn idee geen gekke dingen tegen. Wat ik aan logging voorbij zie komen is in het verbindingslogboek.

Daar zie ik een paar keer dat hij meldt dat de user in kwestie de share waar de back-up komt benaderd. Hij heeft vanaf gisteravond aangestaan en meldt vooral bij het starten van de back-up dit een paar keer. Daarna periodiek nog eens een keer maar verder zie ik niets op de Synology ten tijde van de back-up.

Hij heeft nu 18 uur gelopen en is op een kwart aldus de VEEAM Agent.

Wel zie ik een uptime van rond de 120 dagen op de Synology dus ik ga hem nu ook even updaten en rebooten.

[Ben(V)]

Rebooten van een Nas omdat hij 120 dagen uptime heeft is uiteraard zinloos.
Aan je logging te zien heb je eerder een netwerk probleem.

[Fr0ns]

Ben(V) schreef op dinsdag 29 augustus 2023 @ 12:46:
Rebooten van een Nas omdat hij 120 dagen uptime heeft is uiteraard zinloos.
Aan je logging te zien heb je eerder een netwerk probleem.

Niet omdat hij 120 dagen up is maar omdat het probleem ook rond die tijd is ontstaan. Van de logging in de Synology maak ik nog niet heel veel op, wellicht is het het werkstation. Wat zou een richting kunnen zijn om dit te troubleshooten? Realtime testen wordt al lastig denk ik gezien de lange looptijd.

[_JGC_]

VEEAM en SMB/NFS shares zijn nog nooit vriendjes geweest qua snelheid, zeker niet bij incrementals.

Liep ik bij een klant ook tegenaan. Toen hun NAS stierf heb ik er een fileserver voor teruggehangen met linux erop. Repository ingericht via de VEEAM agent en loopt nu als een trein.
Weet niet of die software native op je NAS kan draaien en of je NAS daar geheugen voor heeft, maar is iets om in overweging te nemen.

[Ben(V)]

Veenam en smb geeft vaker problemen zoals @_JGC_ al opmerkte.

Je kunt proberen een iscsi disk op je Nas te maken of nfs gebruiken.

Ook zou je een C2 object storage kunnen gebruiken als veenam repositary.
Zie;
https://www.blackvoid.clu...rage-as-veeam-repository/

[Fr0ns]

Het liefst vervang ik de software op de Synology niet, dan kan ik beter voor een ander product gaan. Daar heb ik te weinig ervaring mee.

Wat me vreemd blijft is dat dit op deze manier ooit wel snel is geweest. Het werken met een ISCSI disk kan maar dan moet ik de back-up weggooien i.v.m. schijfruimte wat ik het liefst alleen doe als ik zeker weet dat dit de oplossing is. Ook mount ik dan de disk met back-ups op het werkstation wat ik liever niet heb. Of dat moet anders kunnen natuurlijk.

Online storage gaat hem kostentechnisch niet worden ben ik bang.

Ik snap zeker dat ik jullie ook met een flauw gezeur opzadel maar ik ben een beetje bang dat de werkelijke oorzaak niet gevonden is en we straks helemaal zonder back-up zitten en het nog niet werkt.