[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Periodic refresh (or rwrite?) of data on an SSD (was: Re: Recommended SSDs and 4-bay internal dock)



On Sat, 14 Jan 2023, at 15:49, Dan Ritter wrote:

> Let's separate the problem into three cases:
>
> - I recently deleted some files, I want them back. (Same as "I
> recently changed some files, I want the old versions.")
>
> - I have lost a filesystem for some reason, I want it restored.
>
> - I need to have archival copies of some data which I probably
> will never access, but just in case...
>
>
> The deleted/changed files problem is best solved, if plausible,
> with a snapshotting filesystem like ZFS, with automatic
> snapshots and automatic deletion of sufficiently old snapshots.


Although this is a debian list, not all my data is on systems that 
support such FSes.  Eg on Windows ...  There, I keep all the data
where I want access to prior versions of files in Dropbox; I have
a year's worth of old versions of all those files.  (But finding the
right one to reinstate is clumsy.)

I also sometimes run a program that monitors selected filetypes
and filenames within a specific directory and every time one of 
the matching files changes makes a date & time-time suffixed
filename copy of that just-changed file.  So if I was editing file

   xyz.pqr

in a GUI appplication, every time I do a File->Save from within
it as well as the xyz.pqr filebeing written to disk, a new file is
created, named

   xyz (svd@20120716-190723).pqr

containing a copy of the just-saved file.

I first started using this when I was trying to reproduce, for the
programmer, some file-corrupting tendencies in his application
and wanted to make saved copies of the file after every change
I made to it in the GUI.  I kept detailed notes of exactly what I 
did corresponding to each "(svd@20120716-190723)" value.

The programmer wasn't appreciative.  He said "no other user
complains as much as you do", rather than saying "thank you 
very much for providing detailed steps to reproduce each of
these problems".  Bah!



> The restore-a-filesystem problem is best solved with a complete
> filesystem copy to a similarly sized disk. SSDs are nice and
> fast, but you may not actually need that speed if you don't have
> to do a restore very often. ZFS send or rsync are good tools
> here, or borg if you have special requirements.

It's not so much the speed that attracts me to SSDs as the lack of
moving parts and their resistance to shock.


> The archive problem is best solved with spinning disks, which
> are fast enough for most cases, much better priced per capacity,
> and have well-understood stability over long periods of
> unpowered time. 

Speed is not a colossal issue - backups can always run while I eat
or sleep or whatever.  Price is not that much of an issue either, as
I know the hard way that angst & the time cost spent recovering 
lost data rapidly outweigh the minor capital cost of more backup
devices.  

The long-term stability of spinning rust is certainly becoming a 
lot more important to me.  But I already plan to store future 
backups on both types of disk.



-- 
Jeremy Nicoll - my opinions are my own.


Reply to: