Can somebody bring me some coffee? Please?
Can somebody bring me some coffee? Please?
Have fun watching ….
I am backing up my Linux machines bare-metal with ReaR, in the form of weekly full backups and incrementals. ReaR does a great job but doesn’t cleanup old backups by itself, so if you do nothing you’re filing up your backup server sooner or later.
As I am lazy Linux sysadmin I don’t want to cleanup leftovers manualy, so I automated it 🙂 Here is how:
First: my /etc/rear/local.conf
BACKUP_PROG_EXCLUDE=( ‘/tmp/*’ ‘/dev/shm/*’ ‘/mnt/*’ ‘/media/*’ $VAR_DIR/output/\* )
This will create a full backup every friday, and incrementals on all other days.
In the picture below you see what happens if you let things run it’s course:
I have got 11 backup archives of which I only need 4 (today) to recover when needed. The archives with an “F” in their name are full backups, the other ones (with “I”) are incrementals. There are also two important files here, basebackup.txt and timestamp.txt. Those two files actually do sort of the same: tell the system when the last full backup was made. ReaR needs this for restoring the system, using the correct files. I only need timestamp.txt for my cleanup job, but I could also use basebackup.txt for them. What’s in those files is not important to me, I use the time and date they where created or modified. Today is march 17, so every archive created before the last full backup (march 13 in this case) may be deleted.
To find out what files can be deleted you can issue the following command in the terminal:
find /media/nfs/lamp02/*tar.gz -type f ! -newer /media/nfs/lamp02/timestamp.txt
(make sure to adjust the path to your own situation!)
To delete them issue the following command:
find /media/nfs/lamp02/*tar.gz -type f ! -newer /media/nfs/lamp02/timestamp.txt | xargs rm -f
(Again, adjust your paths!)
All files created before the last full backup will be gone, keeping your backup server clean 🙂
The only thing you have to do now is create a proper cronjob to automate this. Be sure the command runs AFTER the backups are complete!
For the best results you can do this daily. If you feel you want to keep your files longer, maybe a month, you can tweak around to accomplish that. Maybe I will update this posting with my own solution for that, although in my case I do not need it.
(Edit: this posting is now in the official rear user documentation, which is kinda cool)
(Edit 2: people keep asking me how to make incremental backups with ReaR, so I inserted my /etc/rear/local.conf above)
Je hebt een normale baan, en je vervoermiddel is toevallig een Mercedes … (/me)
Dan ben je volgens GeenStijl / reaguurder:
After being ill for over a week I was out of the house last afternoon to inspect my Trachycarpus Fortunei palm tree, which had to endure snow, ice, and freezing rain lately.
The result of all that harsh weather is somewhat awkward ..
Pretty cool, and it will survive 🙂
You shouldn’t have done this. Barriers are never too high.
But since this happened, there is no way back. I will never know your reasons.
The only thing left for me to do is to keep using Debian, and think about you every time I login.
Thanks for everything you brought to the world. Debian, open source, and you, in my memories for ever.
Your name will always be there, in deb-ian.
You ruled man, we will miss you very bad.
I am installing Debian a lot, and with every fresh install comes this:
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Someone should fix that 🙂
sudo nano /etc/environment
and add the following:
Or any locale you wan to use. Reboot, and all is fine again.
Just a little manual 🙂
Assuming that you have Ispconfig3 with postfix installed, it’s very easy to get rid of spam that passes your filters, despite the fact that Ispconfig has a anti-spam engine onboard.
I am on Debian 8 (Jessie) b.t.w.
– Login as root and
apt-get update && apt-get install postgrey
Postgrey add’s a delay on your maildelivery, but only for hosts that are new to your server. The default is 300 seconds, but you can safely shorten that to 60 or less because the spamming server might never retry because it won’t get a the greylist command 🙂
Please note that the number “10023” is the port on which postrey runs, it may differ on your installation. Keep that number in mind because you need it in a minute.
add –delay=60 to this line: POSTGREY_OPTS=”–inet=127.0.0.1:10023″ It will look like this: POSTGREY_OPTS=”–inet=127.0.0.1:10023 –delay=60″
service postgrey start
and add check_policy_service inet:127.0.0.1:10023 to the smtpd_recipient_restrictions.
Mine looks like this:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,check_policy_service inet:127.0.0.1:10023
You might want to see it working, you can do so by issuing the following command:
tail -f /var/log/mail.log | grep greylist
Output looks like this:
root@server /var/log # tail -f mail.log | grep greylist
Dec 21 12:30:31 server postgrey: action=greylist, reason=new, client_name=unknown, client_address=22.214.171.124, recipient=[redacted]
Enjoy, spam is something from the past.