Is there a reason not to back up a running root partition

[swerdna]

Hi I use rsync to back up and sync my data partitions.

For example typically like this to sync the /home dir:

mount /dev/sdb7  /mnt/sdb7
rsync -azv --delete /home/  /mnt/sdb7
umount /dev/sdb7

That works well at end of day time I run it and it sync-updates /home to a second drive. Currently I do pretty much the same thing for the root partition by booting into CD Knoppix and update-syncing the root partition. I do that because I “assumed” it’s not a good thing to sync a working root partition while it is “running”. It’s such a pain to boot a live CD to do it!

Here’s the question: was my assumption wrong – could I sync the root partition from within my working computer?

[Miuku]

I do not see why not - the only files that you cannot access are ones that are created automatically by various daemons anyway.

I do it all the time - I even piped a physical machine into a VMware VM via netcat - happily on the fly :3

[malcolmlewis]

@swerdna

Hi I use rsync to back up and sync my data partitions.

For example typically like this to sync the /home dir:

mount /dev/sdb7  /mnt/sdb7
rsync -azv --delete /home/  /mnt/sdb7
umount /dev/sdb7

That works well at end of day time I run it and it sync-updates /home to a second drive. Currently I do pretty much the same thing for the root partition by booting into CD Knoppix and update-syncing the root partition. I do that because I “assumed” it’s not a good thing to sync a working root partition while it is “running”. It’s such a pain to boot a live CD to do it!

Here’s the question: was my assumption wrong – could I sync the root partition from within my working computer?

Hi
Are you running btrfs on / is so backup the snapshots?
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

[swerdna]

@malcolmlewis

Hi
Are you running btrfs on / is so backup the snapshots?
Incremental Backup - btrfs Wiki

Not running btrfs. This machine I use and need on and off all day, money income involved, so I need for it to be a low risk machine.

[swerdna]

@Miuku

I do not see why not - the only files that you cannot access are ones that are created automatically by various daemons anyway.

I do it all the time - I even piped a physical machine into a VMware VM via netcat - happily on the fly :3

Thanks Miuku

[robin_listas]

On 2014-12-04 01:16, swerdna wrote:

> Here’s the question: was my assumption wrong – could I sync the root
> partition from within my working computer?

My normal strategy is to do an image full backup (or xfsdump) of system
partitions, sporadically, and then periodic rsyncs while running.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[swerdna]

@robin_listas

On 2014-12-04 01:16, swerdna wrote:

> Here’s the question: was my assumption wrong – could I sync the root
> partition from within my working computer?

My normal strategy is to do an image full backup (or xfsdump) of system
partitions, sporadically, and then periodic rsyncs while running.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Thanks

It occurs that I would need --exclude switch for a live sync because I don’t want /mnt (4 partitions there) and /home (treated separately).

[Fraser_Bell]

@swerdna

Thanks

It occurs that I would need --exclude switch for a live sync because I don’t want /mnt (4 partitions there) and /home (treated separately).

Yep, good thinking, A.

I also tend to do something somewhat similar to what Carlos said. Regular weekly backups, more often at high-change times and before risky ventures, and also syncs of root and home. Even if one or two files are not correct because they were on a system running at the time, it comes in super handy when you discover you want one file or one chain of files:

sync back or copy back those files, back in business in mere seconds or minutes.

[nrickert]

@swerdna

Thanks

It occurs that I would need --exclude switch for a live sync because I don’t want /mnt (4 partitions there) and /home (treated separately).

I do that differently.

I create subdirectories of “/mnt”:

# cd /mnt
# mkdir 1 2 3

You can create others. Maybe even create “/mnt/root”

If I want to backup the root partition, I would do something like:

# mkdir /mnt/root
# mount --bind / /mnt/root

and then I would actually backup “/mnt/root”.

The reason: A bind mount doesn’t carry with it mounted file systems. So under “/mnt/root”, the directory “home”, “dev”, “proc”, “sys” etc will all be empty directories. That way you avoid backing up mounted file systems. When done, just use a “umount” to undo that mount.

I do something similar with “/home”. That’s because I do use an ecryptfs private directory, and this trick excludes the mounted “/home/$user/Private”, though its encrypted backing file “/home/$user/.Private” will be backed up.

Backing up a bind mount is easier than using a bunch of “–exclude” options.

[swerdna]

@nrickert

I do that differently.

I create subdirectories of “/mnt”:

# cd /mnt
# mkdir 1 2 3

You can create others. Maybe even create “/mnt/root”

If I want to backup the root partition, I would do something like:

# mkdir /mnt/root
# mount --bind / /mnt/root

and then I would actually backup “/mnt/root”.

The reason: A bind mount doesn’t carry with it mounted file systems. So under “/mnt/root”, the directory “home”, “dev”, “proc”, “sys” etc will all be empty directories. That way you avoid backing up mounted file systems. When done, just use a “umount” to undo that mount.

I do something similar with “/home”. That’s because I do use an ecryptfs private directory, and this trick excludes the mounted “/home/$user/Private”, though its encrypted backing file “/home/$user/.Private” will be backed up.

Backing up a bind mount is easier than using a bunch of “–exclude” options.

I like this method, thanks, I’m going to try it out.

[swerdna]

@Fraser_Bell

sync back or copy back those files, back in business in mere seconds or minutes.

True, that could be the job that tacks on to the “bind” method of nrickert

[swerdna]

Well thanks everyone, I finished up with this script which takes the --bind files over to a storage folder called “current” on sdb6

#!/bin/sh
echo "remember this goes from the /mnt/root bind directory --> sdb6 backup"
echo "if you are not root abort immediately"
mount /dev/sdb6 /mnt/sdb6
ls -l /mnt/sdb6
read -p "Press [Enter] key to continue....."
mount --bind / /mnt/root
ls -l /mnt/root
read -p "Press [Enter] key to continue....."
rsync -azv --delete /mnt/root/ /mnt/sdb6/rsynctwroot/current
umount /dev/sdb6
umount /mnt/root

It works fine

[robin_listas]

On 2014-12-04 13:26, nrickert wrote:

> The reason: A bind mount doesn’t carry with it mounted file systems.
> So under “/mnt/root”, the directory “home”, “dev”, “proc”, “sys” etc
> will all be empty directories. That way you avoid backing up mounted
> file systems. When done, just use a “umount” to undo that mount.

Wow! That’s a very interesting trick. I like the idea.

> Backing up a bind mount is easier than using a bunch of “–exclude”
> options.

Indeed…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

[malcolmlewis]

Hi
But at the end of the day, you can always just create an autoYaST file, build an image on SUSE Studio and use that, added bonus is you have additional repositories they can be added. Config files added/changed. There is also kiwi to create your images as well…

I gave up system backups a long time back, I can run configuration scripts for my user to add softlinks (eg .bashrc, Music, Videos, Pictures etc) off on a data partition (which is backed up via fwbackups). Before using SUSE Manager, I just used scripts to add stuff to config files, eg sysctl.conf, hosts, udev rules etc.

At the end of the day, it all depends as well on your end use case, be a desktop or a server install, just make sure you have backups (and keep them off site if you can…).

[Fraser_Bell]

@nrickert

The reason: A bind mount doesn’t carry with it mounted file systems. So under “/mnt/root”, the directory “home”, “dev”, “proc”, “sys” etc will all be empty directories. That way you avoid backing up mounted file systems. When done, just use a “umount” to undo that mount.

I do something similar with “/home”. That’s because I do use an ecryptfs private directory, and this trick excludes the mounted “/home/$user/Private”, though its encrypted backing file “/home/$user/.Private” will be backed up.

Backing up a bind mount is easier than using a bunch of “–exclude” options.

Great stuff! I like this, probably will now make some additional changes to my own way of doing things.

Thanks!

[Fraser_Bell]

@swerdna

Well thanks everyone, I finished up with this script which takes the --bind files over to a storage folder called “current” on sdb6

#!/bin/sh
echo "remember this goes from the /mnt/root bind directory --> sdb6 backup"
echo "if you are not root abort immediately"
mount /dev/sdb6 /mnt/sdb6
ls -l /mnt/sdb6
read -p "Press [Enter] key to continue....."
mount --bind / /mnt/root
ls -l /mnt/root
read -p "Press [Enter] key to continue....."
rsync -azv --delete /mnt/root/ /mnt/sdb6/rsynctwroot/current
umount /dev/sdb6
umount /mnt/root

It works fine

Looks good. I quite like it. I also like the fact you include a warning message.

[Fraser_Bell]

@robin_listas

On 2014-12-04 13:26, nrickert wrote:

> The reason: A bind mount doesn’t carry with it mounted file systems.
> So under “/mnt/root”, the directory “home”, “dev”, “proc”, “sys” etc
> will all be empty directories. That way you avoid backing up mounted
> file systems. When done, just use a “umount” to undo that mount.

Wow! That’s a very interesting trick. I like the idea.

So …

Who was that said: “You can’t teach an old dog new tricks.”? rotfl!

This old dog just learned a few new ones. Sadly, a couple of decades ago when my mind was younger and sharper, I used to come up with things like this all the time. Now, I struggle with coming up with ways to remember what I did this morning after I got up. (I did get up, didn’t I?)

[robin_listas]

On 2014-12-05 00:36, Fraser Bell wrote:
> robin_listas;2680669 Wrote:

>> Wow! That’s a very interesting trick. I like the idea.
>
> So …
>
> Who was that said: -“You can’t teach an old dog new tricks.”-? rotfl!
>
>
> This old dog just learned a few new ones. Sadly, a couple of decades
> ago when my mind was younger and sharper, I used to come up with things
> like this all the time. Now, I struggle with coming up with ways to
> remember what I did this morning after I got up. (I -did- get up,
> didn’t I?)

LOL

But we do know a lot of them tricks. More than others may ever learn.
If we can remember them, that is :-p

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)