Få ut mer av Fotosidan som inloggad
Fotosidan är gratis! Som inloggad får du smarta funktioner. Du kan ladda upp 10 bilder och få kritik på dem. Du får vårt nyhetsbrev. Du kan skapa köp&sälj annonser mm
Merläsning
Panelsamtal: Retuschör – Ett yrke på utdöende?
Föreläsning
Håller AI på att ta över produktionen av bilder – och vad innebär det för retuschyrkets överlevnad och för bildbranschen i stort? Bilddesign befinner sig just nu i en stor förändringsfas. Vilken roll spelar en yrkesutbildning för att driva utvecklingen åt rätt håll? Den 20 november bjuder Fotoskolan STHLM in till ett panelsamtal på Fotografiska med experter inom branschen som ger sin bild av framtiden.
Läs mer...
10 Kommentarer
Logga in för att kommentera
Hittar inget bra. Mest hack för att kunna köra Picasa eller andra hack.
"Får du till exempel en systemkrasch eller ett virus i din dator så påverkar inte det nätverksdisken som är en separat dator."
Om man får ett virus som söker upp och förstör eller kidnappar bilder så är NAS'en helt oskyddad. Om du kommer åt dina bilder via din dator så gör viruset det också.
För attacker som riktar sig mot enskilda filer är de svårt att skydda sig, men jag uppfattar inte sådana som speciellt vanliga.
Sedan finns det numera ganska gott om nas-enheter som kan köra eget virusskydd (helt separat från det du kör i huvuddatorn) vilket också ger ett extra skydd. Så jag vidhåller att lagring på en nas trots allt ger stora säkerhetsmässiga fördelar.
Att säga att en NAS INTE påverkas av virus i datorn är bara fel och vilseledande. Kanske inte jättevanligt men fortfarande fel.
"Polisen varnar för ett avancerat datavirus som låser fotona i din dator. Du måste betala för att få bort viruset."'
http://www.sydsvenskan.se/sverige/polisen-viruset-laser-privata-foton/
Varför är filsystem viktigt. Jo för att dom två vanligaste HFS+ (apple) och NTFS (windows) kontrollerar inte sig själva. Dom märker med andra ord inte om disken råkar ut för bitrot. Något som är oundvikligt, alla diskar kommer att förstöra sig själva förr eller senare.
Därför behöver man ett filsystem som har checksum funktionen och på så sätt är medveten om något händer med disken och kan korrigera det. Detta är oerhört viktigt! Med ett filsystem som har checksum så vet datorn alltid vad som ska stå på disken och kan korrigera fel som uppstår.
Sitter man på en Apple dator så är det tyvärr kört. Då måste man ha en NAS som kör linux, vilket inte är ovanligt. Linux har flera filsystem som klarar detta där ZSF är det vanligaste. Kör man Windows så har faktiskt Microsoft löst detta efter många år, med windows storage spaces ReFS. Dock kan man inte köra hela system på detta utan bara Backup. Så kör ni windows 8 eller senare se till att använa er av windows storage spaces.
Mac, ja tyvärr måste ni då köra Linux NAS. Nackdelen kvarstår dock. Om orginalkopian råkar ut för bitrot så kommer det kopieras till NASen och den har ingen chans att veta om datan den får redan är trasig eller hel. Detta är alså ett stort problem som inte många vet om och även ganska svårt att hitta en bra lösning på. Just nu är Linux det bästa alternativet men svårt för fotografer att hitta tillfredställande programvara. Windows börjar närma sig medans Apple ignorerar det totalt.
Och vad man än gjör, lita inte på det uråldriga RAID, framför allt inte på software RAID. RAID har ingen självkontroll. Software RAID är änu värre eftersom den inte ens får reda på om den lyckats skriva datan eller inte.
Hoppas detta hjälper någon och vill man göra riktiga Backups är detta A och O. Det finns mycket info på nätet om detta så läs på!
Jag håller med om att det finns en stor övertro på raid som säkerhetslösning. Som jag ser det kan raid kan ge tydliga prestandafördelar och förenklad hantering genom att se flera diskar som en enda (raid 0) och att det kan ge tydliga tillgänglighetsfördelar (raid 1, 5, 6, 10 osv). Men ser man till övergripande datasäkerhet så blir den ju faktiskt sämre med raid 0 och förmodligen ofta plus-/minus noll med övriga (ger vissa fördelar som äts upp av ökad komplexitet som i sig är felkälla).
1Tb är gratis och enkelt att ladda upp och skapa album som kan sätta tillstånd vilka som får tillgång till dessa.
Finns ett batchpgm som är enkelt att använda.
Man kan skapa flera konton om nu inte 1Tb räcker.
Får plats med över 300 000 på ett konto.
För mig funkar det bra.
Kör själv backup via Acronis mjukvara. Funderar dock på hur man ska resonerar när det gäller inkrementell backup. Går det bara att lagra på mer och mer av det här (kör en backup varje natt) eller ska man låta programmet göra en helt ny backup då och då?
Sedan funderar jag på hur viktigt det är att köra validiering av backupen via mjukvaran. Tar ju en hel del tid? Är det vanligt att programmet gör "skrivfel"?
En nackdel med att bara köra på med inkrement är att återställning blir mer tidsödande ju fler inkrement man har att hantera. Om jag inte minns fel så är standardinställningen i programmet att göra nya grundbackuper med jämna mellanrum. Själv kör jag inkrementellt varje natt och skapar en helt ny grundkopia en gång per vecka. Vill man sedan ha både livrem och hängslen kan man ju dessutom göra en filbackup av veckans image-filer (grund + inkrement) just innan de uppdateras. Då kan man ju i nödfall backa två veckor i tiden.
Jag har jobbat mycket med i synnerhet Ghost sedan slutet av 1990-talet (effektivt t.ex. när man vill nyinstallera ett fyrtiotal datorer varje morgon :-) och har på senare år kört Acronis hemma. Jag har aldrig råkat ut för valideringsproblem, men funktionen finns ju där av en anledning. En gång med fel är ju en gång för mycket så jag tror det kan vara en bra idé att köra kontroll då och då.
Själv kör jag MD5-summor.
Just nu använder jag FileVerifier++, genererar en checksummefil med ett högerklick på berörda filer; filen blir kompatibel med en massa MD5-summeprogram inkl de i linux/mac.
Enda nackdelen är att Lightroom envisas med att lägga XMP-data *i* jpegfiler istället för brevid som för rawfiler, så checksummorna pajas om man ändrar i Lightroom. Jag checksummar bara rawfilerna.
CHECKSUMS.MD5:
ae1b13ab62fec7ddaa6ee550f558cd6d *_MG_6601.CR2
3a8fea6a7dc5c047f78fb0c8d05aa22b *_MG_6602.CR2
d1ba037c5c6b51bbe7fdffaf0dd593eb *_MG_6603.CR2
...
...