There are lots of great backup tools and utilities out there, but utilizing a simple script and cron task to target specific PostgreSQL database is often the fastest way to a locally based backup procedure.
The below shell script is run as the postgres user on a Linux version 2.6.9-42.0.3.ELsmp (Red Hat 3.4.6-3) with PostgreSQL 8.2.0 that has support for command-line execution. Not that there is anything fancy in the code that would require such specific versions.
Unique to the code is the ability to pass in a database name, or none at all to backup the entire cluster. This code only connects and writes files locally. Assumes appropriate permissions given to executing user. Maybe this works just fine for you, otherwise feel free to make your own modifications.
Personally I gzip the output, but improvements could be made to prevent hard disk saturation on larger databases and archiving utilities.
crontab
# CRON table for postgres user. # run backup every night at 22:00 hours (10PM) 0 22 * * * /var/lib/pgsql/backups/backup.sh database_name # run backup every week at midnight hour on sunday 0 0 * * 0 /var/lib/pgsql/backups/backup.sh
backup.sh
#!/bin/bash # This script will backup the postgresql database # and store it in a specified directory # PARAMETERS # $1 database name (if none specified run pg_dumpall) # CONSTANTS # postgres home folder backups directory # !! DO NOT specify trailing '/' as it is included below for readability !! BACKUP_DIRECTORY="/var/lib/pgsql/backups" # Date stamp (formated YYYYMMDD) # just used in file name CURRENT_DATE=$(date "+%Y%m%d") # !!! Important pg_dump command does not export users/groups tables # still need to maintain a pg_dumpall for full disaster recovery !!! # this checks to see if the first command line argument is null if [ -z "$1" ] then # No database specified, do a full backup using pg_dumpall pg_dumpall | gzip - > $BACKUP_DIRECTORY/pg_dumpall_$CURRENT_DATE.sql.gz else # Database named (command line argument) use pg_dump for targed backup pg_dump $1 | gzip - > $BACKUP_DIRECTORY/$1_$CURRENT_DATE.sql.gz fi
Use 4D header macro to identify code blocks
June 2, 2011 by James
Standard installation of 4Dv11 comes with a set of macros to use in design mode.
The one I find most useful is the
Headermacro. This macro takes my name, date time stamp, the method name and places it directly into whatever type of method I’m working in.Most analogous to function/class/package documentation blocks in other languages, they are also an excellent starting point for other developers looking at your code. In 4D specifically, header blocks also serve as insurance against a corrupted structure file.
After repairing a corrupted structure file,
orphan method(s)can appear without context. The orphan methods are not linked to the original code, and the type of method (object/form/project) and original method name are lost.Worse, the repair process could have replaced the original code in it’s entirety with a comment “
automatically repaired method“.The
method_nametag of the macro generates the text as shown in the title portion of the method editor. So a project method will renderMethod: Project_Methodwhile form and object methods will renderMethod: Form Method [Table]FormandMethod: Object Method [Table].Form.Objectrespectively.A header documents all the missing information to find the original code location and the confidence to delete or restore the orphan code. Having the headers in place has definitely saved me lots of time analyzing and recovering from a structure corruption.
Example Macro
Note The above macro is formatted for v11. 4D v12 has
//for commenting out linesA tech tip on creating header content automatically.
4D Tech Tip – Header Macro
Share this:
Posted in 4D | Tagged 4D, auto-comment, automatically repaired method, clean code, corrupt, macro, method header, orphan method, structure | Leave a Comment »