rdiff-backup-users
[Top][All Lists]
Advanced

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

Format of backup matters more (to me) than which software that does it


From: rhkramer
Subject: Format of backup matters more (to me) than which software that does it
Date: Thu, 28 Nov 2019 10:01:23 -0500
User-agent: KMail/1.13.7 (Linux/3.2.0-6-amd64; KDE/4.8.4; x86_64; ; )

Two introductory things:

   * Happy Thanksgiving to all!

   * I am not very good about doing regular backups, or backing up everything 
that should be backed up

I'm writing this to maybe spark a discussion which might include links to 
sources that provide the answers I'm looking for (for which I'm looking ;-).

To me, I don't care too much or at all what software does my backups, I would 
like to have a convenient almost one button (one cron job) method to do my 
backups, and then I care more about how the backups are organized / formatted, 
with the idea (among others) that a variety of software could write to or read 
from the backups as organized.

I guess the exception to not caring about the software is that I do recognize 
that programs that use rsync are useful at times, especially when the backup 
is remote.  (But using rsync could be an option of any backup program, not 
just, for example, one like rdiff, which, iiuc, is written specifically to 
(always?) use rsync.)

Is there any standard for the organization of backed-up files?  Maybe even a 
default standard (something that several backup programs use)?

I'm going to elaborate -- I mean things like the naming of files, the naming of 
directories of files, compression of files (or tarring), encryption of files,  
whether perhaps they are stored as diffs, etc.

I want to elaborate further, but I don't know how best to do that -- let me 
describe (in probably too long a writeup) how I'd like my backup files to be 
stored.

First of all, I want to distinguish between backups of the system and backups 
of user data (and sort of an inbetween one, backups of user / system 
configuration data).

Next, let me say that I personally don't care too much about having a backup 
to do a bare metal reinstall of my system, I am much more interested in what I 
consider my "user data" -- files that I've created or collected (whether they 
be programs, source code, text files, spreadsheets, photos, sketches, videos, 
audios, ...).  

If I personally have a system "occurrence" that requires a bare metal 
reinstall, I am more likely to install a more recent system from scratch.  For 
example, my "daily driver" is a Debian Wheezy system -- if it dies, I will 
probably install the latest Debian (Buster) and then restore my user data, 
rather than restoring the Debian Wheezy system.  

(There could be exceptions or reasons not to do it that way -- I hear people 
complaining about systemd stuff, and having problems (either real problems of 
systemd or just new approaches that are required that a user is not yet 
familiar with), so if I found a lot of problems I might go back to Wheezy (or 
something inbetween, like Jessie).  

If I did go back to Wheezy, my first thought is that I'd reinstall Wheezy from 
scratch, then consider adding the user / system configuration files (the stuff 
in 
/etc and /home/<username./.*) -- that would probably be on a selective basis 
as I found things that weren't working as I desired after the "from scratch" 
install.

Anyway, another thought occurred to me as I write this -- maybe what's needed 
(maybe what I would like to have) is a very easy to read and modify backup 
configuration file, that many backup programs could read, write, and utilize.

In it, I could specify, by directory | filename | (maybe) partition, which 
files 
to backup, how often to back them up, where to store them (and organize them), 
whether to encrypt them, tar them, compress them, store them as diffs (I forget 
the right terminology, so let me just say forward or reverse deltas), how to 
name new directories | files that might be created, whether to use the rsync 
type transmission algorithm, and maybe other things that don't come to mind 
atm.

Then, knowing how the backup is stored, I'd have the freedom (and knowledge) 
to restore anything that I needed to restore -- a single file from yesterday, 
last week, or wheneve; all my user files; all my encrypted files, and even a 
bare metal complete reinstall (including or not including my user data).

Of course, I'd like the backup program to handle at least some of those 
restorations, but I'd also like the freedom to use other OS (CLI?) tools to go 
into the structure of the backedup files and do whatever I wanted / needed to 
do.

So, maybe rather then elaborating any further, I'll just ask if anything like 
a "standard" backingup configuration file exists, or a standard organization of 
backups, or if several such candidates exist, or if neither of the above, does 
anyone else see the advantage of such an approach?

(One advantage that I hope I've alluded to but maybe not explicitly stated is 
that, if one backup program disappears, other backup programs could continue 
to work with the "standard" backingup configuration file and the standard (or 
the user customized) organization of the backed up files.

(I won't go much into organization of the files, but one such "choice" to be 
made is how subsequent backups are organized in directories, for example, each 
new backup in a new directory, with the same basic name, but with a suffix to 
indicate the date (and time?) when that backup was made.  (And, are backups 
older than a certain time frame deleted, or compressed, or moved to another 
storage medium?))














reply via email to

[Prev in Thread] Current Thread [Next in Thread]