New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
SSH backup to other VPS
I want to tar a backup to other server (because of space); is it OK?
ssh [email protected] "tar cz /var/www/html" > backup.gz
thx
Comments
If this is going to be a regular backup, using rsync over SSH seems like a much better solution?
I use this as a quick and dirty hack on a few VPS: https://www.thriftydevil.com.au/technology/secure-backups-with-rsync-and-ssh
Or you could use rsync over, well, rsync :-)
and how to tar it?
With tar of course.
Using rsync will minimize the amount of data that has to be transfer from the source server. Then build redundancy on the backup server using tar, or one of several applications designed for the job.
I was reffering to, tar the destination delete it... and the rsync again?
Sorry you lost me...
if you rsync, you'll create a folder on your destination, right?
I'm on the destination VPS, and I want it to tar it (or encrypt it). If I tar it, the rsync folder will not be encrypted, so I need to delete it. And then? If I rsync again, will rsync ALL the files again...
Yes that's true. Why do you want to encrypt the backup of your website?
because it will store mysql backups too, and they are from clients...
OK, From my understanding you have two options...
1) Tar + Compress (+ Encrypt?) the folder on the source VPS and then copy that file to your destination.
2) rsync the source folder to to your destination. Tar + Compress (+Encrypt?) it there.
If you do option #1, every time you copy the backup.tar.gz file it will need to copy the entire thing each time.
EG. in your backup folder you will have:
27062012.BACKUP.tar.gz
28062012.BACKUP.tar.gz
29062012.BACKUP.tar.gz
30062012.BACKUP.tar.gz
... etc
If you do option #2, it will only send files that have been updated. You should then tar and compress this into daily/weekly/monthly backups.
EG. in your backup folder you will have:
source/index.php
source/favicon.ico
source/...etc
backup/27062012.BACKUP.tar.gz
backup/28062012.BACKUP.tar.gz
backup/29062012.BACKUP.tar.gz
backup/30062012.BACKUP.tar.gz
backup/...etc
Option #1 will save you some CPU cycles on both machines when the backup is run.
Option #2 will save you significant amount of bandwidth when the backup is run.
Ok, compress.. then what will happen with that folder? =P
the only thing possible is with Truecrypt; I'm waiting to Damian to enable fuse module
Is the backup server somehow less secure than the live server?
@sleddog - nope, it is just a fancy thing
If you need encrypted backups try duply and duplicity
will check this, thanks
What do you do when someone breaks into your primary server and now has the encryption keys and ssh keys to delete your backups on the backup server?
push-based backups are inherently dangerous because all information needed to nuke them is kept on the server doing the push. There are some exceptions (e.g., tarsnap uses delegated authority, but it's likely too expensive for this case) but I personally prefer pull-based backups.
Yeah MainServer pushing backups to BackupServer is always going to be insecure, there is no benefit of encrypting. Using pull based backups is the way to go. Like @raindog308 said.
i push from primary server to a backup server. all backup of backup server pull from backup server.
@jcaleb, risky, shouldn't be done on production servers hosting customers of any type.
i will consider. thanks!
If you don't care if somebody can read your backups on a backup server, then the easiest solution is to run something like rsnasphot/rdiff-backup on the backup server and pull the data from different locations. In such case, if one of your machines will be compromised, your backup remains safe.
However, if you can't trust your backup provider, or you take into account, that your backup server could be compromised as well, and someone will have access to all your backups, what do you do?
Encrypted backup allows you to store your important files on an untrusted backup server. Even if someone will gain access to your backup server, the files there are quite useless for him.
As you said the dissadvantage of the push backup is however, the possibility of the backup destruction by an attacker.
To prevent this, one could combine both techniques: use push encrypted backups, for the data security on the backup server, and use second backup server which pulls encrypted backups from the the first backup server. In that way you will not loose your backup just because one of the client machines has been compromised.
This is the script I use to pull backups. It saves space because of rsync's hardlink feature. It can be more efficient, but it was coded quick. You do need to have passwordless ssh keys set up.
thank you, i will stick with rsync
rsync is pull based?
Seems like a problem that should be dealt with first. Should trust your backup provider just as much as your primary provider.
>
Rsync can go both ways. My script posted above pulls, but it can also push.
@jcaleb rsync can push or pull or IIRC can transfer between two remote hosts as well.
If you setup an rsync daemon you don't even need ssh on the machine(s)
cron