Fins ara tot el que has executat era inofensiu: mirar, llistar, consultar. Aquesta lliçó creua la línia. A partir d'aquí les ordres escriuen al disc, i algunes esborren sense preguntar i sense possibilitat de desfer.

No és un advertiment retòric. A Linux no hi ha paperera de reciclatge per defecte: rm desenllaça el fitxer i l'espai queda disponible per reutilitzar-se. Recuperar alguna cosa esborrada en un sistema de fitxers muntat i en ús és, a la pràctica, impossible. Per això aquesta lliçó dedica un apartat sencer a estratègies defensives, i per això la instantània de la VM és avui més important que mai.

A canvi, aquestes són les eines amb què es treballa de debò: crear estructures de directoris, copiar preservant permisos, moure i reanomenar, sincronitzar arbres complets i empaquetar programari per distribuir-lo. En acabar podràs preparar un paquet de /opt/tramontana/app a punt per enviar-lo a en Luis, amb la certesa que arribarà idèntic a com va sortir.

1. touch: crear i tocar marques de temps
2. mkdir i rmdir: estructura de directoris
3. cp: copiar, i el parany de la barra final
4. mv: moure i reanomenar
5. rm: la conversa seriosa
6. Reanomenament per lots amb rename
7. rsync: la manera correcta de copiar directoris
8. tar: empaquetar
9. Compressió: gzip, bzip2, xz i zip
10. Pràctica: preparar el paquet per a en Luis

touch fa dues coses diferents segons si el fitxer existeix o no:

• Si no existeix, el crea buit.
• Si existeix, actualitza les seves marques de temps sense tocar el contingut.

Zero bytes: existeix però és buit. Accepta diversos arguments:

La segona funció, actualitzar marques de temps, és la que dona nom a l'ordre i la que sorprèn qui només la coneix com a «crear fitxer buit». Reprenent les tres marques de la lliçó anterior:

Fixa't en el que no ha canviat:

L'mtime diu gener, però el ctime diu avui. És exactament el que anticipava l'exercici de la lliçó 02-03: pots falsificar l'mtime, però el ctime delata que l'inode s'ha tocat ara mateix.

Usos legítims de touch en administració:

• Crear un fitxer de bloqueig o un marcador (/var/run/tramontana.lock).
• Forçar que una eina que compara dates consideri un fitxer com a modificat.
• Fixar la data d'un fitxer restaurat d'una còpia perquè coincideixi amb l'original.
• Crear un fitxer buit abans de donar-li permisos restrictius i després escriure-hi, perquè no existeixi mai amb permisos oberts.

-c és l'opció defensiva: actualitza si existeix, i si no existeix no facis res. Evita crear fitxers buits per una errada al nom.

Sense -p, mkdir no crea rutes imbricades:

-p té una segona propietat, tan important com la primera: no falla si el directori ja existeix.

Això fa que mkdir -p sigui idempotent: executar-lo deu vegades deixa el sistema en el mateix estat que executar-lo una. És la propietat que es busca en scripts, on un mkdir que falla perquè el directori ja existia avortaria l'execució sense motiu. Ho reprendràs al Mòdul 4 i amb Ansible al Mòdul 7.

-m crea amb permisos concrets en una sola operació:

És millor que crear i després fer chmod, perquè entre les dues operacions hi hauria una finestra —breu, però real— en què el directori té permisos més oberts del que caldria. En un sistema multiusuari, aquesta finestra és un problema de seguretat. El significat del 700 és la lliçó 02-07.

Amb expansió de claus pots crear estructures completes d'un sol cop:

Aquestes claus són expansió de claus, una funció del shell que s'explica a la lliçó 03-02. Fes-la servir ja; n'entendràs la mecànica més endavant.

rmdir esborra un directori, però només si és buit:

Aquesta limitació no és un defecte: és una xarxa de seguretat. rmdir no pot esborrar res per accident perquè només actua sobre directoris buits. Quan vulguis eliminar un directori amb contingut hauràs de fer servir rm -r, i en aquell moment estàs assumint conscientment el risc.

rmdir -p elimina la branca sencera mentre vagi quedant buida:

Ha esborrat agost, després 2026 perquè va quedar buit, i després informes.

Les opcions que importen:

cp sobreescriu sense avisar. És el comportament per defecte i ha destruït molta feina:

reserves.csv ja no conté reserves: conté cases. No hi va haver ni un avís.

Compara amb la versió defensiva:

Diferència entre -p i -a:

La còpia normal té la data d'avui; la còpia amb -p conserva la data original. El propietari va canviar en totes dues perquè operador no pot crear fitxers que pertanyin a root (cal sudo; els detalls a la lliçó 02-07).

Regla pràctica: per copiar un arbre de directoris tal qual, cp -a. Per a tota la resta, cp -r n'hi ha prou.

Aquest és el comportament que més confusió genera de tota l'ordre. La clau: cp es comporta de manera diferent segons si el destí existeix i és un directori o no.

Al cas 2, el fitxer es diu backup/cases.txt. Fins aquí és intuïtiu. La sorpresa apareix amb directoris:

La mateixa ordre produeix dos resultats diferents segons si backup existia. Aquesta és la fallada clàssica: executes un script de còpia dues vegades i la segona et crea backup/dades/ imbricat a dins.

I ara la barra final a l'origen, que a cp no canvia res però a rsync ho canvia tot:

Amb cp, dades i dades/ donen el mateix resultat. A rsync no, com veuràs a l'apartat 7. És una de les incoherències històriques d'Unix amb què cal conviure.

Defensa pràctica: quan copiïs directoris, executa abans ls -d desti per saber si existeix. I en scripts, fes servir sempre destins explícits i comprovats.

mv fa les dues coses amb la mateixa ordre, perquè al fons són la mateixa operació: canviar l'entrada de directori que apunta a un fitxer.

Com cp, mv sobreescriu sense preguntar, i amb una diferència crucial: a cp perds només el destí; a mv perds el destí i l'origen deixa de ser on era.

Aquest detall explica un comportament que desconcerta quan mous fitxers grans.

El mateix inode. No s'ha copiat ni un byte: només s'ha esborrat una entrada de directori i se n'ha creat una altra que apunta al mateix inode. Per això moure un fitxer de 40 GB dins del mateix disc és instantani.

Ara, entre sistemes de fitxers diferents:

Conseqüències pràctiques de la branca dreta:

• Triga: moure 40 GB de / a un disc USB implica llegir i escriure 40 GB.
• Necessita espai lliure al destí durant tota l'operació.
• Si s'interromp a mitges (tall de llum, Ctrl+C), el destí queda amb un fitxer parcial i l'origen pot haver-se esborrat parcialment si eren diversos fitxers. mv no és atòmic entre sistemes de fitxers.
• El ctime canvia i el propietari pot canviar, perquè en realitat s'ha creat un fitxer nou.

Com saber si dues rutes són al mateix sistema de fitxers:

Mateix dispositiu, /dev/sda2: el moviment serà instantani. Si hi apareguessin dispositius diferents, seria copiar i esborrar.

Regla per moure coses grans entre discos: fes servir rsync i esborra després, després de verificar. Així, si alguna cosa falla, l'origen continua intacte.

rm elimina fitxers. En un sistema de fitxers muntat i en ús, ho fa de manera irreversible.

-I és el punt dolç: t'atura a pensar una vegada, sense la fatiga de -i preguntant quatre-centes vegades (que acaba fent que responguis «sí» automàticament, que és pitjor que no preguntar).

rm -rf és la combinació que esborra un arbre complet sense ni una pregunta i sense queixar-se de res. És necessària en scripts i és la responsable de la majoria dels desastres de dades autoinfligits.

El cas paradigmàtic és el de la variable buida. Un script conté:

Si per qualsevol motiu DESTI i SUBDIR són buides —perquè un cd previ ha fallat, perquè un fitxer de configuració no s'ha llegit, perquè hi ha hagut una errada al nom de la variable— la línia que s'executa és:

Aquest error ha passat en empreses reals i ha arribat a esborrar sistemes sencers en producció. El cas més conegut públicament és el d'un instal·lador d'un joc comercial que, per aquesta mateixa causa, esborrava el directori personal complet dels seus usuaris.

Les versions modernes de rm inclouen --preserve-root, que rebutja rm -rf /:

Però aquesta protecció només cobreix l'arrel exacta. rm -rf /home o rm -rf /opt/tramontana s'executen sense objecció. I amb la barra: rm -rf "$DESTI"/ quan DESTI és buida dona rm -rf /, protegit; però rm -rf "$DESTI"/* amb DESTI buida dona rm -rf /*, que no està protegit i esborra tot el contingut de l'arrel.

1. Mirar abans d'esborrar. L'hàbit que ja coneixes, ara obligatori:

I amb patrons, encara més: executa l'ls amb el mateix patró, comprova la llista i només llavors canvia ls per rm amb la fletxa amunt.

2. Fer servir -I per costum en treball interactiu.

3. Paperera amb trash-cli. Existeix un equivalent a la paperera d'escriptori per al terminal:

És útil al teu portàtil. En un servidor té un inconvenient seriós: els fitxers continuen ocupant espai a ~/.local/share/Trash, i si esborraves per alliberar disc, no has alliberat res. Fes-ho servir amb criteri.

4. Àlies defensius. Es pot fer que rm sigui rm -I per defecte mitjançant un àlies. Els àlies s'estudien a la lliçó 03-01, i allà discutirem per què aquesta pràctica concreta és discutible: t'acostumes a una protecció que no existeix als altres servidors, i el dia que treballis en una màquina aliena tindràs una falsa sensació de seguretat.

5. Cometes i --. Posa sempre les variables entre cometes i fes servir -- abans de noms que vinguin de fora.

6. El que de debò et salva: còpies de seguretat. Cap de les mesures anteriors protegeix contra un esborrat deliberat i ben escrit. L'única cosa que protegeix és tenir còpies en un altre lloc, i això és la lliçó 05-08. I al teu laboratori, la instantània de la VM.

Una última nota tècnica: rm no esborra el contingut, només desenllaça el nom. Les dades continuen als blocs fins que se sobreescriuen. Això significa dues coses oposades: que un forense les podria recuperar, i que tu, a la pràctica, no ho podràs fer perquè el sistema continuarà escrivint a sobre mentre ho intentes. Per a esborrat segur real existeix shred, amb les seves pròpies limitacions en discos SSD i sistemes amb journal.

Reanomenar cinquanta fitxers a mà no és opció. rename (la versió Perl, que és la de Debian i Ubuntu) aplica una transformació a molts noms:

-n (o --nono) és obligatori a la primera execució: mostra el que faria sense fer-ho. És l'equivalent al «mirar abans d'actuar» per a reanomenaments massius.

Més exemples:

La sintaxi s/patró/reemplaçament/ són expressions regulars de Perl, tema de la lliçó 03-02. De moment en tens prou amb el patró literal i -n per verificar.

Compte amb dues coses: en algunes distribucions (Fedora, RHEL) rename és un programa completament diferent amb una altra sintaxi, i rename sobreescriu sense avisar si el nom de destí ja existeix. Afegeix -v per veure què fa realment.

rsync està dissenyat per sincronitzar arbres de directoris. Enfront de cp -a té tres avantatges que el fan l'eina per defecte així que la còpia és gran o important:

Segona execució, sense canvis:

162 bytes en comptes de 50 MB. Ha comparat i no ha trobat res per copiar. Aquest és l'estalvi que justifica fer servir rsync per a qualsevol cosa que es repeteixi.

Opcions essencials:

Aquí sí, i és l'error número u amb aquesta eina:

Mnemotècnia: la barra final significa «el contingut de». Sense barra, «la carpeta mateixa».

--delete combinat amb això és perillós, perquè esborra al destí tot el que no sigui a l'origen. Si t'equivoques de nivell, buides el destí. Sempre -n primer:

-n t'ha ensenyat que anava a esborrar obsolet.txt. Ara decideixes amb informació.

L'ús de rsync per a còpies de seguretat reals —amb rotació, còpies incrementals enllaçades i destins remots— és la lliçó 05-08. Aquí el fas servir com el cp bo per a directoris.

tar (tape archive) ajunta molts fitxers en un de sol conservant l'estructura, els permisos i les dates. Per si mateix no comprimeix: això ho fa un compressor extern al qual crida.

Els tres modes d'operació són excloents, com vas esbrinar llegint el manual a la lliçó 02-02:

I les opcions que l'acompanyen:

Crear:

Desglossament de l'ordre, que és l'important:

• -c crear, -z comprimir amb gzip, -v mostrar, -f seguit del nom del fitxer resultant.
• -C /opt/tramontana fa que tar se situï allà abans d'empaquetar. Sense això, empaquetaria opt/tramontana/app/... amb tota la jerarquia a dins.
• app és el que s'empaqueta, ja relatiu a -C.

Llistar abans d'extreure és obligatori:

Per què és obligatori: per comprovar que el fitxer té un directori arrel únic. Si en comptes d'app/... hi veiessis els fitxers solts a l'arrel del paquet, en extreure'l t'escamparia desenes de fitxers pel teu directori actual. És el que es coneix com a tarbomb, i netejar-ho a mà és tediós.

Extreure:

Extreure sempre amb -C a un directori buit evita el problema del tarbomb del tot.

Les versions modernes de tar detecten la compressió automàticament en extreure, així que -z, -j o -J no són necessàries per descomprimir. Sí que ho són en crear, perquè allà tar no pot endevinar què vols.

Excloure el que no ha de viatjar:

I una nota que val or: la sintaxi històrica de tar admet les opcions sense guionet (tar czf) perquè és anterior a la convenció de guionets de POSIX. Totes dues funcionen. Fes servir la de guionets, que és la que s'entén.

Els compressors d'Unix treballen sobre un sol fitxer i per defecte substitueixen l'original:

dades.csv ja no existeix: s'ha convertit en dades.csv.gz. Per conservar l'original cal demanar-ho amb -k:

Comparativa sobre un fitxer de text de 100 MB, que és on aquestes diferències es noten:

La regla de decisió:

• Comprimeixes moltes vegades i descomprimeixes poques (registres rotats diàriament): gzip. La velocitat importa més que la mida.
• Comprimeixes una vegada i descomprimeixes moltes (una release que es descarregarà mil vegades): xz. El temps de compressió es paga una sola vegada i estalvies amplada de banda a cada descàrrega.
• L'hi passes a algú amb Windows: zip.

zip és l'únic que arxiva i comprimeix alhora, com a Windows:

La seva gran limitació a Linux: no preserva bé els permisos ni la propietat d'Unix. Si empaquetes amb zip i desempaquetes, els bits d'execució es poden perdre i l'script deixa de funcionar. Per això a Linux es fa servir tar, que sí que els conserva, i zip només quan el destinatari fa servir Windows.

Eines per treballar amb fitxers comprimits sense descomprimir-los, molt útils amb registres:

En Luis Ferrer necessita una còpia exacta de la versió 3.2.1 desplegada en producció per reproduir una fallada al seu portàtil. La Marta ha aprovat enviar-l'hi. El paquet no ha d'incloure registres ni fitxers temporals, i ha d'arribar íntegre.

Pas 1: verificar què empaquetaràs.

Pas 2: crear el directori de treball. No s'empaqueta a /tmp tot sol: es fa servir un lloc amb espai i on el fitxer no desaparegui al pròxim reinici.

Pas 3: empaquetar, excloent el que no ha de sortir.

Pas 4: verificar el resultat. No enviïs mai un paquet que no has llistat.

48 MB comprimits a 19 MB, un sol directori arrel app/, permisos preservats (fixa't en el -rwxr-xr-x de l'executable) i cap .log a dins.

Pas 5: generar una suma de comprovació perquè en Luis pugui verificar que el fitxer ha arribat íntegre. És el mateix mecanisme que vas fer servir en verificar la ISO d'Ubuntu a la lliçó 01-04.

En Luis, en rebre'l, executa:

Pas 6: prova d'extracció en local. Comprovar que el paquet s'obre bé abans d'enviar-lo, no després que en Luis digui que no funciona.

diff -rq compara dos arbres recursivament i informa només de les diferències. Sense sortida i amb codi 0: són idèntics. Veuràs diff en detall a la lliçó següent.

Pas 7: netejar.

Procediment complet, reproduïble i verificat. La transferència del fitxer a en Luis es farà amb scp o rsync sobre SSH, que és la lliçó 06-02.

Oblidar -r en copiar o esborrar directoris. cp: -r not specified; omitting directory i rm: cannot remove ...: Is a directory són el mateix avís.

La barra final. A cp gairebé no importa; a rsync decideix si copies la carpeta o el seu contingut. I a cp -r, el resultat depèn de si el destí ja existia.

cp i mv sobreescriuen en silenci. No hi ha confirmació per defecte. -i o -n quan el destí pugui existir.

Copiar configuració amb cp en comptes de cp -p. Perds les dates, que moltes vegades són l'única pista de quan es va canviar alguna cosa.

Empaquetar amb rutes absolutes. tar -czf x.tar.gz /opt/tramontana/app guarda la jerarquia opt/tramontana/app/ a dins. Fes servir -C i rutes relatives.

Extreure sense llistar primer. tar -tzvf abans de tar -xzf, sempre.

zip per a fitxers de Linux. Perd bits d'execució i propietat. tar per a Linux, zip només per a Windows.

Consell: rsync -n i rename -n abans de la versió real. El mode simulació és gratis i t'ensenya exactament el que passarà.

Consell: anomena els paquets amb versió i data. tramontana-app-3.2.1.tar.gz és informatiu; backup.tar.gz no diu res d'aquí a tres mesos.

Consell: acompanya sempre un paquet del seu sha256sum. Costa una ordre i elimina tota una categoria d'incidències.

Consell: abans d'un rm -r, prem Ctrl+A i escriu ls -la al davant. Mires, i després fletxa amunt i ho canvies pel rm. Deu segons que han salvat moltes dades.

Al teu home de srv-tramontana, amb el mínim nombre d'ordres:

1. Crea l'estructura treball/2026/{07,08,09}/informes i treball/2026/{07,08,09}/dades.
2. Crea un fitxer treball/2026/08/informes/resum.txt amb data de modificació de l'1 d'agost de 2026 a les 09:00.
3. Copia ~/dades/reserves.csv a treball/2026/08/dades/ preservant-ne les marques de temps, i verifica-ho.
4. Reanomena tots els .txt de treball/2026/08/informes/ a .md sense equivocar-te (fes servir el mode simulació).

En Luis et proposa aquest procediment per fer una còpia diària de l'aplicació abans de cada desplegament:

Troba almenys cinc problemes i reescriu el procediment correctament.

La Marta necessita endur-se a una reunió les dades de reserves i el llistat de cases. Treballa amb Windows i vol obrir els fitxers amb l'Excel. A més demana que el paquet inclogui un petit informe de què conté.

Prepara l'enviament complet: crea l'informe, empaqueta en el format adequat, verifica el contingut del paquet i genera la suma de comprovació. Justifica l'elecció del format de compressió.

Solució 1

Una sola ordre. L'expansió de claus imbricada genera les sis combinacions i -p crea tots els pares. Sense -p fallaria perquè treball i treball/2026 no existeixen.

touch amb -t crea i fixa la marca en una sola operació. El format és AAAAMMDDhhmm.ss.

Les marques coincideixen al nanosegon. Sense -p, la còpia tindria la data d'ara. Fixa't que el destí acaba en /: com que el directori existeix, la còpia es fa a dins conservant el nom.

El \. escapa el punt perquè signifiqui un punt literal i no «qualsevol caràcter», i el $ ancora el patró al final del nom, de manera que un fitxer anomenat notes.txt.vell no en resultaria afectat. Totes dues coses són expressions regulars (lliçó 03-02).

Solució 2

Els problemes del procediment d'en Luis:

1. Totes dues ordres sobreescriuen la còpia anterior sense avisar. Els noms app-backup i app.tar.gz són fixos. Cada dia es trepitja la còpia del dia anterior, així que en realitat només existeix una còpia: la d'ahir. Si el problema es detecta dos dies després, no hi ha res a què tornar.

2. Pitjor encara: se sobreescriu abans de saber si el desplegament va bé. Si el desplegament d'avui falla i ja has aixafat la còpia bona amb la còpia de la versió trencada, has perdut el punt de retorn.

3. cp -r no preserva permisos ni propietaris. L'executable pot perdre el seu bit d'execució i tot passa a pertànyer a l'usuari que executa l'ordre. Restaurar aquesta còpia deixaria l'aplicació sense arrencar. Ha de ser cp -a o, millor, rsync -a.

4. tar czf amb ruta absoluta. Guarda la jerarquia opt/tramontana/app/ dins del paquet. En extreure no obtens app/, sinó tres nivells de directoris, i tar avisa amb «Removing leading / from member names». Falta -C.

5. Es fan dues còpies redundants del mateix, una sense comprimir (48 MB) i una altra comprimida (19 MB), ocupant 67 MB per desplegament sense que cap aporti res que l'altra no tingui.

6. No hi ha verificació. Ningú comprova que el .tar.gz es pugui obrir ni que contingui el que ha de contenir. Una còpia que no s'ha verificat no és una còpia: és una suposició.

7. No hi ha cap control d'espai. Si /srv s'omple a mitja tar, queda un fitxer truncat que sembla una còpia vàlida.

Procediment reescrit:

Correccions aplicades:

• Nom amb data i hora: cada execució crea un fitxer diferent. No es trepitja mai res.
• Un sol paquet comprimit en comptes de dues còpies.
• -C /opt/tramontana app: dins del paquet hi ha un únic app/ net.
• tar preserva permisos i propietaris per disseny, així que no cal -a.
• || exit 1 a cada pas crític: si alguna cosa falla, l'script s'atura en comptes de continuar com si res. És el &&/|| de la lliçó 02-01 aplicat.
• Verificació amb tar -tzf abans de donar la còpia per bona.
• Suma de comprovació per detectar corrupció posterior.

El que encara li falta i arribarà al seu moment: rotació (esborrar còpies de més de N dies perquè /srv no creixi sense fi), que es fa amb find -mtime a la lliçó 03-03; automatització amb cron (03-07); i destí remot, perquè una còpia al mateix disc que l'original no protegeix contra una fallada de maquinari (05-08).

Com dir-l'hi a en Luis: el seu procediment fa el gest de copiar però no compleix cap de les tres propietats d'una còpia útil —única, verificable i restaurable—. I la més greu és la primera: en fer servir un nom fix, la còpia bona es destrueix just abans que la necessitis.

Solució 3

Elecció del format: zip. La Marta treballa a Windows i obrirà els fitxers amb l'Excel. Encara que a Linux tar.gz conserva millor les metadades, aquí això no aporta res —són fitxers de dades, no executables— i sí que suposaria que la Marta hagués d'instal·lar una eina per obrir-lo. Windows obre .zip de manera nativa amb doble clic. La compatibilitat amb el destinatari mana sobre la puresa tècnica.

(Aquell cat > fitxer <<'FI' és un here document: escriu tot el bloc al fitxer. S'explica al Mòdul 3; aquí el fas servir com a eina.)

Detalls del procediment que mereixen comentari:

• cd al directori i zip * en comptes de zip -r /tmp/x.zip /tmp/enviament-marta: així el paquet conté els tres fitxers a la seva arrel, sense la jerarquia tmp/enviament-marta/ a dins. És l'equivalent del -C de tar.
• cp -p conserva les dates originals de les dades, visibles al llistat del zip. La Marta pot veure que cases.txt és d'ahir i reserves.csv d'aquest matí.
• El LLEGEIXME resol per endavant la pregunta que la Marta hauria fet per telèfon: per què el CSV es veu malament a l'Excel. El separador punt i coma és el que fa servir reserves.csv, i en un Excel amb configuració regional espanyola sol funcionar directament, però convé documentar-ho.
• La suma de comprovació va en un fitxer a part, no dins del zip: ha de poder verificar-se sense obrir el paquet.

Nota important per al món real: reserves.csv conté noms d'hostes, és a dir, dades personals. Enviar aquest fitxer fora del servidor per correu o per un canal no xifrat té implicacions de protecció de dades. En un entorn real, aquest enviament hauria d'anar xifrat i comptar amb l'aprovació del responsable de protecció de dades. Tornarem sobre el xifratge de fitxers a la lliçó 06-05.

Ja escrius al disc, i ho fas amb xarxa de seguretat.

• touch crea fitxers buits i manipula marques de temps, i el seu ctime sempre delata la manipulació.
• mkdir -p és idempotent i crea arbres complets; rmdir és segur per disseny perquè només esborra el que és buit.
• cp sobreescriu en silenci; -a és l'opció per a còpies fidels; i el parany de la barra final i del destí preexistent produeix resultats diferents amb la mateixa ordre.
• mv és instantani dins del mateix sistema de fitxers perquè només canvia una entrada de directori, i és copiar-i-esborrar, lent i no atòmic, quan creua a un altre.
• rm és irreversible, rm -rf amb una variable buida ha esborrat sistemes sencers, i les defenses són mirar abans, -I, cometes i, sobretot, còpies de seguretat.
• rename -n reanomena per lots amb simulació prèvia.
• rsync -av és el cp correcte per a directoris: incremental, verificable, reprenible, amb --dry-run i amb la barra final que sí que importa.
• tar empaqueta preservant permisos; es llista amb -t abans d'extreure i es fa servir -C per no arrossegar rutes absolutes.
• gzip per defecte, xz per distribuir, zip per a Windows, i saps justificar l'elecció.
• I has preparat un paquet de producció complet: verificat, amb suma de comprovació i provat abans d'enviar-lo.

Ja saps moure fitxers de lloc. Falta el que hi ha a dins. A la propera lliçó, Visualització i Edició de Fitxers, aprendràs a mirar el contingut sense obrir un editor amb cat, less, head i tail —inclòs tail -F per seguir errors.log en directe mentre passa una incidència—, i a editar-lo amb nano a fons i amb el vim de supervivència que necessitaràs el dia que entris en un servidor on no hi hagi res més. Establiràs a més una convenció que el curs farà servir a partir d'aleshores: còpia de seguretat del fitxer de configuració abans de tocar-lo. I veuràs com comparar dues versions d'app.conf amb diff per saber exactament què ha canviat, que és la pregunta que es fa sempre després que alguna cosa deixi de funcionar.