# A strategy to securely backup ?

## javeree

At home I want to have a centralized backup of multiple hosts.

I want in particular to back up the /etc and /home of each host.

I wanted to let each client share /etc and /home, have the backup PC mount these shares and then rsync them to a disk.

The problem is: in order to be allowed to read every file, I would need to mount these shares as root. 

On the other hand, making these shares available as with no-root-squash would allow any PC with local root access to read all critical data. 

I am sure others already thought up similar backup schemes. What has been your approach to doing a 'secure' backup over network ?

----------

## V-Li

 *javeree wrote:*   

> At home I want to have a centralized backup of multiple hosts.
> 
> I want in particular to back up the /etc and /home of each host.
> 
> I wanted to let each client share /etc and /home, have the backup PC mount these shares and then rsync them to a disk.
> ...

 

A cron job with rsnapshot is not possible?

----------

## Hu

Why not have the individual clients upload their designated directories to the backup server?  You can arrange for them to upload tar files to a restricted user or group of users on the backup server, so that no system bestows root access to any other.  The only way one machine could compromise another would be for the backup server to maliciously modify a tar file and then wait for the client to be rebuilt from that tar file.

----------

## neonknight

How about using a client-/server-backup solution such as amanda or bacula? You install a client application on each computer. This client runs with root privileges. Then the server pulls the backup files from your client and stores them in the data storage volume you specified. It also keeps track of all backupped files in a database, so you can easily revert to any version of your incremental backup.

My current approach at home is using rdiff-backup over ssh. In this approach, my clients push the data to the server. This reduces the heavy overhead of a centralized, managed backup solution.

----------

## javeree

A lot of good replies, but no surprises. Most of these things have been under my consideration too.

@V-Li

rsnapshot (was new to me) seems to take approximately teh same approach as I do, mainly with more sophisticated handling of multiple generations. However, I think it has teh same problem as my solution:

"rsnapshot will typically be invoked as root by a cron job" => any local root could gain access to a remote client sharing with no_root_squash

@Hu

making the clients responsible for their own backup was also somthing considered, and may still be the way I go. The main drawback I see is that I don't know of a way to incrementally update a tar file. so adding files only if newer, and especially deleting files not existing anymore. If that feature does not exist, the alternative is to recreate a complete tar file again every day, and sending all that data over the network, about 800 Gb => this would take hours, even if not a single file changed. I would still have to cater centrally for the Windows PCs, but these are not that important security wise, so my current approach is OK there.

@neonknight

I also looked (shortly) into amanda, but was wondering if this is really a free solution. It looks like there is a paying and a non-paying version. I can live with that, but it puts me on my guard that at any time, the solution may be not available anymore. I will definitely look into it a bit closer then. the good thing is the philosophy that each client seems to define its own backup user with its own password, and then probably suids into root to actually read the files. => any distributed password is not the root password. I am going to check this out a bit more. 

Finally, I will definitely check out bcking up using a connection over ssh. Until now, I never used ssh but manually, and using passwords instead of using ssh-keys. It may be possible to use a concept similar to the user concept of amanda (allow only a specified user to execute a specific backup command, and then let the backup command drop to root when needed).

As always, Windows clients don't play nice with such a solution, but as already said, I don't treat them as secure anyway, so any data on it I consider as public. 

@All

thanks for your comments

----------

## gentoo_ram

Have the clients run rsync and send the files to a directory on the server.  You can do rsync over ssh and give the clients each their own account on the server, so they each have their own private directory.  Seems like that should work, and you talked about using rsync anyway, just the other direction.  

For extra security, you could probably set up the server backup accounts to authenticate via SSH public-key login with no passphrase on the private key (on the client).  That way, you don't need to store the passwords on the client and the server-side is still secured with authentication.

----------

## lxg

javeree: Have a look at rsnapshot. Yes, you must allow it root access, but that's necessary to preserve file ownership information and be sure to have access to all files. Apart from that, it's exactly what you need, and it's very easy to set up. As an extra bonus, it saves a bunch of space by using hardlinks, while you can have a partial restore at any time you want.

----------

## dmpogo

You can have a look also at backuppc

----------

## Quincy

I could suggest rdiff-backup using a ssh tunnel. This consumes very limited amount of traffic and works quite well for years now.

----------

## Hu

 *javeree wrote:*   

> @Hu
> 
> making the clients responsible for their own backup was also somthing considered, and may still be the way I go. The main drawback I see is that I don't know of a way to incrementally update a tar file. so adding files only if newer, and especially deleting files not existing anymore. If that feature does not exist, the alternative is to recreate a complete tar file again every day, and sending all that data over the network, about 800 Gb => this would take hours, even if not a single file changed. I would still have to cater centrally for the Windows PCs, but these are not that important security wise, so my current approach is OK there.

 Given your requirements, I think my proposal is not a good match.  However, I would like to correct one misunderstanding.

Although not exactly what you requested, you can get close by telling tar to pack up only files newer than the previous tarball, which will give you small incremental backups.  This is different from incrementally updating the tar file itself, but it does avoid sending huge backups when only minor changes have occurred on the client.  To work around the inability to directly delete files, you would need to periodically create a new full backup and discard prior tar files from that client, which is undesirable for the size of data involved.  Also, my approach assumes that it is rare for a file to be deleted when it is undesirable or unacceptable for the file to reappear when the backup is restored.  I typically apply this incremental design only to directories known in advance to contain a mostly static number of files, which may change, but are never removed and rarely have new files added.  Thus, there are no deleted files which would reappear if a backup were restored.

----------

## 1clue

IMO complex backup schemes are doomed to fail when the $#!+ hits the fan.  Every scheme has a serious shortfall, no matter how much money or bandwidth you have.  Not many archive formats let you have a large file, and if part of your critical data is a virtual machine you're pretty much done with archives before you start.

Most people (including companies) who come up with some sort of backup strategy have never tested it until it was critical to do so, and then they find out just how bad their plan was.  My first company as IT, they used a tape drive to religiously back everything up regularly, but it turned out the drive couldn't read its own tapes.  Didn't know until it was too late.

Personally I only need 1 host backup.  I have a removable drive that is large enough to hold everything uncompressed.  My backup stores the directories I want on the drive, uncompressed but with proper ownership and permissions.

Were I really concerned about my data, I would have two or more of those removable drives.  Every day I would remove the recently used one and put in the oldest of the set and then carry that drive out to a secure off-site location.

Advantages: It involves no network activity to be sniffed, and can be done safely as root.  It relies on nothing more than cron and a recursive copy, and the fact that your backup drive is as large as or larger than the data being stored.  There is nothing simpler technically, and the fact of you needing to swap the drives makes sure you're actually paying attention.

Problems: It requires human activity in order for the backups to be safe and to be rotated effectively.  And it's not multi-host.

It used to be that you could set up a drop box using ssh by going into a directory where you have only write permissions.  This might help.

Another approach I've used, when not concerned about fire as much as about a hard drive failure, and if you have small files:  Back up each host to your files, say you have machines A, B and C.  Copy A's backup to B and C, B's backup to A and C, and C's backup to A and B.  You can establish a private account for each host which is unprivileged.  Write to that account through ssh and you have encrypted traffic to a non-privileged account.  At that point you can lose all but one of your computers without losing your data.

Good luck and have fun.

----------

