Re: write only storage.
On 9/22/21 1:04 AM, Tim Woodall wrote:
On Tue, 21 Sep 2021, David Christensen wrote:
On 9/21/21 8:53 AM, Tim Woodall wrote:
I would like to have some WORM memory for my backups.
Have you considered snapshots -- e.g. btrfs, LVM, or ZFS?
I don't see how they help me - I am already using [LVM] snapshots to create
the backup. But if I can create the snapshot, I can delete it again?
I have not used LVM in years, and never tried LVM snapshots. As for
deleting an LVM snapshot, erasing a HDD is the easy part. The real
question is whether or not there is metadata somewhere in the source LVM
that records the creation, existence, and/or deletion of snapshots. If
so, destroying a snapshot means adjusting the relevant metadata.
uses dump to dump
the filesystem and uses ssh to write that dump to backup@backup17.
I prefer a "pull" architecture from a hardened backup host.
Yet, it is important that users have the ability to easily restore files
without assistance from the backup sysadmin. (When the backup sysadmin
is the only user, it is easy to forget this feature.)
It then runs restore to verify the backup. ...
I've been doing this for nigh on 25 years now, from cd to dvd to blu-ray
with various tweaks along the way and I've never lost anything
important.
That is an impressive system.
I rebuilt my backup processes when I converted to ZFS a few years ago.
Most of the hard work was done for me -- ZFS, zfs-auto-snapshot,
replication, etc. But, I had to redesign my processes to fit the new
reality, and to write scripts to automate the various use-cases. Along
the way, I re-visited my archive and imaging processes.
Homebrew backup solutions are tough. They save money, but cost time;
lots of time. Crawling through the details forces understanding. There
is a definite sense of satisfaction when things work. There is a
definite sense of terror when they do not. There is always a
subconscious fear that you have missed something.
Once it is working, you dare not touch anything. The chores become
chores. Do the grind, watch the outputs, burn the disks, visit the
off-site, buy more hardware/ media, stockpile old hardware/ media, etc..
Over time, the memories fade of how it all works; but it's your monster
and no one can help you. Making changes involves significant risk.
Even the smallest change demands re-learning and re-validation. Yet,
the machines and data being backed up change, so the backup system must
change. And, you are always wanting another improvement or feature.
I have often considered switching to one of the many available FOSS
backup solutions. Using a mature tool with a helpful user base is very
appealing, and probably less work in the long run.
But I'm conscious that to an extent I've been lucky. I do my best to
keep secure ...
Different data sources have different security, backup, archive, and
retention/ destruction needs. As the differences grow, so does the
complexity of the backup system.
The suggestion by Thomas Schmitt to write multiple sessions is a good
one. ...
If you are burning partial discs frequently, multiple seasons might work
for you.
David
Reply to: