Open main menu

CDOT Wiki β

Changes

OSTEP Infrastructure

2,590 bytes added, 14:29, 7 August 2013
Backup System
Here at CDOT, our current backup solution was a little archaic, and hard to expand on. I decided to make a new method of backup that can be run from a single computer and backup our entire infrastructure. This script is currently, as I'm writing this not in a finished state, however it is in a state where it works and is usable as a replacement to our previous system. I would like to pose a warning that this method of backup across systems is not a very secure method, and it does pose security threats. Since it does require you to give some users nopasswd sudo access to some or all programs. I am looking for a way around this, and would appreciate any input on this matter.
 
The script is to be run on the computer: bahamas
The script is to be run with the user: backup
== Goals ==
So to get the most speed out of your backups, and finish all schedules as fast as possible, run this script in the crontab at a high frequency. What a high frequency is, is really up to you, there is hardly any harm in running it too often, as it will just end itself if there is nothing to do. Whether you run the script once a day or once every 10 minutes, the script will get the job done.
=== Advanced sbk Options ===
 
Most of these options are just for me to debug while making the script, however some of them may be useful for managing backups. Note: when using the "--sid=<id>" please replace <id> with a number.
 
Remove a single schedule from the queue.
 
<pre>
 
sbk --remove-queue --sid=<id>
 
</pre>
 
Remove a single schedule from running(this will NOT currently end the backup that is running).
 
<pre>
 
sbk --remove-run --sid=<id>
 
</pre>
 
Expire a schedule so that it appears as though it has not run today, useful if you want to force a backup to run a second time.
 
<pre>
 
sbk --expire --sid=<id>
 
</pre>
 
Add a schedule to the queue. This is similar to expire in function, except you don't have to wait for the time field to expire. Next time "sbk --queue" is run, it will run this backup.
 
<pre>
 
sbk --add-queue --sid=<id>
 
</pre>
 
=== Logging ===
 
I could not figure out the format for the logging. Too many options. I went with a procedure where it makes a new log file each time the program is run. This could be a problem if you run the script too frequently, since it will make so many log files. I think the best idea would be to log to a single file, or to log into the sqlite3 database. I have not had time to change this yet.
 
Logging directory:
 
<pre>
 
/var/log/smart-bk/
 
</pre>
 
Logging format:
 
<pre>
smart-bk-yyyy-MM-dd-hh-mm.log
</pre>
 
== Backup Host Configuration ==
 
One of the main drawbacks to using this script is, it requires a bit of configuration on all computers using the backup system.
1. backup user created on all computers
 
2. backup user must be able to ssh without a password from any computer to any other as backup user
 
3. backup user must have sudo access with the nopasswd option on the rsync program and tar program(Security risk! Giving rsync sudo access allows backup user to modify any file.)
 
4. root user must be able to ssh to all backup users from any computer(This is annoying, trying to find a way around this.)
 
5. add custom users such as koji to work with ssh no password to all backup users, give root access to koji user in the same way
 
6. WARNING, make sure you disable the passwords on all these backup accounts, that way they can't log in and get access to root without a private key
 
This list of configurations, that need to be done to each computer, is annoying and could be done better. Currently looking for ways to change it. After these configurations are made, you can use this host in any backup schedule.
198
edits