Detekter adgang til lokalnetværk

Kan du ikke bare tjekke om en bestemt fil eller mappe er til rådighed? Jeg har et tilsvarende rsync script som laver backup mod en online backupserver. Denne server er i princippet altid til rådighed, men jeg laver backup i en encfs beskyttet mappe på serveren, og backuppen skal kun køre hvis den er mountet.

Det tjekker jeg simpelthen ved at kigge efter en bestemt mappestruktur som kun findes hvis den er mountet.

#1: Kan du ikke bare tjekke om en bestemt fil eller mappe er til rådighed?

Tjo. Jeg havde nok håbet på at det kunne lade sig gøre på netværksniveau og ikke applikationsniveau, men det er givetvis et ønske der er af mere principiel end pragmatisk natur. Der kører en rsync daemon på remote-serveren, så umiddelbart kan jeg bare se, hvilke shares den deler - det vil nok være en OK løsning evt. kombineret med en indledende 'ping'.


#1: Jeg har et tilsvarende rsync script som laver backup mod en online backupserver.

Af nysgerrighed: sync'er du med flere klienter? Jeg har både en arbejdscomputer og en hjemmecomputer, hvor jeg gerne vil sync'e nogle udvalgte mapper mellem dem - så rsync-serveren skal både være backup og "sync-mellemled". Men rsync har sine begrænsninger på det punkt, fordi det ikke er givet på forhånd, hvem der er "master". Man kan lave en masse tricks, men i mit hoved er ingen af dem helt bullet-proof medmindre man går til ekstremer ('sync' begge veje uden '--delete'), men så bliver det jo et stjernekrigsprojekt at undgå dubletter, hver gang man flytter en fil.

#2: Af nysgerrighed: sync'er du med flere klienter?

Ja, men som regel mest med den stationære. De deler dog ikke destinationen, så i mit tilfælde er det jo helt ligetil.

Måske kunne du kigge på Unison hvis du vil synce to computere.

Her er i øvrigt mit simple script. Det bruger datoen som navn på destination og gemmer kun forskellen fra den forrige backup ved hjælp af --link-dest parametren.

#!/bin/bash
isMounted=0
ssh marlar@example.com test -d /home/marlar/mountencrypted/D && isMounted=1
if [ $isMounted == 1 ]; then
olddir=$(ssh marlar@example.com ls mountencrypted/D | egrep '[0-9]{6}' | sort | tail -n 1)
echo $olddir
today=$(date +%y%m%d)
echo $today
rsync -azhP -e ssh --delete-excluded --exclude='r9tn1xep.default/Cache/' --link-dest=/home/marlar/mountencrypted/D/$olddir/ /media/truecrypt1/ marlar@example.com:/home/marlar/mountencrypted/D/$today/
else
echo "Remote dir is not mounted. Aborting."
fi


#3: Måske kunne du kigge på Unison hvis du vil synce to computere.

Jeg vil forsøge at læse lidt om det. Men jeg kan forestille mig, at jeg har lige rigeligt specielle ønsker til at et "standard"-værktøj kan klare ærterne.

Jeg mangler egentlig bare at rsync havde en "delete, hvis fil på destinationsserver er ældre end X"-funktionalitet, hvor X så er sat til tidspunktet for seneste synkronisering. På den måde kan jeg se forskel på om afvigelser skyldes filer, der er nyoprettede på server A, eller filer, der er slettet på B, når man laver en dobbeltvejs-rsync. Men det lader desværre ikke til at rsync har sådan en feature...

#3: Det bruger datoen som navn på destination og gemmer kun forskellen fra den forrige backup ved hjælp af --link-dest parametren.

Ja, det er en ganske smart feature. Jeg kan nu bedre lide --backup-dir, hvor den gemmer de ændrede filer i en folder med passende navn (oplagt: tidsstempel). Så har man en nem oversigt over hvilke filer, man har ændret hvornår. Hardlinks kan godt forvirre, synes jeg.

#5: Hardlinks kan godt forvirre, synes jeg.

Det kommer nok an på hvordan man bruger backuppen. Med hardlinks får man en slags tidsmaskine hvor man kan se hvordan data så ud på et bestemt tidspunkt. Altså et snapshot (hvilket jo netop udnyttes i rsnapshot). Så hvis jeg pludselig får brug for en tidligere version af et projekt kan jeg hente alle filerne fra samme backupfolder og vide med sikkerhed at de hører sammen uanset hvilken mappe de i virkeligheden ligger i. Rsync har lænket dem rigtigt sammen for mig. Hvis der kun var deltamapper, skulle jeg måske hente de sammenhørende filer i forskellige mapper.

#5: På den måde kan jeg se forskel på om afvigelser skyldes filer, der er nyoprettede på server A, eller filer, der er slettet på B, når man laver en dobbeltvejs-rsync

Kunne du ikke opnå netop dette med hardlinks? Så kunne midtvejsbackuppen være målet for --link-dest, og de to backups vil blot hardlinke til midtvejsbackuppen der hvor filerne er uændrede. Du får altså to udadtil fulde backups der deler en fælles kerne og dermed fylder så lidt som muligt.

#6: Det kommer nok an på hvordan man bruger backuppen.


Klart. I mit tilfælde har jeg oftest brug for at tracke udviklingen på en enkelt fil/folder - i det tilfælde synes jeg den nævnte struktur er bedre end et komplet snapshot baseret på hardlinks. Du kan sikkert opnå det samme med passende find-kommandoer, men det må være tidskrævende når antallet af snapshots vokser.


#6: Kunne du ikke opnå netop dette med hardlinks?

Jeg kan ikke se hvordan det skulle hjælpe mig. Måske misforstår jeg, eller måske misforstår du problematikken. Here goes:

Jeg har en fælles folder (inkl. subfoldere og filer) på mellemstationen X, som skal synkroniseres med folderne Y og Z på hver deres klientmaskine.

Hvis udgangspunktet er tre perfekt synkroniserede foldere, er problematikken fx.:
1) Jeg arbejder på klient Y og sletter en fil.
2) efter synkronisering med X slettes samme fil med "--delete", hvis jeg sørger for at starte tovejs-synkroniseringen med en Y->X rsync
3) efterfølgende sætter jeg mig ved Z og synkroniserer med X, hvor jeg skal starte med X->Z med "--delete", så filen bliver slettet på Z

Dvs. for trinene 2) og 3) skal der tages stilling til, hvem der er "master", og hvis man rammer forkert er det ret brutalt: enten sletter man potentielt en nyoprettet fil, eller også får man ikke slettet en ellers tilsigtet slettet fil og den roder til og giver ekstraarbejde/forvirring.

I en perfekt verden er det ret simpelt:
- jeg arbejder aldrig på begge maskiner samtidigt.
- ved login på en maskine skal den synkronisere med X som master.
- ved logout på en maskine skal den synkronisere med X med sig selv som master.

I en mere reel (u-perfekt) verden er problemet, at det ikke er givet, at man altid har adgang til X (manglende Internet, server utilgængelig, whatever). Og glipper et af punkterne ovenfor er (worst-case) effekten, som beskrevet, ret nådesløs. Det vil være markant nemmere, hvis der var en --delete-only-if-older-than=TIMESTAMP" parameter, så jeg kunne administrere seneste synkroniseringstidspunkt for en given klient og kun delete mismatchede filer, hvis de var ældre end det tidspunkt (for det vil jo være ensbetydende med, at de har været slettet (formentlig tilsigtet), og IKKE nyoprettede).

Nu ender det nok med at jeg selv må lade X være master hver gang, og så tage hånd om evt. slettede filer på den lokale maskine. Disse filer skulle jo gerne ende i backup-dir, hvor jeg så kan se deres modifikationstidspunkt og kopiere dem tilbage i træet, hvis de er tilpas nye. Men det er lidt omstændigt...

Giver det mening?

#7: Giver det mening?

Ja det gør det. Jeg har muligvis nogle ideer men får ikke tid før på mandag.