"Intelligent" Data Syncen.

[HeepH]

Ik heb een situatie met 2 lokaties. Lokatie A bevat data waarmee dagelijks gewerkt word, lokatie B bevat de backup van deze data.

Aan het eind van de dag word Lokatie B gesynched met de laatste wijzigingen op lokatie A. Echter bevat A voor zo'n 500 GB aan files (400.000+ files / 30.000 folders) en deze moeten gesynched worden over een normale (trage) ADSL lijn.

Is het mogelijk om lokaal te bekijken welke files gewijzigd zijn vergeleken met gisterenavond en dan alleen deze naar lokatie B te synchen? Zodat niet voor elke file de (30-60ms) delay van het remote checken of deze file gewijzigd is sinds gisterenavond.

En zou dit een significante prestatie verbetering opleveren? Nu lukt het regelmatig niet om binnen 12u deze synch af te ronden.

Disk I/O en Bandbreedte verhogen/vergroten zijn GEEN optie. Comprimeren van 500 GB ook niet. Wellicht wel het comprimeren van de files die als gewijzigd gemarkeerd zijn maar dan blijft het bovenstaande probleem primair

TLDR : Ik wil een lijst van gewijzigde files op lokatie A en alleen deze files over mijn lijn naar lokatie B trekken.

[NiteFly]

Volgens mij kan dit met Goodsync. Ik heb het vroeger gebruik en voor het daadwerkelijk syncen checkte het programma eerst alle mappen/bestanden op wijzigingen. Dit lijkt me vrij standaard eigenlijk. Of begrijp ik je vraag verkeerd?

[freelh]

NiteFly schreef op donderdag 21 augustus 2014 @ 17:06:
Volgens mij kan dit met Goodsync. Ik heb het vroeger gebruik en voor het daadwerkelijk syncen checkte het programma eerst alle mappen/bestanden op wijzigingen. Dit lijkt me vrij standaard eigenlijk. Of begrijp ik je vraag verkeerd?

Ik geloof dat de TS ook van het remote checken af wil.

[HeepH]

NiteFly schreef op donderdag 21 augustus 2014 @ 17:06:
Volgens mij kan dit met Goodsync. Ik heb het vroeger gebruik en voor het daadwerkelijk syncen checkte het programma eerst alle mappen/bestanden op wijzigingen. Dit lijkt me vrij standaard eigenlijk. Of begrijp ik je vraag verkeerd?

Nee, het zou inderdaad kunnen dat dit vrij standaard is. Liefst zou ik een gratis/bijna gratis oplossing hebben en liefst in robocopy, maar alternatieve zijn welkom

freelh schreef op donderdag 21 augustus 2014 @ 17:08:
[...]

Ik geloof dat de TS ook van het remote checken af wil.

Ik wil op lokatie A een lijst vna de files gisteren vs een lijst van de files van vandaag, Dan kijken welke er verschillen en deze moeten naar B gepushed worden. Ik wil dus niet per file op b checken of deze nog over een komt met A

[ Voor 79% gewijzigd door HeepH op 21-08-2014 17:09 ]

[Verwijderd]

rsync met de --update switch
Dit kan overigens ook met robocopy: http://itbloggertips.com/...iles-sync-both-the-drive/

[ Voor 70% gewijzigd door Verwijderd op 21-08-2014 17:13 ]

[CurlyMo]

Het lijkt me cruciaal om eerst te weten wat het OS is en het gebruikte bestandssysteem.

[HeepH]

Windows server 2008, NTFS.

Rsync met update checked toch nog steeds remote of de files anders zijn dan lokaal? Ik wil "lokaal vandaag (A)" vs "lokaal gisteren"en die changes naar "remote (B )."

[ Voor 6% gewijzigd door HeepH op 22-08-2014 08:25 ]

[CurlyMo]

Is het uitbreiden van je infrastructuur of het wisselen van OS een optie?

[ Voor 24% gewijzigd door CurlyMo op 22-08-2014 10:01 ]

[Brahiewahiewa]

Wat jij wilt kan allemaal wel, maar je vertrouwt er dan op dat het locale time-stamp klopt.
Als er iemand een document saved en er in slaagt om de change-time te wijzigen (dat kan) dan wordt die file dus niet ge-backupped. En als de locale tijd op je file-server om één of andere reden een keer afwijkt, loopt je hele backup in de soep.

Kortom: je zult een afweging moeten maken tussen de betrouwbaarheid van je backup en de kosten van een eventuele aanpassing van je infra-structuur

[jeroen3]

SyncbackSE heeft "Fast Backup" waar het een (riskante) aanname maakt dat de bestanden op je backup locatie niet zijn gewijzigd.
Het zal dus met behulp van een een lokale lijst van de vorige keer vergelijken wat er moet worden opgestuurd naar de backup lokatie.

[RemcoDelft]

Heephstan schreef op vrijdag 22 augustus 2014 @ 08:25:
Rsync met update checked toch nog steeds remote of de files anders zijn dan lokaal? Ik wil "lokaal vandaag (A)" vs "lokaal gisteren"en die changes naar "remote (B )."

Daarvoor bestaat toch de archive-attribute in MS-omgeving?

Persoonlijk ben ik zeer tevreden over rsync, ik neem aan dat rsync zelf zo intelligent is om niet file voor file verbinding te leggen, en zo vrij snel alles kan controleren.

[Gomez12]

Waarom zou je het niet zelf maken? In principe zal hier geen standaard oplossing voor zijn omdat als het eenmaal fout gaat het altijd fout gaat ( je vergelijkt namelijk maar de bestanden van 1 kant)

Maar in principe kan je wel iets in elkaar scripten wat op lokatie A een bestand maakt bestaande uit : Lokaltie bestand / grootte bestand / md5 vh bestand / timestamp van het bestand.
Dan tijdens het opbouwen van dat bestand telkens kijken wat er in de vorige versie van dat bestand staat, alles wat er niet letterlijk in voorkomt kan je dan doorgeven als filelist aan robocopy om te gaan synchen.

Enige is dan dus wel dat als robocopy eruit vliegt dat je script denkt dat het goed gegaan is en dat je dus bestanden zal missen.

[akimosan]

Al eens gekeken naar DFS-R en replication groups?
Deze werkt op block niveau. Enkel de gewijzigde bits worden gesynched. Dan heb je het soms maar over een paar mb die daadwerkelijk gesynched worden.
Rapportjes kun je snel en makkelijk maken met dfsradmin (ook te schedulen en plaatsen op een webserver)

Let op dat sync van data geen backup is! De data wijzigt immers op beide plekken!

Shadowcopies aan op je disk, kun je snel data terugzetten.
Extra backup (echte backup) naar tape of offsite disk omgeving/cloud backup.

[Rannasha]

Brahiewahiewa schreef op zaterdag 23 augustus 2014 @ 15:33:
Wat jij wilt kan allemaal wel, maar je vertrouwt er dan op dat het locale time-stamp klopt.
Als er iemand een document saved en er in slaagt om de change-time te wijzigen (dat kan) dan wordt die file dus niet ge-backupped. En als de locale tijd op je file-server om één of andere reden een keer afwijkt, loopt je hele backup in de soep.

Daarom is een timestamp ook een slechte methode om te checken of een bestand gewijzigd is. Serieuze backup/sync software zal eerder naar hashes van bestanden kijken.

[Killah_Priest]

akimosan schreef op zondag 24 augustus 2014 @ 01:30:
Al eens gekeken naar DFS-R en replication groups?
Deze werkt op block niveau. Enkel de gewijzigde bits worden gesynched. Dan heb je het soms maar over een paar mb die daadwerkelijk gesynched worden.
Rapportjes kun je snel en makkelijk maken met dfsradmin (ook te schedulen en plaatsen op een webserver)

Let op dat sync van data geen backup is! De data wijzigt immers op beide plekken!

Shadowcopies aan op je disk, kun je snel data terugzetten.
Extra backup (echte backup) naar tape of offsite disk omgeving/cloud backup.

Dit dus.
Bij Windows server moet je geen 3rd party tools hiervoor willen gebruiken (tenzij het natuurlijk enterprise tools zijn) maar gewoon met DFSR werken.
Vanaf 2008R2 is dit ook vrij makkelijk op te zetten met een 1-way sync.

Overigens zou ik dit nooit als backup inzetten, DFSR gebruik ik zelf alleen voor HA (en als ik een nieuwe fileserver uitrol dan sync ik deze via DFSR met de oude voordat deze in productie gaat)

[P_Tingen]

RemcoDelft schreef op zaterdag 23 augustus 2014 @ 15:39:
[...]
Daarvoor bestaat toch de archive-attribute in MS-omgeving?

Precies daarom zit dat attribuut er al zo'n 30 jaar in. Als je een batchfile hebt die alle files waarvan het archive attribuut is gezet kopieert en na het kopieren weer terugzest dan heb je precies wat je wil. Op het moment dat er iets met een file gebeurt, zet DOS / Windows het archive vlaggetje namelijk weer. Hier zijn wel standaard dos batch files voor te vinden.

ARCHIVING FILES
Use Xcopy's /m switch to back up only files that have been changed since the last time they were Xcopied. This works only on files that have been Xcopied at least once before and will not work on un-Xcopied files.

When Xcopy copies a file, it resets the original file's archive bit from 1 to 0. For more on archive bits, see DOS Attrib. Whenever you update a file, the archive bit is set to 1. When you use the /m switch, Xcopy copies only files with the archive bit set to 1.

The following example backs up all files onto the D disk:
xcopy *.* d: /m


ARCHIVE ONE HARD DISK TO ANOTHER
The following example copies everything from the C: drive to the D: drive that has changed since the last time the files on C: were Xcopied. This includes the root and all subfolders. The /s switch is used here in order to include all subfolders.
xcopy c:\*.* d:\ /s /m

bron

Wat je dan alleen niet hebt is wanneer files op lokatie A worden verwijderd. Je hebt ze dan nog steeds op locatie B.

[ Voor 48% gewijzigd door P_Tingen op 28-08-2014 19:35 ]

[Killah_Priest]

P_Tingen schreef op donderdag 28 augustus 2014 @ 18:59:
[...]


Precies daarom zit dat attribuut er al zo'n 30 jaar in. Als je een batchfile hebt die alle files waarvan het archive attribuut is gezet kopieert en na het kopieren weer terugzest dan heb je precies wat je wil. Op het moment dat er iets met een file gebeurt, zet DOS / Windows het archive vlaggetje namelijk weer. Hier zijn wel standaard dos batch files voor te vinden.


[...]

bron

Wat je dan alleen niet hebt is wanneer files op lokatie A worden verwijderd. Je hebt ze dan nog steeds op locatie B.

Maar waarom zou je met batchfiles etc gaan werken als Server 2008 gewoon standaard DFS-R aan boord heeft wat hiervoor gemaakt is (ok, voor 2-way sync echter is het dmv het aanpassen van de permissies erg simpel om er een 1-way replication van te maken).
Tevens gebruikt DFSR ook nog eens erg weinig bandbreedte en kun je ook nog eens in je replication schedule aangeven of er op bepaalde momenten met een lagere snelheid gesynced moet worden.

[ido_nl]

Is het een optie om eerst lokaal een backup te maken naar 1 file en daarna incremental backups, en dan alleen deze kleinere incremental backups naar B te sturen? De traagheid zit in het remote controleren of er een wijziging is geweest, die zou je op deze manier kunnen wegnemen.

Een andere optie zou kunnen zijn om gebruik te maken van bijvoorbeeld bittorrent sync, daar kan je 1-way sync instellen en die verzend alleen de wijzigingen van bv een grote file.

Ben wel benieuwd waar je op uitkomt, ben zelf ook opzoek naar een dergelijke oplossing, een off-site backup voor mijn thuis backup.

[P_Tingen]

Killah_Priest schreef op zaterdag 30 augustus 2014 @ 17:14:
[...]
Maar waarom zou je met batchfiles etc gaan werken als Server 2008 gewoon standaard DFS-R aan boord heeft wat hiervoor gemaakt is (ok, voor 2-way sync echter is het dmv het aanpassen van de permissies erg simpel om er een 1-way replication van te maken).
Tevens gebruikt DFSR ook nog eens erg weinig bandbreedte en kun je ook nog eens in je replication schedule aangeven of er op bepaalde momenten met een lagere snelheid gesynced moet worden.

Ten eerste omdat ik niks weet van Server 2008 en ten tweede omdat TS vroeg:

Is het mogelijk om lokaal te bekijken welke files gewijzigd zijn vergeleken met gisterenavond en dan alleen deze naar lokatie B te synchen? Zodat niet voor elke file de (30-60ms) delay van het remote checken of deze file gewijzigd is sinds gisterenavond.

Hoe gedraagt DFS-R zich in zo'n situatie?

[Killah_Priest]

DFS-R heeft reporting mogelijkheden : de health test (waarbij je voor een replication groep oa kan zien hoeveel data er is verplaatst, hoeveel bandbreedte dit gekost heeft en of er nog bestanden in backlog staan).
Ook heb je de propagation test waarbij er dmv een testbestand gekeken kan worden hoe snel er gesynced werd (op mijn werk is deze op kantoor zelf normaal minder als 1 seconde, naar onze colo is het binnen 2 seconden binnen).

Ook worden alleen wijzigingen gesynchroniseerd (dus niet eens de complete bestanden als er maar een deel van een de bestanden gewijzigd is).

Vanaf server 2008R2 is dfsr btw de standaard methode om de Active Directory data te replicaten out of the box.

[ Voor 11% gewijzigd door Killah_Priest op 02-09-2014 18:59 ]

[Orion84]

Killah_Priest schreef op dinsdag 02 september 2014 @ 18:57:
Ook worden alleen wijzigingen gesynchroniseerd (dus niet eens de complete bestanden als er maar een deel van een de bestanden gewijzigd is).

Dan blijft de vraag: vindt er communicatie tussen lokaal en remote plaats om bestanden/bestandseigenschappen te vergelijken. Of wordt er puur lokaal een beslissing genomen wat er naar remote gestuurd moet worden? Want dat laatste is wat TS zoekt.

@TopicStarter: weet je heel zeker dat de overhead van het vinden van de wijzigingen daadwerkelijk de veroorzaker van je probleem is en het niet gewoon domweg een bandbreedte probleem is?

[ Voor 15% gewijzigd door Orion84 op 02-09-2014 19:09 ]

[Killah_Priest]

Orion84 schreef op dinsdag 02 september 2014 @ 19:08:
[...]

Dan blijft de vraag: vindt er communicatie tussen lokaal en remote plaats om bestanden/bestandseigenschappen te vergelijken. Of wordt er puur lokaal een beslissing genomen wat er naar remote gestuurd moet worden? Want dat laatste is wat TS zoekt.

Alle replication partners in een replication group hebben contact met elkaar : dfs is bedoeld om data beschikbaar te maken en dfs-r is om de boel synchroon te houden over meerdere fileservers (je kan beide echter los van elkaar gebruiken), je kan echter een replication partner in de groep readonly maken.

(Dfs werkt met een namespace waarin je shared folders aanmaakt welke je via de namespace kunt bereiken ipv met de servernaam, bijvoorbeeld \\domein\shares\hrm ipv \\server\shares\hrm. Je kunt echter meerdere servers aan dezelfde share toewijzen waardoor de gebruikers gewoon door kunnen werken als er een fileserver uitligt.
Het synchroon houden van de data is echter wel essentieel in dat geval en daar is dfs-r dus voor.
Uiteraard is dit ook bedoeld voor branch offices.)

[Gomez12]

Killah_Priest schreef op dinsdag 02 september 2014 @ 21:11:
[...]
Alle replication partners in een replication group hebben contact met elkaar : dfs is bedoeld om data beschikbaar te maken en dfs-r is om de boel synchroon te houden over meerdere fileservers (je kan beide echter los van elkaar gebruiken), je kan echter een replication partner in de groep readonly maken.

Je leest de vraag verkeerd ben ik bang, de data op zich is niet direct het probleem. Het is meer de hoeveelheid files en hoe die in sync gehouden moeten worden.

Zoals je zelf al zegt, een test-bestandje richting jullie colo kost 2 seconden, laten we zeggen dat dat 10 msec kost om te kijken of het er al staat of niet.
Dan heb je het dus met 430.000 files/directory's over 430.000 x 10 msec = 1 uur en 14 minuten dat een sync run duurt als er nul wijzigingen zijn.

TS zijn huidige methode gebruikt echter geen 10 msec om het te vergelijken, maar zoals TS aangeeft kost dat 30 tot 60 msec per bestand, dus een run zonder enige wijziging duurt dan 3 1/2 uur tot 7 uur. Dat is simpelweg rekenen, elke wijziging komt daar nog eens bovenop als extra tijd.

Het nadeel waar TS tegenaan loopt is dat de meeste sync-programma's op dit niveau gewend zijn veel wijzigingen ook tussendoor te moeten verstouwen (zodat het op de achtergrond kan lopen) en daarom echt per file gekeken wordt of het verandert is zodat er niet als er eens een dvd op het netwerk gedumpt wordt er profiles die 3 uur geleden verandert zijn ook meegesynced worden. TS loopt gewoon tegen een keiharde logische limiet aan dat als de check per file gebeurt dat er gewoon 430.000 checks nodig zijn enkel en alleen om te zien of de boel in sync is of niet. En 430.000 individuele checks met netwerklatency duurt gewoon lang. TS is meer op zoek naar iets wat een eenmalige (per run) check doet over alle bestanden zodat er 429.999 netwerklatency's overgeslagen kunnen worden.

-----
@TS : Alternatieve gedachte, alhoewel ik er geen een ken die echt goed is met binary files zou wellicht iets van een distributed versie controle systeem zijn in de trant van Git / Mercurial oid. Die zijn vanwege het distributed karakter erop gemaakt dat ze lokaal de wijzigingen bijhouden en op commando in 1 transactie enkel de wijzigingen gecomprimeerd doorzetten.
Het kost je aan allebei de kanten een smackload aan diskspace vanwege het feit dat versie controle systemen in principe alles eeuwig bijhouden (dus je praat minimaal (compressie even daargelaten) over een verdubbeling van je diskspace en als iemand eens besluit een dvd'tje op het netwerk te copieren voor een dag dan blijft deze in principe tot in den eeuwigheid diskspace innemen in je versie controle systeem.
Maar wellicht dat je hiervoor el cheapo diskspace (as in no backup) kan inzetten aan beide kanten omdat het "zo" weer opnieuw op te bouwen is en je toch al een losse backup routine moet hebben.

[akimosan]

Bij DFS-R hoeven bestanden niet iedere keer tegen elkaar vergeleken te worden. Elke replicatiepartner houdt een "database" bij waarin informatie wordt bijgehouden over te repliceren data. Enkel de informatie in de databases wordt vergeleken alvorens wordt gerepliceerd. Er wordt dus geen "check per file" gedaan over en weer. Hierdoor duurt alleen de initiële synchronisatie lang maar elke opvolgende wijziging gaat echt supersnel. Dus geen 429.999 checks met bijbehorende latency.
Je hebt vrijwel geen latency of netwerkverkeer tussendoor. Het werkt op een vergelijkbare manier als wat je beschrijft met een distributed version control system. Sterker nog: DFS-R staat voor Distributed File System Replication)