KOMPAS.com - Indonesia baru saja merdeka, Belanda ingkar janji. Suara bom pesawat Belanda mengagetkan Panglima Besar Jenderal Sudirman yang dirawat di Rumah Sakit Panti Rapih. Anak buahnya mencoba menenangkan Sudirman, "Itu hanya anak-anak yang sedang latihan perang."
Sudirman baru saja kehilangan satu paru-parunya di meja operasi. Rasa sakit masih menyiksa. Akan tetapi, instingnya sebagai ahli taktik perang berkata, ada yang tidak beres. Sadar negara dalam keadaan genting, Sudirman menemui Presiden Soekarno di Istana Gedung Agung, Yogyakarta.
Di hadapan Soekarno, Sudirman minta izin memulai gerilya untuk menghancurkan mental Belanda. Kala itu, Soekarno melarang, "Kang Mas sedang sakit, lebih baik tinggal di kota". Sudirman menyahut, "Yang sakit Sudirman, Panglima Besar tidak pernah sakit."
Jawaban Sudirman sebelum memulai perang gerilya itu kini dituliskan pada mural berlatar belakang bendera Merah Putih di Museum Pusat TNI Angkatan Darat Dharma Wiratama. Menurut Kepala Seksi Pemandu dan Pameran Museum Mayor Riko Sahani, bangunan museum ini dulunya merupakan markas besar Tentara Keamanan Rakyat (TKR) saat perang kemerdekaan.
Keterbatasan fisik tak menyurutkan niat Sudirman memimpin perang gerilya. Bertolak dari rumah dinasnya di kawasan Bintaran yang kini jadi Museum Panglima Besar Jenderal Sudirman, satu kompi pasukan (80 tentara) dibawa. Demi keamanan, keluarganya dititipkan di lingkungan Keraton Yogyakarta.
Lahir
Sesaat setelah merdeka, Indonesia yang baru lahir mendapat cobaan bertubi-tubi. Pemberontakan pecah di mana-mana, tentara sekutu yang diboncengi Belanda kembali menancapkan kuku penjajahannya. Di tengah kekacauan itulah, rantai komando perang lahir dari Yogyakarta.
Berawal dari inisiatif Letnan Jenderal Urip Sumoharjo yang melontarkan keprihatinan "alangkah lucunya negara tanpa tentara" maka dibentuk TKR yang menjadi cikal bakal lahirnya Tentara Nasional Indonesia. Melalui konferensi besar TKR pada 12 November 1945, untuk pertama kalinya, Indonesia memiliki pucuk pimpinan tertinggi angkatan perang.
Setelah mengusir tentara sekutu di Ambarawa pada Oktober 1945, Kolonel Sudirman dilantik menjadi Pimpinan Tertinggi TKR, sedangkan Urip Sumoharjo menjadi Kepala Staf Umum yang meletakkan dasar organisasi TNI. Pelantikan dilaksanakan pada 18 Desember 1945.
Dari markas besar TKR di Yogyakarta, terpancar kesatuan komando ke seluruh Tanah Air dalam mempertahankan kemerdekaan yang mulai terancam tentara Belanda maupun pemberontakan dari dalam negeri. Perang di bawah rantai komando Sudirman, antara lain, adalah perang atau palagan di Bandung yang dikenal sebagai Bandung Lautan Api. Bandung dibumihanguskan saat melawan sekutu dan Belanda November 1945-24 Maret 1946.
Perang lain di bawah komando markas besar TKR di Yogyakarta adalah Palagan Surabaya di bawah pimpinan Bung Tomo yang kini diperingati sebagai Hari Pahlawan 10 November. Beberapa kali pemberontakan mulai dari PKI Muso di Madiun, DI/TII di Jawa Tengah, hingga RMS di Maluku berhasil dipadamkan.
Selama perang gerilya Desember 1948-10 Juli 1949, Sudirman juga memegang rantai komando untuk serangan umum 1 Maret 1949 yang dipimpin Letnan Kolonel Soeharto.
Melalui serangan umum, tentara berhasil menguasai kembali Yogyakarta selama enam jam. Dunia menyaksikan, Indonesia masih ada dan PBB mendesak Belanda membuka jalan perundingan melalui Konferensi Meja Bundar yang berisi pengakuan terhadap kedaulatan Indonesia.
Meski tidak banyak meninggalkan catatan di wilayah yang dilintasi seperti di Bantul, perjalanan gerilya Sudirman menjadi spirit tersendiri bagi masyarakat. "Semangat dan kegigihannya tetap berjuang meski sakit seharusnya terus diteladani," ujar Kepala Dinas Kebudayaan dan Pariwisata Bantul Suyoto. (ENY/WKM)
Tuesday, August 24, 2010
Thursday, August 19, 2010
PITR postgresql
If the standard methods can't be used (for ex, if the database is too big for a complete dump), another method can be used: WAL archiving.
This page describes how to use WAL archiving and PITR on an example database.
Backup ¶
The setup procedure is the following:
* Configure PITR recovery by defining an archive_command
* Restart the cluster to start WAL archiving
To make a backup:
* Connect to the database and run the pg_start_backup('label') function
* Backup the entire cluster (without stopping it)
* Connect to the database and run the pg_stop_backup() function
(Intro) WAL files ¶
At all times, postgresql maintains a WAL (write-ahead log) in the pg_xlog subdirectory of the cluster. These files are primarily used for crash-safety purposes: each operation on the database is logged in a WAL file (with a default limit of 16 MB). By default, WAL files are recycled. However, if postgresql is configured to continuously log all operations, these files can be used for backups, acting exactly like incremental backups. This has some benefits:
* Backups does not need to be perfectly consistent: you need a backup of the cluster, and some WAL files
* A complete dump of the database is not needed
* Incremental
* Continuous
* Point in time recovery: it is possible to restore the database at its state at any time since the backup
However, there are some drawbacks:
* Additional complexity
* Needs lots of space on disk
* More writes on disk (can impact performance)
* Works on the entire cluster
PITR is generally not needed: you should prefer using dumps when possible. PITR can be used for large databases, continuous backups, or high-availability.
Before trying to use PITR, you should practise, and test on a non-critical database.
Enabling WAL archiving ¶
We will configure postgresql to archive WAL files when they are complete, instead of recycling them.
(Option) Creating a test cluster ¶
Since we don't want to crash our production server, we'll create a test cluster.
# mkdir /bigstuff/pgPITR
# chown postgres:postgres /bigstuff/pgPITR
# su - postgres
$ export PGDATA=/bigstuff/pgPITR
$ /usr/lib/postgresql/8.2/bin/initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
fixing permissions on existing directory /bigstuff/pgPITR ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /bigstuff/pgPITR/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.
Success. You can now start the database server using:
/usr/lib/postgresql/8.2/bin/postgres -D /bigstuff/pgPITR
or
/usr/lib/postgresql/8.2/bin/pg_ctl -D /bigstuff/pgPITR -l logfile start
Add archive_command ¶
Edit your configuration file to add archive_command. This command can do anything you want (from a simple copy to a complex script), just remember to return 0.
For our test, we will copy files to a directory in /tmp. Stop the server, and edit the configuration:
$ vi $PGDATA/postgresql.conf
archive_command = 'cp %p /tmp/wals/%f'
Restart the server.
PostgreSQL will now work as usuel, creating WAL files in its pg_xlog subdirectory. However, when they are complete, it will copy them to the /tmp/wals/ directory.
(Option) Create a test database ¶
$ /usr/lib/postgresql/8.2/bin/pg_ctl -l /tmp/pg.log start
server starting
$ createdb test
CREATE DATABASE
$ psql test
[...]
test=# BEGIN WORK;
BEGIN
test=# CREATE TABLE dummy1 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
test=# select pg_size_pretty(pg_relation_size('dummy1'));
pg_size_pretty
----------------
97 MB
(1 row)
test=# \q
At this point, PostgreSQL should have archiving some files:
$ ls -al /tmp/wals/
total 98402
drwxr-xr-x 2 postgres postgres 288 Jan 6 15:00 .
drwxrwxrwt 24 root root 2304 Jan 6 14:59 ..
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 000000010000000000000009
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000A
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000B
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000C
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000E
Backup the cluster ¶
You need to backup the cluster directory. You can use any method you want (tar, cpio, bacula, etc). to backup the cluster directory ($PGDATA).
Note: you don't need to stop the cluster or take extra precautions.
For our example, we'll just create a tar archive. Before doing so, we just need to inform postgresql that we will create a backup using the command pg_start_backup.
$ psql test
[...]
test=# SELECT pg_start_backup('full backup');
pg_start_backup
-----------------
0/F74F118
(1 row)
test=# \q
$ tar -cvzf /tmp/pgdata.tgz $PGDATA
$ psql test
[...]
test=# SELECT pg_stop_backup();
pg_stop_backup
----------------
0/F74F118
(1 row)
test=# \q
The argument of pg_start_backup is simply a label that helps you. This will be stored in file $PGDATA_backup_label.
(option) create some tables ¶
Create one more table:
test=# BEGIN;
BEGIN
test=# CREATE TABLE dummy2 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
If you want to test PITR, create a table dummy3:
test=# BEGIN;
BEGIN
test=# CREATE TABLE dummy3 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
test=# BEGIN;
BEGIN
wait some time (remember the exact time !), then drop it:
test=# DROP TABLE dummy3;
DROP TABLE
test=# COMMIT;
COMMIT
test=# \q
(option) simulate disaster ¶
.. or just wait for it to happen ..
Here, we'll just kill brutally the server:
$ kill -9 $(head -1 $PGDATA/postmaster.pid)
Recovery ¶
At this point, your database must be stopped.
The procedure is the following:
* If possible, get data from the damaged cluster
* Restore the complete cluster backup from the archive
* Clean up the restored cluster (remove pg_xlog files and the pid file)
* If possible, copy WAL files from the damaged cluster to the restored cluster
* Create the $PGDATA/recovery.conf file
* Start the cluster
* Watch the logs, then verify the restored data
Old cluster ¶
First, we need to try to recover data from the old cluster. If it is not possible, you will still be able to recover data from you backup, but you will maybe lost data from the most recent (unarchived) WAL file.
Here, we will just rename it:
$ mv $PGDATA $PGDATA.old
Restore the cluster ¶
Restore the cluster using your favorite method.
For our example, we'll use the tar archive:
$ (cd / && tar xvzf /tmp/pgdata.tgz)
$ chmod 0700 $PGDATA
Clean up the restored directory:
$ rm $PGDATA/pg_xlog/0*
$ rm $PGDATA/postmaster.pid
Restore WAL files from the old cluster ¶
If available, you can copy the WAL files from the pg_xlog subdirectory of the damaged cluster:
$ cp -a $PGDATA.old/pg_xlog $PGDATA/
Create a recovery file ¶
Create a new file $PGDATA/recovery.conf. The only required line is restore_command:
restore_command = 'cp /tmp/wals/%f %p'
recovery_target_time = '2008-01-06 15:18:00 CET'
The recovery target time allows you to recover the most recent data (if you do not specify recovery_target_time) or at a precise time.
If you removed WAL files after archiving them from the directory (/tmp/wals), you should restore them as well.
Start the database, and witness the miracle ¶
Start the database:
$ /usr/lib/postgresql/8.2/bin/pg_ctl -l /tmp/pg.log start
server starting
PostgreSQL will detect the file recovery.conf, and start automatic recovery:
$ tail -f /tmp/pg.log
LOG: database system was interrupted at 2008-01-06 15:01:57 CET
LOG: starting archive recovery
LOG: restore_command = "cp /tmp/wals/%f %p"
LOG: recovery_target_time = 2008-01-06 15:31:00+01
cp: cannot stat `/tmp/wals/00000001.history': No such file or directory
LOG: restored log file "00000001000000000000000F.0074F118.backup" from archive
LOG: restored log file "00000001000000000000000F" from archive
LOG: checkpoint record is at 0/F74F118
LOG: redo record is at 0/F74F118; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 0/618; next OID: 24582
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: automatic recovery in progress
LOG: redo starts at 0/F74F168
LOG: restored log file "000000010000000000000010" from archive
LOG: restored log file "000000010000000000000011" from archive
LOG: restored log file "000000010000000000000012" from archive
LOG: restored log file "000000010000000000000013" from archive
LOG: restored log file "000000010000000000000014" from archive
LOG: restored log file "000000010000000000000015" from archive
LOG: restored log file "000000010000000000000016" from archive
LOG: restored log file "000000010000000000000017" from archive
LOG: restored log file "000000010000000000000018" from archive
LOG: restored log file "000000010000000000000019" from archive
LOG: restored log file "00000001000000000000001A" from archive
LOG: restored log file "00000001000000000000001B" from archive
LOG: restored log file "00000001000000000000001C" from archive
cp: cannot stat `/tmp/wals/00000001000000000000001D': No such file or directory
LOG: could not open file "pg_xlog/00000001000000000000001D" (log file 0, segment 29): No such file or directory
LOG: redo done at 0/1CFFFD70
LOG: restored log file "00000001000000000000001C" from archive
LOG: archive recovery complete
LOG: database system is ready
If you specified the correct recovery_target_time, you will be able to restore your database just at the moment before dropping the table dummy3:
test=# \d
List of relations
Schema | Name | Type | Owner
--------+--------+-------+----------
public | dummy1 | table | postgres
public | dummy2 | table | postgres
public | dummy3 | table | postgres
(3 rows)
After recovery, PostgreSQL will rename recovery.conf to recovery.done.
This page describes how to use WAL archiving and PITR on an example database.
Backup ¶
The setup procedure is the following:
* Configure PITR recovery by defining an archive_command
* Restart the cluster to start WAL archiving
To make a backup:
* Connect to the database and run the pg_start_backup('label') function
* Backup the entire cluster (without stopping it)
* Connect to the database and run the pg_stop_backup() function
(Intro) WAL files ¶
At all times, postgresql maintains a WAL (write-ahead log) in the pg_xlog subdirectory of the cluster. These files are primarily used for crash-safety purposes: each operation on the database is logged in a WAL file (with a default limit of 16 MB). By default, WAL files are recycled. However, if postgresql is configured to continuously log all operations, these files can be used for backups, acting exactly like incremental backups. This has some benefits:
* Backups does not need to be perfectly consistent: you need a backup of the cluster, and some WAL files
* A complete dump of the database is not needed
* Incremental
* Continuous
* Point in time recovery: it is possible to restore the database at its state at any time since the backup
However, there are some drawbacks:
* Additional complexity
* Needs lots of space on disk
* More writes on disk (can impact performance)
* Works on the entire cluster
PITR is generally not needed: you should prefer using dumps when possible. PITR can be used for large databases, continuous backups, or high-availability.
Before trying to use PITR, you should practise, and test on a non-critical database.
Enabling WAL archiving ¶
We will configure postgresql to archive WAL files when they are complete, instead of recycling them.
(Option) Creating a test cluster ¶
Since we don't want to crash our production server, we'll create a test cluster.
# mkdir /bigstuff/pgPITR
# chown postgres:postgres /bigstuff/pgPITR
# su - postgres
$ export PGDATA=/bigstuff/pgPITR
$ /usr/lib/postgresql/8.2/bin/initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
fixing permissions on existing directory /bigstuff/pgPITR ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /bigstuff/pgPITR/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.
Success. You can now start the database server using:
/usr/lib/postgresql/8.2/bin/postgres -D /bigstuff/pgPITR
or
/usr/lib/postgresql/8.2/bin/pg_ctl -D /bigstuff/pgPITR -l logfile start
Add archive_command ¶
Edit your configuration file to add archive_command. This command can do anything you want (from a simple copy to a complex script), just remember to return 0.
For our test, we will copy files to a directory in /tmp. Stop the server, and edit the configuration:
$ vi $PGDATA/postgresql.conf
archive_command = 'cp %p /tmp/wals/%f'
Restart the server.
PostgreSQL will now work as usuel, creating WAL files in its pg_xlog subdirectory. However, when they are complete, it will copy them to the /tmp/wals/ directory.
(Option) Create a test database ¶
$ /usr/lib/postgresql/8.2/bin/pg_ctl -l /tmp/pg.log start
server starting
$ createdb test
CREATE DATABASE
$ psql test
[...]
test=# BEGIN WORK;
BEGIN
test=# CREATE TABLE dummy1 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
test=# select pg_size_pretty(pg_relation_size('dummy1'));
pg_size_pretty
----------------
97 MB
(1 row)
test=# \q
At this point, PostgreSQL should have archiving some files:
$ ls -al /tmp/wals/
total 98402
drwxr-xr-x 2 postgres postgres 288 Jan 6 15:00 .
drwxrwxrwt 24 root root 2304 Jan 6 14:59 ..
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 000000010000000000000009
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000A
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000B
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000C
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 Jan 6 15:00 00000001000000000000000E
Backup the cluster ¶
You need to backup the cluster directory. You can use any method you want (tar, cpio, bacula, etc). to backup the cluster directory ($PGDATA).
Note: you don't need to stop the cluster or take extra precautions.
For our example, we'll just create a tar archive. Before doing so, we just need to inform postgresql that we will create a backup using the command pg_start_backup.
$ psql test
[...]
test=# SELECT pg_start_backup('full backup');
pg_start_backup
-----------------
0/F74F118
(1 row)
test=# \q
$ tar -cvzf /tmp/pgdata.tgz $PGDATA
$ psql test
[...]
test=# SELECT pg_stop_backup();
pg_stop_backup
----------------
0/F74F118
(1 row)
test=# \q
The argument of pg_start_backup is simply a label that helps you. This will be stored in file $PGDATA_backup_label.
(option) create some tables ¶
Create one more table:
test=# BEGIN;
BEGIN
test=# CREATE TABLE dummy2 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
If you want to test PITR, create a table dummy3:
test=# BEGIN;
BEGIN
test=# CREATE TABLE dummy3 AS SELECT * FROM pg_class, pg_attribute;
SELECT
test=# COMMIT;
COMMIT
test=# BEGIN;
BEGIN
wait some time (remember the exact time !), then drop it:
test=# DROP TABLE dummy3;
DROP TABLE
test=# COMMIT;
COMMIT
test=# \q
(option) simulate disaster ¶
.. or just wait for it to happen ..
Here, we'll just kill brutally the server:
$ kill -9 $(head -1 $PGDATA/postmaster.pid)
Recovery ¶
At this point, your database must be stopped.
The procedure is the following:
* If possible, get data from the damaged cluster
* Restore the complete cluster backup from the archive
* Clean up the restored cluster (remove pg_xlog files and the pid file)
* If possible, copy WAL files from the damaged cluster to the restored cluster
* Create the $PGDATA/recovery.conf file
* Start the cluster
* Watch the logs, then verify the restored data
Old cluster ¶
First, we need to try to recover data from the old cluster. If it is not possible, you will still be able to recover data from you backup, but you will maybe lost data from the most recent (unarchived) WAL file.
Here, we will just rename it:
$ mv $PGDATA $PGDATA.old
Restore the cluster ¶
Restore the cluster using your favorite method.
For our example, we'll use the tar archive:
$ (cd / && tar xvzf /tmp/pgdata.tgz)
$ chmod 0700 $PGDATA
Clean up the restored directory:
$ rm $PGDATA/pg_xlog/0*
$ rm $PGDATA/postmaster.pid
Restore WAL files from the old cluster ¶
If available, you can copy the WAL files from the pg_xlog subdirectory of the damaged cluster:
$ cp -a $PGDATA.old/pg_xlog $PGDATA/
Create a recovery file ¶
Create a new file $PGDATA/recovery.conf. The only required line is restore_command:
restore_command = 'cp /tmp/wals/%f %p'
recovery_target_time = '2008-01-06 15:18:00 CET'
The recovery target time allows you to recover the most recent data (if you do not specify recovery_target_time) or at a precise time.
If you removed WAL files after archiving them from the directory (/tmp/wals), you should restore them as well.
Start the database, and witness the miracle ¶
Start the database:
$ /usr/lib/postgresql/8.2/bin/pg_ctl -l /tmp/pg.log start
server starting
PostgreSQL will detect the file recovery.conf, and start automatic recovery:
$ tail -f /tmp/pg.log
LOG: database system was interrupted at 2008-01-06 15:01:57 CET
LOG: starting archive recovery
LOG: restore_command = "cp /tmp/wals/%f %p"
LOG: recovery_target_time = 2008-01-06 15:31:00+01
cp: cannot stat `/tmp/wals/00000001.history': No such file or directory
LOG: restored log file "00000001000000000000000F.0074F118.backup" from archive
LOG: restored log file "00000001000000000000000F" from archive
LOG: checkpoint record is at 0/F74F118
LOG: redo record is at 0/F74F118; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 0/618; next OID: 24582
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: automatic recovery in progress
LOG: redo starts at 0/F74F168
LOG: restored log file "000000010000000000000010" from archive
LOG: restored log file "000000010000000000000011" from archive
LOG: restored log file "000000010000000000000012" from archive
LOG: restored log file "000000010000000000000013" from archive
LOG: restored log file "000000010000000000000014" from archive
LOG: restored log file "000000010000000000000015" from archive
LOG: restored log file "000000010000000000000016" from archive
LOG: restored log file "000000010000000000000017" from archive
LOG: restored log file "000000010000000000000018" from archive
LOG: restored log file "000000010000000000000019" from archive
LOG: restored log file "00000001000000000000001A" from archive
LOG: restored log file "00000001000000000000001B" from archive
LOG: restored log file "00000001000000000000001C" from archive
cp: cannot stat `/tmp/wals/00000001000000000000001D': No such file or directory
LOG: could not open file "pg_xlog/00000001000000000000001D" (log file 0, segment 29): No such file or directory
LOG: redo done at 0/1CFFFD70
LOG: restored log file "00000001000000000000001C" from archive
LOG: archive recovery complete
LOG: database system is ready
If you specified the correct recovery_target_time, you will be able to restore your database just at the moment before dropping the table dummy3:
test=# \d
List of relations
Schema | Name | Type | Owner
--------+--------+-------+----------
public | dummy1 | table | postgres
public | dummy2 | table | postgres
public | dummy3 | table | postgres
(3 rows)
After recovery, PostgreSQL will rename recovery.conf to recovery.done.
Friday, August 6, 2010
PROFESIONALISME TNI DALAM MENGATASI KONFLIK LAF DAN IDF DI LEBANON SELATAN
PROFESIONALISME TNI DALAM MENGATASI KONFLIK LAF DAN IDF DI LEBANON SELATAN
06 Agu 2010
PUSPEN (6/8),- Prajurit Satgas Yon Mekanis Kontingen Garuda XXIII-D/Unifil (Indobatt) dengan sigap bertindak profesional dan imparsial dalam mengemban tugas serta tanggung jawabnya selaku Peacekeeper saat terjadi ketegangan antara IDF (Israeli Defence Forces) dan LAF (Lebanese Armed Forces) di salah satu Observation Post (OP) di daerah Al-Adaisse yang terkenal dengan sebutan ”Panorama Point” dan masih dalam Area of Responsibility (AOR) Indobatt di Lebanon Selatan, Selasa (3/8).
Menurut Komandan Satuan Tugas Batalyon Mekanis Kontingen Garuda XXIII-D/Unifil (Indonesian Battalion/Indobatt), Letkol Inf Andi Perdana Kahar, tindakan menengahi yang sangat berani dilakukan oleh prajurit TNI berawal dari rencana kegiatan pemotongan batang pohon cemara yang tumbang dan mengenai pagar/Technical Fence oleh pihak IDF (Israeli Defence Forces). Kegiatan IDF ini tidak disetujui LAF (Lebanese Armed Forces) dan mendapat tentangan, karena menurut LAF pohon tersebut berada di wilayah negaranya. Walaupun kegiatan ini telah dipantau dan mendapatkan ijin dari UNIFIL (United Nations Interim Force In Lebanon) selaku pemegang mandat pemelihara perdamaian di wilayah Lebanon Selatan, namun pada kenyataannya kegiatan IDF di lapangan ini mendapatkan tentangan yang sangat keras dari LAF serta memicu ketegangan antara kedua belah pihak.
Lebih lanjut Komandan Indobatt menyatakan, sebagai pasukan penjaga perdamaian, Kompi A Indobatt telah melakukan segala upaya prosedural se-maksimal mungkin untuk meredakan situasi. Upaya negosiasi kedua pihak di lapangan yang dimediasi oleh Indobatt dan Liaison Officer (LO) dari markas UNIFIL, telah dilakukan selama kurang lebih 4 (empat) jam. Demi meredakan ketegangan yang terjadi, Danki A Indobatt Kapten Inf Fardin Wardhana mengambil resiko meloncati pagar pengaman jalan, kemudian turun mendekat ke area Blue-Line yang belum sepenuhnya bersih oleh ranjau (UXO), dengan mengibar-ngibarkan bendera PBB dan berdiri di tengah-tengah kedua belah pihak yang sedang berhadap-hadapan dengan bersenjata lengkap (pointing). Bukan hanya itu saja, anggota Tim Kompi A Indobatt yang saat itu berjaga-jaga di Observation Post (OP) tersebut, seluruhnya membantu dengan mengibarkan bendera sambil mengangkat tangan serta meminta kepada kedua pihak agar dapat menahan diri dan dapat mencari kata sepakat mengenai pemotongan pohon cemara tersebut.
Menurut keterangan yang diperoleh dari saksi mata Lettu Inf Arief Widyanto, selaku Perwira Force Protection Indobatt yang saat itu berada di tempat kejadian, dijelaskan bahwa situasi menjadi makin menegangkan dan sangat tidak terkendali saat salah satu pihak melepaskan tembakan. Tembakan tersebut selanjutnya memicu terjadinya kontak tembak antara IDF dan LAF. Sesuai prosedur, prajurit Indobatt melakukan tindakan taktis mencari tempat perlindungan di sekitar lokasi kejadian saat terjadi baku tembak antara LAF dan IDF. Sesuai dengan perintah Komando, prajurit Indobatt kemudian melaksanakan pengunduran diri mencari posisi berlindung yang aman dan menunggu perintah lebih lanjut. Baku tembak ini melibatkan dua pesawat Heli Apache dan 3 (tiga) Tank ”Markava” IDF, yang melepaskan tembakan ke arah kedudukan pasukan LAF.
Situasi pertempuran yang makin hebat dan membahayakan personel Unifil dalam hal ini Indobatt, memaksa Markas Komando Sektor Timur Unifil mengambil keputusan dan memerintahkan Komandan Indobatt untuk menarik personel Indobatt yang berada di lokasi kontak tembak ke posisi yang lebih aman sambil tetap memonitor keadaan. Dalam proses penarikan pasukan tersebut, personel Kompi A Indobatt terpecah menjadi dua kelompok yang terpisah satu sama lain karena gencarnya tembakan yang dikeluarkan oleh kedua pihak dalam pertempuran tersebut. Satu kelompok ke arah Al-Adaisse dan kelompok yang lain ke arah Kafer Kela. Dari hasil pengecekan personel, didapati masih ada dua personel yang belum diketahui keberadaannya dan putus kontak dengan induk pasukan.
Selama satu jam lebih, keberadaan dua prajurit tersebut ternyata masih berada di lokasi peristiwa kontak senjata. Kedua prajurit Indobatt ini, terjebak dalam kontak senjata kedua belah pihak dan hanya bisa berlindung di balik bangunan tanpa dapat malakukan pengunduran dari daerah pertempuran. Setelah kontak tembak sedikit mereda Kopda Zulkarnain dan Praka Oksa berusaha mencari pasukan kawan ke arah Kafer Kela yang merupakan Area of Responsibility (AoR) Spain Battalion. Kedua prajurit ini tidak bertemu dengan satupun anggota Peacekeeper yang diharapkan berada di pos pengamatan Spainbatt, karena telah ditarik mundur oleh Komando Atas.
Dari keterangan kedua prajurit tersebut, mereka memutuskan untuk menuju ke arah Fatima Gate, persimpangan jalan dimana terdapat OP (Observation Post) Spainbatt lainnya. Sama seperti kejadian pada pos sebelumnya, mereka tidak menemukan satupun anggota UN yang siaga di tempat tersebut. Dalam keadaan putus hubungan komunikasi dengan pasukan induk serta tanpa mengetahui situasi terakhir, mereka menerima bantuan salah satu masyarakat Lebanon yang bersedia mengantarkannya ke markas Indobatt UN Posn 7-1 desa Adshit Al-Qusayr yang berjarak 15 Km dari Fatima-Gate.
Dari peristiwa kontak tembak antara LAF dan IDF telah jatuh korban dari kedua belah pihak. Dari pihak Lebanon, tiga anggota LAF dan satu orang jurnalis AL-Akhbar Lebanese tewas di tempat. Sedangkan dari pihak IDF, dua orang Perwiranya menjadi korban dan meninggal dunia. Untuk pihak Indobatt sendiri, tidak ada kerugian personel maupun material. Hal ini dikarenakan kesigapan prajurit Indobatt dalam melaksanakan tindakan pengunduran pasukan sesuai dengan STIR (Standardize Tactical Incident Reaction) yang dilakukan berdasarkan perintah Komando Atas dalam hal ini oleh Sektor Timur UNIFIL.
06 Agu 2010
PUSPEN (6/8),- Prajurit Satgas Yon Mekanis Kontingen Garuda XXIII-D/Unifil (Indobatt) dengan sigap bertindak profesional dan imparsial dalam mengemban tugas serta tanggung jawabnya selaku Peacekeeper saat terjadi ketegangan antara IDF (Israeli Defence Forces) dan LAF (Lebanese Armed Forces) di salah satu Observation Post (OP) di daerah Al-Adaisse yang terkenal dengan sebutan ”Panorama Point” dan masih dalam Area of Responsibility (AOR) Indobatt di Lebanon Selatan, Selasa (3/8).
Menurut Komandan Satuan Tugas Batalyon Mekanis Kontingen Garuda XXIII-D/Unifil (Indonesian Battalion/Indobatt), Letkol Inf Andi Perdana Kahar, tindakan menengahi yang sangat berani dilakukan oleh prajurit TNI berawal dari rencana kegiatan pemotongan batang pohon cemara yang tumbang dan mengenai pagar/Technical Fence oleh pihak IDF (Israeli Defence Forces). Kegiatan IDF ini tidak disetujui LAF (Lebanese Armed Forces) dan mendapat tentangan, karena menurut LAF pohon tersebut berada di wilayah negaranya. Walaupun kegiatan ini telah dipantau dan mendapatkan ijin dari UNIFIL (United Nations Interim Force In Lebanon) selaku pemegang mandat pemelihara perdamaian di wilayah Lebanon Selatan, namun pada kenyataannya kegiatan IDF di lapangan ini mendapatkan tentangan yang sangat keras dari LAF serta memicu ketegangan antara kedua belah pihak.
Lebih lanjut Komandan Indobatt menyatakan, sebagai pasukan penjaga perdamaian, Kompi A Indobatt telah melakukan segala upaya prosedural se-maksimal mungkin untuk meredakan situasi. Upaya negosiasi kedua pihak di lapangan yang dimediasi oleh Indobatt dan Liaison Officer (LO) dari markas UNIFIL, telah dilakukan selama kurang lebih 4 (empat) jam. Demi meredakan ketegangan yang terjadi, Danki A Indobatt Kapten Inf Fardin Wardhana mengambil resiko meloncati pagar pengaman jalan, kemudian turun mendekat ke area Blue-Line yang belum sepenuhnya bersih oleh ranjau (UXO), dengan mengibar-ngibarkan bendera PBB dan berdiri di tengah-tengah kedua belah pihak yang sedang berhadap-hadapan dengan bersenjata lengkap (pointing). Bukan hanya itu saja, anggota Tim Kompi A Indobatt yang saat itu berjaga-jaga di Observation Post (OP) tersebut, seluruhnya membantu dengan mengibarkan bendera sambil mengangkat tangan serta meminta kepada kedua pihak agar dapat menahan diri dan dapat mencari kata sepakat mengenai pemotongan pohon cemara tersebut.
Menurut keterangan yang diperoleh dari saksi mata Lettu Inf Arief Widyanto, selaku Perwira Force Protection Indobatt yang saat itu berada di tempat kejadian, dijelaskan bahwa situasi menjadi makin menegangkan dan sangat tidak terkendali saat salah satu pihak melepaskan tembakan. Tembakan tersebut selanjutnya memicu terjadinya kontak tembak antara IDF dan LAF. Sesuai prosedur, prajurit Indobatt melakukan tindakan taktis mencari tempat perlindungan di sekitar lokasi kejadian saat terjadi baku tembak antara LAF dan IDF. Sesuai dengan perintah Komando, prajurit Indobatt kemudian melaksanakan pengunduran diri mencari posisi berlindung yang aman dan menunggu perintah lebih lanjut. Baku tembak ini melibatkan dua pesawat Heli Apache dan 3 (tiga) Tank ”Markava” IDF, yang melepaskan tembakan ke arah kedudukan pasukan LAF.
Situasi pertempuran yang makin hebat dan membahayakan personel Unifil dalam hal ini Indobatt, memaksa Markas Komando Sektor Timur Unifil mengambil keputusan dan memerintahkan Komandan Indobatt untuk menarik personel Indobatt yang berada di lokasi kontak tembak ke posisi yang lebih aman sambil tetap memonitor keadaan. Dalam proses penarikan pasukan tersebut, personel Kompi A Indobatt terpecah menjadi dua kelompok yang terpisah satu sama lain karena gencarnya tembakan yang dikeluarkan oleh kedua pihak dalam pertempuran tersebut. Satu kelompok ke arah Al-Adaisse dan kelompok yang lain ke arah Kafer Kela. Dari hasil pengecekan personel, didapati masih ada dua personel yang belum diketahui keberadaannya dan putus kontak dengan induk pasukan.
Selama satu jam lebih, keberadaan dua prajurit tersebut ternyata masih berada di lokasi peristiwa kontak senjata. Kedua prajurit Indobatt ini, terjebak dalam kontak senjata kedua belah pihak dan hanya bisa berlindung di balik bangunan tanpa dapat malakukan pengunduran dari daerah pertempuran. Setelah kontak tembak sedikit mereda Kopda Zulkarnain dan Praka Oksa berusaha mencari pasukan kawan ke arah Kafer Kela yang merupakan Area of Responsibility (AoR) Spain Battalion. Kedua prajurit ini tidak bertemu dengan satupun anggota Peacekeeper yang diharapkan berada di pos pengamatan Spainbatt, karena telah ditarik mundur oleh Komando Atas.
Dari keterangan kedua prajurit tersebut, mereka memutuskan untuk menuju ke arah Fatima Gate, persimpangan jalan dimana terdapat OP (Observation Post) Spainbatt lainnya. Sama seperti kejadian pada pos sebelumnya, mereka tidak menemukan satupun anggota UN yang siaga di tempat tersebut. Dalam keadaan putus hubungan komunikasi dengan pasukan induk serta tanpa mengetahui situasi terakhir, mereka menerima bantuan salah satu masyarakat Lebanon yang bersedia mengantarkannya ke markas Indobatt UN Posn 7-1 desa Adshit Al-Qusayr yang berjarak 15 Km dari Fatima-Gate.
Dari peristiwa kontak tembak antara LAF dan IDF telah jatuh korban dari kedua belah pihak. Dari pihak Lebanon, tiga anggota LAF dan satu orang jurnalis AL-Akhbar Lebanese tewas di tempat. Sedangkan dari pihak IDF, dua orang Perwiranya menjadi korban dan meninggal dunia. Untuk pihak Indobatt sendiri, tidak ada kerugian personel maupun material. Hal ini dikarenakan kesigapan prajurit Indobatt dalam melaksanakan tindakan pengunduran pasukan sesuai dengan STIR (Standardize Tactical Incident Reaction) yang dilakukan berdasarkan perintah Komando Atas dalam hal ini oleh Sektor Timur UNIFIL.
Push Administration/Registration/Login Prestashop using SSL
Coz, someone ask how to make administration,login page using SSL in id-freebsd milis, I am trying for Prestashop and make some modification in preference and code. The modification code is in the login.php in admin folder(I got it from http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html)
add the following code in login.php
//Redirect to https if accessed over http (except when running locally)
if ($_SERVER['SERVER_NAME'] != "localhost")
{
$port = $_SERVER["SERVER_PORT"];
$ssl_port = "443"; //Change 443 to whatever port you use for https (443 is the default and will work in most cases)
if ($port != $ssl_port)
{
$host = $_SERVER["HTTP_HOST"];
$uri = $_SERVER["REQUEST_URI"];
header("Location: https://$host$uri");
}
}
The code above is if the origin port is not equal to the ssl port so redirect to the location of https://$host$uri
That script will push using port 443 if the origin site are in port 80.
And below is for registration and login in prestashop. Simple just go to preference in admin page.
Just enable to Yes.
Enable SSL Yes No
If your hosting provider allows SSL, you can activate SSL encryption (https://) for customer account identification and order processing
Or you can using rewrite module in apache. Please read the http://www.askapache.com/htaccess/apache-ssl-in-htaccess-examples.html for good explanation.
add the following code in login.php
//Redirect to https if accessed over http (except when running locally)
if ($_SERVER['SERVER_NAME'] != "localhost")
{
$port = $_SERVER["SERVER_PORT"];
$ssl_port = "443"; //Change 443 to whatever port you use for https (443 is the default and will work in most cases)
if ($port != $ssl_port)
{
$host = $_SERVER["HTTP_HOST"];
$uri = $_SERVER["REQUEST_URI"];
header("Location: https://$host$uri");
}
}
The code above is if the origin port is not equal to the ssl port so redirect to the location of https://$host$uri
That script will push using port 443 if the origin site are in port 80.
And below is for registration and login in prestashop. Simple just go to preference in admin page.
Just enable to Yes.
Enable SSL Yes No
If your hosting provider allows SSL, you can activate SSL encryption (https://) for customer account identification and order processing
Or you can using rewrite module in apache. Please read the http://www.askapache.com/htaccess/apache-ssl-in-htaccess-examples.html for good explanation.
Subscribe to:
Posts (Atom)