Dotaz: Opakovany RSYNC pri zmene nazvu souboru

[JojoANe]

Resim nasledujici - mam hlavni adresar v kterém jsou podadresare do 3-4 urovne. V techto adresarich jsou mkv, ktere budou po rsyncu na sekundarnim storage konvertovany na mp4. Vzhledem k tomu, ze rsync se bude z hlavniho na sekundarni storage v pravidelne opakovat, protoze nove soubory neustale pribyvaji, hledam jak provest opakovany rsync tak, aby se nahraly pouze nove mkv a ne originalne rsyncovane, aktualne uz na sekundarnim storage prejmenovane na mp4. Jak na to?

Odpovědi

[X]

Nejdrive oba adresare porovnej a to porovnavani podle nazvu a kopirovani si proste doskriptujes. Rsync fakt nepozna, ze si cilovy soubor zkonvertoval do jineho formatu a jinou velikosti.

[Jendа]

Napadá mě třeba podle času, a nebo ručním porovnáním (ssh sekundární "ls -lr" > tmp1, ls -lr > tmp2, ... | sed -re "s/mp4/mkv/" | ..., comm -3 tmp1 tmp2).

[JojoANe]

Uf, doufal jsem, že existuje "neco" co tohle resi, ale vypada to na nějakou silenou rouru. V kazdym pripade diky za tip, zkusim to nejak doprasit, pokud se neozve nekdo s nejakym zazracnym resenim.

[Ruža Becelin]

Řešení by mohlo být několik.

1. Hlavní adresář na primárním storage verzovat např. časovou značkou a pak rsync source_$časováznačka na sekundární storage. Předpokládám, že tvůj rsync nepoužívá --delete-xxx, takže to nebude mazat soubory, co jsou chybí na primáru.

2. Alternativa může být pouštět rsync tak, jak doposud s tím, že po konverzi mkv->mp4 se udělá truncate na mkv soubory a rsync dostane parametr --ignore-existing, který zabrání přepisu existujících souborů.

[X]

K variante 2] by mozna stacil symlink, nebo proste prazdny "placeholder" soubor.

[Andrej]

Předpokládám, že na cílovém disku se mají původní .mkv po konverzi na .mp4 smazat, jinak by celá otázka měla velmi triviální řešení (nemazat).

Inu, tady mě napadá ošklivé, prasácké, ale účinné řešení založené na rsync: Místo mazání původní .mkv ponechat na místě, ale zmenšit je (například pomocí truncate) na nulu a obnovit jejich původní datum změny. Pak si rsync bude myslet, že už tam jsou, ale zároveň nebudou zabírat místo. Při konverzi do .mp4 je pak potřeba odfiltrovat ty .mkv, které mají nulovou velikost. Problém tohoto postupu: bitrot — Tedy nelze použít rsync -c (ze zjevných důvodů) a není tam vůbec žádná „end to end“ ochrana proti silent data corruption. Ale pokud jde jen a pouze o to „přeskočit“ už zpracované soubory, tohle by mohlo fungovat.

[Andrej]

Gah. No to se mi povedlo, tahle↑ „rada“. Tohle je problém:

rsync finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time.

Dobře, tak úplně jednoduše a „implicitně“ to nepůjde. Existuje sice --size-only, ale není tam žádný ekvivalent --time-only, který by pomohl v tomto případě.

Takže podle mě by mohlo být řešením --ignore-existing (skip updating files that exist on receiver). To vypadá, že by to mohlo (správně) přeskočit přenos již zpracovaných .mkv souborů — pokud na cíli budou ponechané ty placeholdery zmenšené na nulu (kvůli úspoře místa).

[exclude-from]

Jak vypadá výstup rsync už vlastně nevím. Nešel by zapisovat(přidávat) do souboru a ten pak použít jako exclude? Nebo log po dokončení "očistit" a připojit do exclude. Jak moc může ovlivnit velké množství souborů v exclude čas synchronizace těžko říct.

[JojoANe]

Hm, toz ten rsync vypada na clusterfuck in waiting. Kdyz odlozime rsync, co pouzit jineho vhodnejsiho pro tento scenar?

[X]

Dal by se pouzit git. Na sekundani server jako master budes prenaset zmeny nehlede na jeho stav.

[JojoANe]

Uf, s gitem moc neumím, ale s takovouhle za chvilku budem rozjizdet vypocetni cluster s sql DB :)

[X]

Je to jeden prikaz. Nebal bych se toho..

[Vantomas]

Šlo by na to použít parametr --exclude-from, kterému se subshellem strčí výsledek z find a u kterého se přes sed změní .mp4 na .mkv.

Pozor, funguje to pouze pokud se bude spouštět bashem a když se to bude spouštět z cílového stroje, kde se find dostane k těm mp4 souborům.

Pro referenci třeba: Copy recursively, completely ignoring matching directories in Bash [closed]

[Ivan]

Obycenjny rsync tohle nezvladne. Kdysi jsem pouzival zalohovaci SW id fy. IBM - TSM. Ten mel demona ktery poslouchal pres rozhrani i-notify. Kernel mu sdeloval ktere soubory se zmenily/pribyly/prejmenovaly a pak inkrementalne zalohoval jen to co se zmenilo.

Myslim, ze ti kdo se dodnes snazi pouzivat rsync pro zalohovani uz prisli s necim podobnym. Ze existuje verzi rsync, ktera umi pouzit zurnal zmen od i-notify. IMHO zadna jina cesta, nez i-notify neni. Musis si nechat od kernelu rict co pribylo, co se prejmenovalo,...

Pokud si budes hrat s i-notify jeste vic, tak mozna dospajes k tomu, ze to ma modul pro python, ze a bude nejjednossi rsync uplne opustit a napsat si vlastni synchronizacni SW v pythonu.

[JojoANe]

Mno takhle jsem si to jednodussi a efektivnejsi reseni nepredstavoval...to vypada na cim dal vetsi clusterFuck.

[Petr Tomášek]

unison

[GPTv.4]

#!/bin/bash

# Directory to watch for new MKV files
WATCH_DIR="/path/to/watch"

# Loop to keep checking for new MKV files
inotifywait -m -e create --format "%f" "$WATCH_DIR" | while read NEW_FILE
do
    # Check if the new file is an MKV file
    if [[ "$NEW_FILE" =~ \.mkv$ ]]; then
        # Full path to the new MKV file
        MKV_FILE="$WATCH_DIR/$NEW_FILE"
        # Full path to the target MP4 file
        MP4_FILE="${MKV_FILE%.mkv}.mp4"
        
        # Convert the MKV file to MP4 using ffmpeg
        ffmpeg -i "$MKV_FILE" -codec:v libx264 -codec:a aac -strict experimental "$MP4_FILE"
        
        # Check if conversion was successful
        if [[ $? -eq 0 ]]; then
            # Remove the original MKV file after successful conversion
            rm "$MKV_FILE"
            echo "Converted and removed $MKV_FILE"
        else
            echo "Error converting $MKV_FILE"
        fi
    fi
done