[protocol] welk protocol voor directory syncing?

[Verwijderd]

Ik ben bezig met het opzetten van een directory-syncing systeem, waarbij een client onder windows naar een 'backup' folder op een *n*xsysteem moet syncen. Met hoge performance, en eventueel secure (tunneled). Ik ben een dag bezig geweest met het uitzoeken van verschillende systemen, maar blijf een beetje te veel bij de mij bekende mogelijkheden hangen. En ik ga er eigenlijk vanuit dat ik iets over het hoofd zie.

Protocollen die voorbij zijn gekomen zijn: (S)FTP, SCP, RSYNC, NDS, DFS, RCP (klopt dit?). En zou eigenlijk graag advies willen wat ik het best voor het bovenstaande doel kan gebruiken.

Het belangrijkste is zo weinig mogelijk overhead, en een zo gunstig mogelijke performance (1000+ connecties op server moet mogelijk zijn!).

Kan het uberhaupt wat ik wil? waar moet ik voor kiezen? en waarom?

alvast bedankt!

[F_J_K]

In PNS kunnen ze je beter helpen denk ik zo

[Koffie]

Heb je al eens gekeken wat voor specifieke programmas hiervoor op de martk zijn ?
BTW: Wat is je budget ?

[Verwijderd]

Koffie schreef op 23 April 2003 @ 21:40:
Heb je al eens gekeken wat voor specifieke programmas hiervoor op de martk zijn ?
BTW: Wat is je budget ?

ja, programma's heb ik al uitgebreid naar gekeken. Het is de bedoeling om zelf zo iets te gaan ontwikkelen, in eerste instantie hobbymatig, later evt commercieel. Voor het bepalen van welk protocol denk ik geen budget nodig te hebben. Het gaat momenteel echt puur en alleen om het bepalen van het protocol.

[The Jester]

Zo weinig mogelijk overhead is, naar ik begrijp, een belangrijke factor.
In dat geval kun je alles met encryptie (SSH/SCP/SFTP) buiten beschouwing laten.
Het minste overhead vind je bij TFTP. Erg snel, weinig secure en redelijk beperkt.
RSYNC is heel geschikt, omdat het niet meer verstuurd dan nodig. Voor een full backup, zou je ook dd kunnen nemen. dd if=/dev/sdx of=user@host:whatever. Werkt goed, snel en betrouwbaar, maar alleen geschikt voor Linux-clients. Op zich geen probleem, indien je de client een Knoppix-CD laat booten voor de backup. Knoppix kun je custmizen, zodat je niet telkens opties hoeft op te geven en met een lege /home begint. Door bijvoorbeeld je directory-sync in rc.d te zetten, gaat alles dan 'automagisch' en heb je de beschikking over alle onder Linux beschikbare tools en/of protocollen. Dit heeft natuurlijk geen zin indien er meerdere malen per dag gesync'ed moet worden, maar voor eens per dag (of minder) is dit helemaal geen gekke oplossing!

[Verwijderd]

http://www.linux-mag.com/2000-11/dfs_04.html

deze al gevonden? Coda lijkt me de moeite van uitzoeken waard, of anders gewoon NFS, maar dan heb je geen syncing.

Coda kan afaik offline werken, dus op laptopje kun je gewoon werken zonder netwerk verbinding, als je laptop weer online gaat wordt alles weer netjes gesynct.

Code website: http://www.coda.cs.cmu.edu/index.html

[DiGuru]

Is dit iets? Het werkt niet over veilige verbindingen. Je geeft gewoon 2 lokaties op, en die worden gesynchroniseerd. Let wel op: als je hem opdraagt om de files die in de bron niet bestaan weg te gooien en de brondirectory is leeg, is daarna ook de doeldirectory leeg! Sync dus niet bijvoorbeeld een netwerklokatie naar c:\ met Delete = 1, dan is je harddisk leeg als hij die netwerklokatie niet kan vinden.

Maar verder werkt het heel goed en snel om backups te maken. Draait ook in de achtergrond.

[alt-92]

DiGuru schreef op 26 april 2003 @ 02:50:
Sync dus niet bijvoorbeeld een netwerklokatie naar c:\ met Delete = 1, dan is je harddisk leeg als hij die netwerklokatie niet kan vinden.

Maar verder werkt het heel goed en snel om backups te maken. je schijf te wissen.

Ik zou daar toch een check op zetten.
Tis maar een idee hoor, maar bijna alle bestaande sync-software prompt als je netwerk niet beschikbaar is.

[DiGuru]

BackSlash32 schreef op 26 April 2003 @ 03:23:
[...]

Ik zou daar toch een check op zetten.
Tis maar een idee hoor, maar bijna alle bestaande sync-software prompt als je netwerk niet beschikbaar is.

Ja, dat moet ik inderdaad nog eens een keer doen. Maar het werkt gewoon goed, dus het is eigenlijk nog nooit een probleem geweest. Maar ik zal dat van het weekend in orde maken.

[DiGuru]

Ok, ik heb het aangepast. Hier is de link nog een keer.

Edit: gratis, bloedsnel en bedrijfszeker. Wat wil je nog meer?

[ Voor 26% gewijzigd door DiGuru op 26-04-2003 04:52 ]

[mutsje]

Als je wilt syncen tussen windows systemen kun je ook robocopy gebruiken. Dit is een tool uit de resource kit.

Het kan een sync doen eenmalig de hele directory structuur en kijkt daarna alleen nog naar veranderingen die gedaan zijn op de source directory.

Ik heb deze tool gebruikt om circa 15GB te synchroniseren vanwege vervanging van PDC waar een data directory met home en afdelingsfolders op staat. Dit gebeurde elke dag de eerste keer was ding ff lang aan het pompen maar daarna alleen nog de veranderende files.

[alt-92]

DiGuru schreef op 26 April 2003 @ 04:42:
Edit: gratis, bloedsnel en bedrijfszeker. Wat wil je nog meer?

1 dingetje:

code:

G:\Sync>ls
Sync
Sync.exe
sync help.bat

op cli een batchfile aanroepen waar een spatie in de filename zit is niet handig.
Bovendien ontgaat me het nut van die hele batchfile, aangezien je alleen maar *.exe /? aanroept.

Kan je net zogoed een README van maken, stuk duidelijker.

[Verwijderd]

hmm, een aantal reacties zijn wel bruikbaar...

maar het gaat mij dus NIET om het programma, maar om het protocol!

sync.exe werkt dus al helemaal niet met (netwerk)protocollen, want om hiermee met een remote dir te syncen zou je dus al een bestaande verbinding (via bijv SMB) moeten hebben. en het copieren dat gaat mij wel lukken, ik wil alleen weten welk protocol ik moet gaan gebruiken!

bedankt voor de reacties tot zover iig

[DiGuru]

BackSlash32 schreef op 26 April 2003 @ 12:58:
[...]


1 dingetje:

code:

G:\Sync>ls
Sync
Sync.exe
sync help.bat

op cli een batchfile aanroepen waar een spatie in de filename zit is niet handig.
Bovendien ontgaat me het nut van die hele batchfile, aangezien je alleen maar *.exe /? aanroept.

Kan je net zogoed een README van maken, stuk duidelijker.

Daar had ik inderdaad nog nooit aan gedacht. Ik gaf eerst altijd gewoon de executable, maar veel mensen bleken dan de help niet te kunnen vinden. Maar een readme is inderdaad makkelijker.

[mutsje]

waarom wil je precies het protocol weten? UDP verkeer vereis minder verkeer maar is onbetrouwbaar tcp/ip vereist meer van een netwerk en is betrouwbaarder vanwege de controlebits. Encrypty hierover krijg je alleen meer overhead erover heen.

[Verwijderd]

mutsje schreef op 27 April 2003 @ 11:37:
waarom wil je precies het protocol weten? UDP verkeer vereis minder verkeer maar is onbetrouwbaar tcp/ip vereist meer van een netwerk en is betrouwbaarder vanwege de controlebits. Encrypty hierover krijg je alleen meer overhead erover heen.

ik wil het protocol weten om zelf een applicatie (zowel linux server, als windows client side) te schrijven.

en ik heb het dan over protocollen als FTP, HTTP, TFTP, SCP, SMB, RSYNC etc, niet over tcp/udp/icmp of tcp/ip spul. want over tcp/ip in general gaat het toch wel.

ik dacht eigenlijk dat dit inmiddels wel duidelijk was

[Guru Evi]

HTTP is voor browsers ;-) je kunt het wel enorm zelf aanpassen (PHP enzo) maar is zo'n niet-standaard om files te backuppen.
TFTP is onveilig
SMB is imho traag tov andere protocollen
FTP gaat goed maar is niet geencrypteerd, je kunt er wel heel gemakkelijk heel veel mee (er bestaan zo'n sync-programma's in linux, naam ontglipt me) zoals bestandsattributen, datum & tijd
SFTP is de geencrypteerde versie van FTP maar iets moeilijker als je zelf je app wilt schrijven.
RSYNC heb ik eigenlijk nog maar een keer geprobeerd en ziet er uit goed te zijn maar ik weet niet of je dat op Windows kunt gebruiken.
SCP nog nooit geprobeerd

[elevator]

Verwijderd schreef op 28 april 2003 @ 01:01:
ik wil het protocol weten om zelf een applicatie (zowel linux server, als windows client side) te schrijven.

en ik heb het dan over protocollen als FTP, HTTP, TFTP, SCP, SMB, RSYNC etc, niet over tcp/udp/icmp of tcp/ip spul. want over tcp/ip in general gaat het toch wel.

ik dacht eigenlijk dat dit inmiddels wel duidelijk was

Ik denk dat rsync in jouw geval het beste geschikt is:

• FTP ondersteunt (vziw) geen incrementele updates
• HTTP ook niet en bovendien zou je bij een PUT moeten mime encoden iirc (overhead)
• TFTP kent geen authenticatie iirc
• SCP ken ik niet voldoende
• kan maar is moeilijker over internet (aangezien de meeste firewall maintainers dat liever niet open hebben staan)
• rsync doet alles wat jij wilt volgens mij

[Verwijderd]

kijk hier kan ik wat mee

research gaat maar eens richting rsync denk ik zo...

thank you guys

[Verwijderd]

hmm wat ik heb gelezen over rsync:

This will produce an rsync binary which runs under win95/NT which can _send_
data to a UNIX rsync host but not receive.

http://samba.anu.edu.au/ftp/rsync/win95.txt