making fc20 backup

[Jackson Byers]

What I am still very uncertain :

how to handle, ie backup,
dirs like
/dev, /proc, /sys, /srv
/media, /run

In the past (f14,f16) I have muddled through these
somehow, but always felt I wasn't doing it quite correctly.

I recall some advice e.g., just create the dir,  /dev, but not its
contents.?
or,
Is it actually ok to do full update of all above dirs, including contents?
              What I am still very uncertain :

how to handle, ie backup,
dirs like
/dev, /proc, /sys, /srv
/media, /run

In the past (f14,f16) I have muddled through these
somehow, but always felt I wasn't doing it quite correctly.

I recall some advice e.g., just create the dir,  /dev, /proc,...
 but not the contents.
or,
Is it actually ok to do full update of all above dirs, including contents?

advice?

[Joe Zeff]

On 07/11/2014 03:21 PM, Jackson Byers wrote:
> What I am still very uncertain :
>
> how to handle, ie backup,
> dirs like
> /dev, /proc, /sys, /srv
> /media, /run

Don't.  I'm not sure about /sys and /srv, but the rest are created by 
the system at boot, and all you would do by "restoring" them would be to 
fsck your system up completely.

[Rick Stevens]

On 07/11/2014 03:33 PM, Joe Zeff issued this missive:
> On 07/11/2014 03:21 PM, Jackson Byers wrote:
> > What I am still very uncertain :
> >
> > how to handle, ie backup,
> > dirs like
> > /dev, /proc, /sys, /srv
> > /media, /run
>
> Don't.  I'm not sure about /sys and /srv, but the rest are created by
> the system at boot, and all you would do by "restoring" them would be to
> fsck your system up completely.

I use this sort of thing to back up to a directory named after the
machine and the date located on a USB hard drive mounted at
/run/media/Rick/USBDrive/backups:

rsync -avXA --exclude-from=/etc/skipdirs.rsync / 
/run/media/Rick/USBDrive/backups/`hostname`-`date +%d-%m-%Y-%T`

and where the contents of /etc/skipdirs.rsync is:

/proc/*
    /sys/*
    /dev/*
    /media/*
    /run/media/*
    **/.cache/google-chrome/***
    **/.ccache/***

/proc, /sys and /dev are dynamically created at boot so backing them
up is sort of a bad idea (well, backing them up is OK but restoring them
would be bad).

I don't back up /run/media or /media simply because I don't want to
back up removable media--especially anything I'm backing up TO (circular
references anyone?) I also don't back up various caches (and it's
shocking how much of that cruft there is).

If you want, you can back up /srv. RHEL-related systems (RHEL, CentOS,
Fedora) generally don't use it. Some distros use it for the webroot,
e.g. /srv/www or or other "sharable" or "servable" content. It's not a
dynamically created filesystem like /proc or /sys or /dev. Your choice.

For what it's worth, I have also used MondoRescue and Clonezilla with
success if you need to restore to bare metal after a total meltdown.

Just a suggestion. Your mileage may vary.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-     If you can't beat your computer at chess...try kickboxing!     -
----------------------------------------------------------------------

[Heinz Diehl]

On 12.07.2014, Rick Stevens wrote:
> /proc, /sys and /dev are dynamically created at boot so backing them
> up is sort of a bad idea (well, backing them up is OK but restoring them
> would be bad).

Why would this be bad?

The content of those dirs is dynamically generated and of variable and
often temporary nature. Thus, it shouldn't do any harm restoring them.
You do not want to reply system data without a reboot anyway.

Btw: "rsync -avxHSAX /source/ /target" will take care of it all, both
on securing and restoring. No need to operate with exclude lists and similar.

[Patrick O'Callaghan]

On Sat, 2014-07-12 at 09:50 +0200, Heinz Diehl wrote:
> The content of those dirs is dynamically generated and of variable and
> often temporary nature. Thus, it shouldn't do any harm restoring them.

Restoring /proc (if such a thing is even possible) would pretty much
guarantee screwing up your system. Recall that each running process has
a subdirectory in /proc under its PID, which is going to be different
when the system runs again and may indeed overwrite data from a
completely different process. Definitely not something you want to do
with a restore.

poc